# Cis Benchmarks > - Skill: `frank-luongt/cis-benchmarks` (Agent Skill) - Install (CLI): `npx skillmds@latest add frank-luongt/cis-benchmarks` - Raw SKILL.md: https://api.skillmd.com/api/skills/frank-luongt/cis-benchmarks/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Coding & Dev Tools - Author: frank-luongt (https://skillmd.com/u/frank-luongt) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/frank-luongt/cis-benchmarks --- --- 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