Cis Benchmarks

<!-- AUTO-GENERATED by export-skills.py — DO NOT EDIT -->
---
name: cis-benchmarks
description: CIS Benchmarks reference for Kubernetes, Docker, and GCP hardening with automated scanning guidance
tags: [cis, security]
---

# CIS Benchmarks Reference

## Overview

The Center for Internet Security (CIS) publishes consensus-based security configuration benchmarks for operating systems, cloud platforms, containers, and orchestrators. CIS Benchmarks provide prescriptive, testable hardening recommendations organized into two levels:

- **Level 1** -- Practical settings that can be applied broadly with minimal impact on functionality. These represent baseline security posture.
- **Level 2** -- Defense-in-depth settings intended for high-security environments. They may restrict functionality or require additional planning.

This skill covers the three benchmarks most relevant to the FAOS platform:

| Benchmark                  | Current Version | Controls | Primary Tool      |
|----------------------------|-----------------|----------|-------------------|
| CIS Kubernetes Benchmark   | v1.9.0          | ~120     | kube-bench         |
| CIS Docker Benchmark       | v1.6.0          | ~100     | docker-bench-security |
| CIS GCP Foundations        | v3.0.0          | ~80      | Forseti / SCC      |

Each benchmark maps to broader frameworks (NIST 800-53, ISO 27001, SOC 2) making CIS compliance a strong foundation for multi-framework audits.

## When to Use This Skill

- You are hardening a new Kubernetes cluster or Docker host before production deployment
- A compliance audit requires evidence of CIS benchmark adherence
- You need to prioritize remediation findings from an automated CIS scan
- You are building Infrastructure as Code and want to embed CIS controls from the start
- You are reviewing pull requests that modify cluster configuration, Dockerfiles, or GCP IAM/network settings
- You want to map CIS controls to SOC 2, ISO 27001, or NIST CSF requirements

## How It Works

### Step 1: Select the Applicable Benchmark

Identify which benchmarks apply based on your infrastructure stack. For a typical FAOS deployment on GKE:

- **CIS GCP Foundations** -- covers project-level IAM, networking, logging, and storage
- **CIS Kubernetes Benchmark** -- covers API server, etcd, kubelet, scheduler, and workload configuration
- **CIS Docker Benchmark** -- covers Docker daemon, images, container runtime, and host configuration

Download the latest benchmark PDFs from the CIS website (free registration required) or use the CIS-CAT Pro tool for automated assessment.

### Step 2: Run Automated Scans

Use purpose-built tools to assess compliance automatically:

```bash
# Kubernetes: kube-bench (runs CIS Kubernetes Benchmark checks)
# Install via Helm or run as a Job
kubectl apply -f https://raw.githubusercontent.com/aquasecurity/kube-bench/main/job.yaml
kubectl logs -l app=kube-bench --tail=-1

# Docker: docker-bench-security
git clone https://github.com/docker/docker-bench-security.git
cd docker-bench-security
sudo sh docker-bench-security.sh

# GCP: Security Command Center (SCC) with CIS compliance module
gcloud scc findings list organizations/$ORG_ID \
  --filter="category=\"CIS_BENCHMARK\"" \
  --format=json
```

For GKE specifically, Google Cloud Security Command Center provides built-in CIS Kubernetes Benchmark scanning without additional tooling.

### Step 3: Review Findings

Scan output categorizes findings as PASS, FAIL, WARN, or INFO. Focus triage on:

1. **FAIL at Level 1** -- these are baseline gaps that should be remediated first
2. **FAIL at Level 2** -- evaluate based on your security requirements
3. **WARN** -- manual verification needed; the tool could not determine status automatically

Map each finding to its control ID (e.g., `1.2.3`) for tracking in your compliance management system.

### Step 4: Remediate by Priority

Prioritize remediation using this order:

