frank-luongt/skills/codex/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

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:

# 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:

# 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:

# 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:

{
  "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:

{
  "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 -- official benchmark PDFs
• kube-bench GitHub -- automated Kubernetes CIS scanning
• docker-bench-security GitHub -- automated Docker CIS scanning
• GCP Security Command Center -- built-in CIS compliance for GCP
• CIS Controls v8 Mapping -- mapping benchmarks to CIS Controls
• NIST SP 800-190 -- Application Container Security Guide

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