1. **Critical exposure** -- unauthenticated API access, anonymous auth enabled, unencrypted etcd
2. **Privilege escalation** -- excessive RBAC permissions, privileged containers, hostPID/hostNetwork
3. **Data protection** -- secrets not encrypted at rest, audit logging disabled
4. **Network hardening** -- missing NetworkPolicies, overly permissive firewall rules
5. **Operational hygiene** -- missing resource limits, missing labels, outdated images

### Step 5: Re-validate After Remediation

After applying fixes, re-run the automated scans to confirm remediation:

```bash
# Re-run kube-bench and compare
kubectl apply -f kube-bench-job.yaml
kubectl logs -l app=kube-bench --tail=-1 | grep -E "^\[FAIL\]" | wc -l

# Track progress over time
echo "$(date +%Y-%m-%d),$(kubectl logs -l app=kube-bench --tail=-1 | grep -c FAIL)" >> cis-progress.csv
```

Integrate CIS scanning into CI/CD pipelines to catch regressions on every infrastructure change.

## Examples

### Example 1: Running kube-bench on GKE and Interpreting Results

Deploy kube-bench as a Kubernetes Job targeting the GKE-specific benchmark:

```yaml
# kube-bench-job.yaml
apiVersion: batch/v1
kind: Job
metadata:
  name: kube-bench
spec:
  template:
    spec:
      hostPID: true
      containers:
      - name: kube-bench
        image: aquasec/kube-bench:v0.8.0
        command: ["kube-bench", "run", "--benchmark", "gke-1.6.0", "--json"]
        volumeMounts:
        - name: var-lib-kubelet
          mountPath: /var/lib/kubelet
          readOnly: true
        - name: etc-systemd
          mountPath: /etc/systemd
          readOnly: true
      restartPolicy: Never
      volumes:
      - name: var-lib-kubelet
        hostPath:
          path: /var/lib/kubelet
      - name: etc-systemd
        hostPath:
          path: /etc/systemd
```

Interpreting the JSON output:

```json
{
  "Controls": [
    {
      "id": "4.2",
      "text": "Pod Security Standards",
      "tests": [
        {
          "section": "4.2.1",
          "desc": "Minimize the admission of privileged containers",
          "status": "FAIL",
          "remediation": "Apply PodSecurity admission controller with 'restricted' profile"
        }
      ]
    }
  ],
  "Totals": { "total_pass": 42, "total_fail": 8, "total_warn": 12, "total_info": 3 }
}
```

A `total_fail` of 8 means 8 controls need immediate attention. Filter for Level 1 failures first.

### Example 2: Docker Daemon Hardening Configuration

Apply CIS Docker Benchmark Level 1 recommendations via `/etc/docker/daemon.json`:

```json
{
  "icc": false,
  "iptables": true,
  "log-driver": "json-file",
  "log-opts": {
    "max-size": "10m",
    "max-file": "3"
  },
  "live-restore": true,
  "no-new-privileges": true,
  "userland-proxy": false,
  "userns-remap": "default",
  "storage-driver": "overlay2",
  "default-ulimits": {
    "nofile": {
      "Name": "nofile",
      "Hard": 65536,
      "Soft": 32768
    }
  },
  "tls": true,
  "tlscacert": "/etc/docker/certs/ca.pem",
  "tlscert": "/etc/docker/certs/server-cert.pem",
  "tlskey": "/etc/docker/certs/server-key.pem",
  "tlsverify": true
}
```

Key settings explained:

| Setting            | CIS Control | Purpose                                      |
|--------------------|-------------|----------------------------------------------|
| `icc: false`       | 2.1         | Disable inter-container communication         |
| `no-new-privileges`| 2.18        | Prevent privilege escalation in containers    |
| `userns-remap`     | 2.8         | Enable user namespace remapping               |
| `tls/tlsverify`    | 2.6         | Protect Docker daemon socket with TLS         |
| `live-restore`     | 2.14        | Keep containers running during daemon restart |
| `log-driver`       | 2.12        | Ensure container logging is configured        |

## Best Practices

### Do This

- Run CIS benchmarks as part of your CI/CD pipeline for infrastructure changes
- Start with Level 1 controls; they provide the highest security-to-effort ratio
- Use Infrastructure as Code to enforce CIS controls declaratively (Terraform, Helm)
- Track CIS compliance scores over time with a simple dashboard
- Map CIS controls to your primary compliance framework for audit evidence
- Apply the principle of least privilege across Kubernetes RBAC, GCP IAM, and Docker
- Enable audit logging at every layer: GCP audit logs, K8s audit policy, Docker daemon logs

### Don't Do This

- Do not skip Level 1 controls because they seem basic -- attackers exploit common misconfigurations
- Do not run kube-bench only once and assume ongoing compliance; configuration drifts
- Do not apply Level 2 controls blindly -- some may break workloads (e.g., `readOnlyRootFilesystem`)
- Do not ignore WARN findings; they often require manual verification of important controls
- Do not expose the Docker daemon socket over TCP without TLS
- Do not grant `cluster-admin` to service accounts or workloads without justification
- Do not disable PodSecurityStandards enforcement in production namespaces

## Security Checklist

### Kubernetes Hardening

- [ ] API server anonymous auth is disabled (`--anonymous-auth=false`)
- [ ] RBAC is enabled and default service account tokens are not automounted
- [ ] Etcd is encrypted at rest with a KMS provider
- [ ] Audit logging is enabled with an appropriate audit policy
- [ ] PodSecurityStandards are enforced at `restricted` or `baseline` level
- [ ] NetworkPolicies are applied to every namespace
- [ ] Kubelet authentication and authorization are properly configured
- [ ] Container images use non-root users
- [ ] Resource requests and limits are set for all containers
- [ ] Secrets are stored in an external secret manager (not plain K8s Secrets)

### Docker Hardening

- [ ] Docker daemon socket is not exposed without TLS
- [ ] Inter-container communication is disabled (`icc: false`)
- [ ] Content trust is enabled for image verification (`DOCKER_CONTENT_TRUST=1`)
- [ ] Base images are minimal (distroless, Alpine, or scratch)
- [ ] No secrets are baked into Docker images
- [ ] Containers run as non-root users
- [ ] Health checks are defined in Dockerfiles
- [ ] Log drivers are configured for centralized logging
- [ ] Docker daemon is kept up to date

### GCP Hardening

- [ ] Organization policy constraints are configured (e.g., no public IPs on VMs)
- [ ] Uniform bucket-level access is enabled on Cloud Storage
- [ ] VPC Flow Logs are enabled for all subnets
- [ ] Cloud Audit Logs are enabled for all services (Admin Activity + Data Access)
- [ ] Service accounts follow least-privilege with no primitive roles
- [ ] Cloud KMS is used for customer-managed encryption keys
- [ ] Binary Authorization is enforced for GKE container deployments
- [ ] Security Command Center is enabled with Premium tier

## Related Skills

- @container-security-guide -- detailed Docker and Kubernetes runtime hardening
- @cloud-security-patterns -- cloud-native security architectures for GCP, AWS, Azure
- @nist-csf -- mapping CIS controls to the NIST Cybersecurity Framework
- @compliance-crosswalk -- multi-framework mapping including CIS to SOC 2/ISO 27001

## Additional Resources

- [CIS Benchmarks Downloads](https://www.cisecurity.org/cis-benchmarks) -- official benchmark PDFs
- [kube-bench GitHub](https://github.com/aquasecurity/kube-bench) -- automated Kubernetes CIS scanning
- [docker-bench-security GitHub](https://github.com/docker/docker-bench-security) -- automated Docker CIS scanning
- [GCP Security Command Center](https://cloud.google.com/security-command-center) -- built-in CIS compliance for GCP
- [CIS Controls v8 Mapping](https://www.cisecurity.org/controls/v8) -- mapping benchmarks to CIS Controls
- [NIST SP 800-190](https://csrc.nist.gov/publications/detail/sp/800-190/final) -- Application Container Security Guide

<!-- Source: .faos/custom/skills/security/cis-benchmarks/SKILL.md -->