Skip to main content

CCC Kubernetes Controls Catalog

This page renders the FINOS Common Cloud Controls Managed Kubernetes controls as a Gemara ControlCatalog, including the shared CCC Core controls this service catalog imports. Native K8S controls and imported Core controls appear together with their assessment requirements.

For the companion catalogs, see the Capabilities Catalog and Threats Catalog.

ControlCatalogvv2026.07-rc
Controls for Managed Kubernetes Container Orchestration technologies, as defined by the FINOS Common Cloud Controls project.

Showing 27 of 27

Access Control

The Access Control group covers entries related to authentication, authorization, and trust perimeter enforcement. This includes multi-factor authentication, least privilege access, network access rules, and prevention of unauthorized access or reconnaissance.

CCC.K8S.CN01Restrict Kubernetes API Network Access
Objective

Limit Kubernetes API reachability to explicitly approved networks and private management paths to reduce administrative exposure.

Assessment Requirements
  • CCC.K8S.CN01.AR01

    When a Kubernetes API endpoint is active, its network access configuration MUST restrict inbound traffic to explicitly approved private networks or source address ranges.

    Applicability: tlp-cleartlp-greentlp-ambertlp-red

    Recommendation: Configure a private cluster endpoint where possible and otherwise maintain a minimal allowlist of approved administration networks.

  • CCC.K8S.CN01.AR02

    When a Kubernetes API endpoint is active, public network access to that endpoint MUST be disabled.

    Applicability: tlp-ambertlp-red

    Recommendation: Use private endpoint connectivity, private DNS, and controlled administrative access paths from trusted networks.

Threats CCC.Core.Threats
  • CCC.Core.TH01Access is Granted to Unauthorized Users
  • CCC.Core.TH15Automated Enumeration and Reconnaissance by Non-human Entities
  • CCC.Core.TH17Responses are Generated for Unauthorized Requests
Threats CCC.K8S.Threats
  • CCC.K8S.TH01Kubernetes API is Exposed to Untrusted Networks
Guidelines NIST_800_53
  • SC-7Boundary Protection
  • AC-17Remote Access
CCC.K8S.CN02Enforce Least-Privilege Cluster Authorization
Objective

Apply least privilege across cloud and Kubernetes authorization so identities receive only the permissions required for their cluster responsibilities.

Assessment Requirements
  • CCC.K8S.CN02.AR01

    When a user or group is granted cluster access, each cloud access binding and Kubernetes role binding MUST grant only an approved role required by that identity's documented responsibilities.

    Applicability: tlp-cleartlp-greentlp-ambertlp-red

    Recommendation: Assign access to managed identity groups and review cloud access entries, ClusterRoleBindings, and RoleBindings against an approved entitlement inventory.

  • CCC.K8S.CN02.AR02

    When a non-system Kubernetes role is defined, it MUST NOT grant wildcard verbs or wildcard resources AND any access to secrets, role bindings, admission configuration, or node proxy functions MUST enumerate the required verbs and resource names.

    Applicability: tlp-cleartlp-greentlp-ambertlp-red

    Recommendation: Replace broad roles with namespace-scoped roles and narrowly enumerated API groups, resources, resource names, and verbs.

Threats CCC.Core.Threats
  • CCC.Core.TH01Access is Granted to Unauthorized Users
Threats CCC.K8S.Threats
  • CCC.K8S.TH02Workload Identity Grants Excessive Cloud Access
  • CCC.K8S.TH13Controllers Reconcile Unauthorized Cluster State
Guidelines NIST_800_53
  • AC-3Access Enforcement
  • AC-6Least Privilege
CCC.K8S.CN03Use Federated Identities for Workloads
Objective

Replace stored cloud credentials with narrowly scoped, short-lived federated identity for workload access to cloud services.

Assessment Requirements
  • CCC.K8S.CN03.AR01

    When a workload accesses a cloud API, its Kubernetes service account MUST be bound to a dedicated cloud identity that issues short-lived credentials through workload identity federation.

    Applicability: tlp-cleartlp-greentlp-ambertlp-red

    Recommendation: Use the CSP workload identity integration and assign one cloud permission set for each distinct workload responsibility.

  • CCC.K8S.CN03.AR02

    When workload identity federation is enabled, workload specifications and Kubernetes configuration objects MUST NOT contain long-lived cloud access keys, client secrets, or service-account key files.

    Applicability: tlp-cleartlp-greentlp-ambertlp-red

    Recommendation: Scan workload manifests, Secrets, ConfigMaps, environment variables, and mounted files for static cloud credentials and revoke any discovered credentials.

Threats CCC.K8S.Threats
  • CCC.K8S.TH02Workload Identity Grants Excessive Cloud Access
  • CCC.K8S.TH03Long-Lived Credentials are Exposed to Workloads
  • CCC.K8S.TH07Secrets are Exposed to Unauthorized Workloads
Guidelines NIST_800_53
  • AC-6Least Privilege
  • IA-5Authenticator Management
CCC.K8S.CN07Protect Workload Secrets
Objective

Protect workload secrets through encrypted handling, narrow authorization, and removal from images and non-secret configuration objects.

Assessment Requirements
  • CCC.K8S.CN07.AR01

    Secret material used by a workload MUST be encrypted during storage and delivery, MUST be accessible only to the intended workload identity, and MUST NOT be embedded in a container image or non-secret configuration resource.

    Applicability: tlp-greentlp-ambertlp-red

    Recommendation: Use a protected Kubernetes secret mechanism, encrypted manifest workflow, or external secrets service, and rotate any secret discovered in a static workload artifact.

  • CCC.K8S.CN07.AR02

    When Kubernetes secret access is granted, workload roles MUST be limited to the required named secrets and MUST NOT grant unrestricted list or watch access.

    Applicability: tlp-cleartlp-greentlp-ambertlp-red

    Recommendation: Use namespace-scoped roles with resource names and audit service accounts that can read Secret resources.

Threats CCC.K8S.Threats
  • CCC.K8S.TH03Long-Lived Credentials are Exposed to Workloads
  • CCC.K8S.TH07Secrets are Exposed to Unauthorized Workloads
Guidelines NIST_800_53
  • AC-3Access Enforcement
  • IA-5Authenticator Management
  • SC-28Protection of Information at Rest
CCC.K8S.CN11Protect Admission Control Enforcement
Objective

Apply mandatory cluster security policy to every workload path and prevent its scope or enforcement configuration from being bypassed or modified without authorization.

Assessment Requirements
  • CCC.K8S.CN11.AR01

    When security admission policies are enabled, every namespace and relevant create or update operation MUST be governed by an explicitly defined policy, including separate policies for system namespaces that require different constraints.

    Applicability: tlp-cleartlp-greentlp-ambertlp-red

    Recommendation: Test policy coverage across user and system namespaces, workload controllers, direct pod creation, and ephemeral container updates.

  • CCC.K8S.CN11.AR02

    When admission policy configuration is modified, the change MUST require a dedicated administrative role AND produce an externally retained audit record.

    Applicability: tlp-cleartlp-greentlp-ambertlp-red

    Recommendation: Separate policy administration from workload administration and alert on policy, webhook, namespace-label, and policy-scope changes.

  • CCC.K8S.CN11.AR03

    When an external admission component enforces a mandatory control, unavailable or untrusted webhook responses MUST cause the request to be denied.

    Applicability: tlp-greentlp-ambertlp-red

    Recommendation: Configure mandatory validation webhooks to fail closed and monitor webhook availability and certificate trust continuously.

Threats CCC.K8S.Threats
  • CCC.K8S.TH12Admission Controls are Bypassed
  • CCC.K8S.TH13Controllers Reconcile Unauthorized Cluster State
Guidelines NIST_800_53
  • CM-3Configuration Change Control
  • CM-6Configuration Settings
  • SI-7Software, Firmware, and Information Integrity
CCC.K8S.CN12Restrict Node Administrative Access
Objective

Block untrusted or unauthenticated paths to worker-node administration, kubelet interfaces, and instance metadata.

Assessment Requirements
  • CCC.K8S.CN12.AR01

    When a worker node is active, kubelet and node administrative APIs MUST require authentication and authorization AND anonymous or read-only unauthenticated access MUST be disabled.

    Applicability: tlp-cleartlp-greentlp-ambertlp-red

    Recommendation: Use provider-managed node authorization and verify kubelet configuration and network reachability from outside approved management paths.

  • CCC.K8S.CN12.AR02

    When SSH, RDP, or another node management interface is enabled, it MUST NOT be reachable from the public internet and MUST be restricted to an approved authenticated management path.

    Applicability: tlp-cleartlp-greentlp-ambertlp-red

    Recommendation: Disable interactive node access where possible and otherwise use an audited session-management or bastion service without public node addresses.

  • CCC.K8S.CN12.AR03

    When a workload does not require instance metadata, network access from that workload to the node metadata service MUST be denied.

    Applicability: tlp-greentlp-ambertlp-red

    Recommendation: Use workload identity federation, metadata concealment or hop limits, and network policy or node firewall controls to prevent workload metadata access.

Threats CCC.K8S.Threats
  • CCC.K8S.TH14Node Administrative Interfaces Expose Cluster Credentials
Guidelines NIST_800_53
  • AC-17Remote Access
  • CM-7Least Functionality
  • IA-2Identification and Authentication (Organizational Users)
CCC.K8S.CN16Enforce Managed Cluster Authentication
Objective

Bind human access to the Kubernetes API and cluster resources to identities that can be centrally governed, monitored, and revoked.

Assessment Requirements
  • CCC.K8S.CN16.AR01

    When a human accesses the Kubernetes API or cluster resources, authentication MUST use an identity from a centrally managed identity provider or cloud identity service AND that access MUST be revocable independently of the cluster.

    Applicability: tlp-cleartlp-greentlp-ambertlp-red

    Recommendation: Integrate cluster authentication with a managed identity provider or cloud identity service and govern human access through centrally maintained identity lifecycle processes.

  • CCC.K8S.CN16.AR02

    Unmanaged local accounts, static human credentials, and legacy authentication methods MUST NOT provide human access to the Kubernetes API or cluster resources.

    Applicability: tlp-cleartlp-greentlp-ambertlp-red

    Recommendation: Disable authentication methods that cannot be centrally governed or promptly revoked, and monitor the cluster for their reintroduction.

Threats CCC.Core.Threats
  • CCC.Core.TH01Access is Granted to Unauthorized Users
Threats CCC.K8S.Threats
  • CCC.K8S.TH16Unmanaged Credentials Bypass Cluster Identity Controls
Guidelines NIST_800_53
  • AC-2Account Management
  • IA-2Identification and Authentication (Organizational Users)
  • IA-5Authenticator Management
CCC.K8S.CN17Restrict Cluster Infrastructure Identities
Objective

Limit cloud access by cluster infrastructure to the permissions and resources required for each platform responsibility.

Assessment Requirements
  • CCC.K8S.CN17.AR01

    Control-plane, worker-node, and supporting components with distinct security responsibilities MUST use independently governed cloud identities.

    Applicability: tlp-cleartlp-greentlp-ambertlp-red

    Recommendation: Separate infrastructure identities according to component responsibility and review their trust relationships and assignments together.

  • CCC.K8S.CN17.AR02

    Each cluster infrastructure identity MUST grant only the cloud actions and resource scope required for its platform responsibility.

    Applicability: tlp-cleartlp-greentlp-ambertlp-red

    Recommendation: Replace shared, default, or general-purpose permissions with narrowly scoped identity assignments and continuously review their effective access.

Threats CCC.K8S.Threats
  • CCC.K8S.TH02Workload Identity Grants Excessive Cloud Access
  • CCC.K8S.TH17Cluster Infrastructure Identities Grant Excessive Cloud Access
Guidelines NIST_800_53
  • AC-2Account Management
  • AC-6Least Privilege
CCC.Core.CN03Implement Multi-factor Authentication (MFA) for Accessimported

Imported from CCC.Core.Controls

Objective

Ensure that all sensitive activities require two or more identity factors during authentication to prevent unauthorized access.

Assessment Requirements
  • CCC.Core.CN03.AR01

    When an entity attempts to modify the service through a user interface, the authentication process MUST require multiple identifying factors for authentication.

    Applicability: tlp-cleartlp-greentlp-ambertlp-red

  • CCC.Core.CN03.AR02

    When an entity attempts to modify the service through an API endpoint, the authentication process MUST require a credential such as an API key or token AND originate from within the trust perimeter.

    Applicability: tlp-cleartlp-greentlp-ambertlp-red

  • CCC.Core.CN03.AR03

    When an entity attempts to view information on the service through a user interface, the authentication process MUST require multiple identifying factors from the user.

    Applicability: tlp-ambertlp-red

  • CCC.Core.CN03.AR04

    When an entity attempts to view information on the service through an API endpoint, the authentication process MUST require a credential such as an API key or token AND originate from within the trust perimeter.

    Applicability: tlp-ambertlp-red

Threats CCC.Core.Threats
  • CCC.Core.TH01
Guidelines CCM
  • IAM-14Strong Authentication (Define, implement and evaluate processes - including MFA)
CCC.Core.CN05Prevent Access from Untrusted Entitiesimported

Imported from CCC.Core.Controls

Objective

Ensure that secure access controls enforce the principle of least privilege to restrict access to authorized entities from explicitly trusted sources only.

Assessment Requirements
  • CCC.Core.CN05.AR01

    When an attempt is made to modify data on the service or a child resource, the service MUST block requests from unauthorized entities.

    Applicability: tlp-cleartlp-greentlp-ambertlp-red

  • CCC.Core.CN05.AR02

    When administrative access or configuration change is attempted on the service or a child resource, the service MUST refuse requests from unauthorized entities.

    Applicability: tlp-cleartlp-greentlp-ambertlp-red

  • CCC.Core.CN05.AR03

    When administrative access or configuration change is attempted on the service or a child resource in a multi-tenant environment, the service MUST refuse requests across tenant boundaries unless the origin is explicitly included in a pre-approved allowlist.

    Applicability: tlp-cleartlp-greentlp-ambertlp-red

  • CCC.Core.CN05.AR04

    When data is requested from outside the trust perimeter, the service MUST refuse requests from unauthorized entities.

    Applicability: tlp-ambertlp-red

  • CCC.Core.CN05.AR05

    When any request is made from outside the trust perimeter, the service MUST NOT provide any response that may indicate the service exists.

    Applicability: tlp-red

  • CCC.Core.CN05.AR06

    When any request is made to the service or a child resource, the service MUST refuse requests from unauthorized entities.

    Applicability: tlp-greentlp-ambertlp-red

Threats CCC.Core.Threats
  • CCC.Core.TH01
Guidelines CCM
  • DSP-01Security and Privacy Policy and Proceduress
  • DSP-07Data Protection by Design and Default
  • DSP-08Data Privacy by Design and Default
  • DSP-10Sensitive Data Transfer
  • DSP-17Sensitive Data Protection

Resource Management

The Resource Management group covers entries related to the lifecycle, configuration, and operational integrity of cloud resources. This includes resource exhaustion, tag manipulation, version rollback, scaling, and cost management.

CCC.K8S.CN04Admit Only Trusted Container Images
Objective

Prevent unapproved, mutable, unverifiable, or critically vulnerable container images from entering the workload environment.

Assessment Requirements
  • CCC.K8S.CN04.AR01

    When a workload is admitted, every container image MUST originate from an approved registry AND be referenced by an immutable digest.

    Applicability: tlp-cleartlp-greentlp-ambertlp-red

    Recommendation: Enforce registry allowlists and digest pinning with an admission policy.

  • CCC.K8S.CN04.AR02

    When a container image is admitted, its signature and provenance attestation MUST be verified against an approved publisher and build process.

    Applicability: tlp-greentlp-ambertlp-red

    Recommendation: Sign images during the approved build pipeline and enforce signature and provenance verification during admission.

  • CCC.K8S.CN04.AR03

    When a container image contains a known critical vulnerability, admission of that image MUST be denied.

    Applicability: tlp-greentlp-ambertlp-red

    Recommendation: Integrate continuously updated registry vulnerability results with the cluster's admission policy and remediate affected images before deployment.

Threats CCC.K8S.Threats
  • CCC.K8S.TH04Untrusted Container Images are Deployed
Guidelines NIST_800_53
  • RA-5Vulnerability Monitoring and Scanning
  • SI-7Software, Firmware, and Information Integrity
  • SR-11Component Authenticity
CCC.K8S.CN09Maintain Supported Cluster Components
Objective

Keep control-plane, worker, runtime, and extension components within supported and vulnerability-managed release lifecycles.

Assessment Requirements
  • CCC.K8S.CN09.AR01

    When a cluster is operational, its Kubernetes control-plane version, worker version, node image, and container runtime MUST remain within the CSP's current support lifecycle.

    Applicability: tlp-cleartlp-greentlp-ambertlp-red

    Recommendation: Monitor provider support calendars and inventory all control-plane and worker versions before support deadlines.

  • CCC.K8S.CN09.AR02

    Managed cluster components and worker-node images MUST incorporate published security updates through a supported update or replacement mechanism.

    Applicability: tlp-greentlp-ambertlp-red

    Recommendation: Use automatic upgrade channels where available and test upgrades in a representative non-production cluster before promotion.

  • CCC.K8S.CN09.AR03

    When a cluster add-on or extension is installed, its version MUST be compatible with the active Kubernetes version and remain supported by its publisher.

    Applicability: tlp-cleartlp-greentlp-ambertlp-red

    Recommendation: Include managed add-ons, CSI and CNI components, ingress controllers, policy engines, and observability agents in the version inventory.

Threats CCC.K8S.Threats
  • CCC.K8S.TH09Unsupported Cluster Components Remain in Use
Guidelines NIST_800_53
  • CM-8System Component Inventory
  • SI-2Flaw Remediation
CCC.K8S.CN13Bound Workload Resource Consumption
Objective

Bound resource requests, namespace consumption, and autoscaling so workloads cannot exhaust cluster or cloud capacity.

Assessment Requirements
  • CCC.K8S.CN13.AR01

    When a workload is admitted, every container MUST define approved CPU and memory requests and limits.

    Applicability: tlp-cleartlp-greentlp-ambertlp-red

    Recommendation: Apply LimitRanges for defaults and validate workload-specific requests and limits against tested capacity requirements.

  • CCC.K8S.CN13.AR02

    When a user workload namespace is active, ResourceQuota objects MUST bound its aggregate CPU, memory, storage, workload count, and externally exposed services.

    Applicability: tlp-cleartlp-greentlp-ambertlp-red

    Recommendation: Provision namespace quotas from centrally governed templates and alert before consumption reaches each quota.

  • CCC.K8S.CN13.AR03

    When workload or node autoscaling is enabled, every autoscaler MUST define an approved maximum replica or capacity boundary.

    Applicability: tlp-cleartlp-greentlp-ambertlp-red

    Recommendation: Set workload replica maxima, node-pool maxima, cloud quotas, budgets, and alerts that constrain the complete scaling chain.

Threats CCC.Core.Threats
  • CCC.Core.TH12Resource Constraints are Exhausted
Guidelines NIST_800_53
  • SC-5Denial-of-service Protection
CCC.K8S.CN15Protect Resource Metadata
Objective

Preserve the completeness and accuracy of policy-relevant cloud tags and Kubernetes labels by limiting modification to authorized identities.

Assessment Requirements
  • CCC.K8S.CN15.AR01

    When a cluster, node pool, namespace, or governed workload is created, all organization-required ownership, environment, data-classification, and policy metadata MUST be present with approved values.

    Applicability: tlp-cleartlp-greentlp-ambertlp-red

    Recommendation: Enforce required cloud tags and Kubernetes labels during resource creation and continuously report missing or invalid values.

  • CCC.K8S.CN15.AR02

    When metadata controls authorization, network policy, admission, billing, or data handling, modification of that metadata MUST be restricted to a dedicated role and MUST produce an externally retained audit record.

    Applicability: tlp-cleartlp-greentlp-ambertlp-red

    Recommendation: Protect policy-significant labels and tags with cloud policy, Kubernetes RBAC, admission policy, and alerts for unauthorized changes.

Threats CCC.Core.Threats
  • CCC.Core.TH13Resource Tags are Manipulated
Guidelines NIST_800_53
  • AC-16Security and Privacy Attributes
  • CM-3Configuration Change Control
  • CM-8System Component Inventory

Compute

The Compute group covers entries related to processing, execution, and runtime infrastructure. This includes CPU, memory, storage allocation, network ports, command-line interfaces, and elastic scaling.

CCC.K8S.CN05Enforce Restricted Workload Security
Objective

Minimize workload privilege and block unnecessary access to host-level resources that could defeat container isolation.

Assessment Requirements
  • CCC.K8S.CN05.AR01

    When a workload is admitted, it MUST NOT request privileged execution, privilege escalation, host PID, host IPC, host networking, unrestricted host paths, or additional Linux capabilities.

    Applicability: tlp-cleartlp-greentlp-ambertlp-red

    Recommendation: Enforce the Kubernetes Restricted Pod Security Standard or a stricter equivalent policy across all workload namespaces.

  • CCC.K8S.CN05.AR02

    When a Linux workload is admitted, each container MUST run as a non-root user, use the runtime-default seccomp profile, disable privilege escalation, and drop all Linux capabilities without adding capabilities back to the container.

    Applicability: tlp-greentlp-ambertlp-red

    Recommendation: Define secure defaults in workload templates and enforce them through admission policy before resources are persisted.

Threats CCC.K8S.Threats
  • CCC.K8S.TH05Privileged Workloads Escape Isolation
  • CCC.K8S.TH12Admission Controls are Bypassed
Guidelines NIST_800_53
  • AC-6Least Privilege
  • CM-7Least Functionality
CCC.K8S.CN18Protect Worker Node Integrity
Objective

Prevent untrusted or altered worker-node software from operating beneath Kubernetes workloads.

Assessment Requirements
  • CCC.K8S.CN18.AR01

    Worker nodes MUST use supported images obtained from the service or an authenticated publisher.

    Applicability: tlp-cleartlp-greentlp-ambertlp-red

    Recommendation: Provision worker pools from maintained image sources and verify image identity and support status during creation and replacement.

  • CCC.K8S.CN18.AR02

    Worker nodes MUST use service-supported boot-integrity verification before accepting workloads.

    Applicability: tlp-cleartlp-greentlp-ambertlp-red

    Recommendation: Enable the service's node boot-integrity protections and monitor their reported state throughout the worker-node lifecycle.

Threats CCC.K8S.Threats
  • CCC.K8S.TH05Privileged Workloads Escape Isolation
  • CCC.K8S.TH09Unsupported Cluster Components Remain in Use
  • CCC.K8S.TH18Worker Node Integrity Is Not Verified
Guidelines NIST_800_53
  • CM-2Baseline Configuration
  • SI-2Flaw Remediation
  • SI-7Software, Firmware, and Information Integrity

Networking

The Networking group covers entries related to network infrastructure, connectivity, and traffic management. This includes virtual networks, subnets, load balancing, DNS, routing, peering, and network-level access controls.

CCC.K8S.CN06Enforce Default-Deny Workload Network Policies
Objective

Confine workload communication to flows permitted by explicit, least-privilege network policies, with all other traffic denied by default.

Assessment Requirements
  • CCC.K8S.CN06.AR01

    When a user workload namespace is created, an enforced network policy MUST deny all ingress and egress traffic by default.

    Applicability: tlp-cleartlp-greentlp-ambertlp-red

    Recommendation: Enable a network-policy-capable data plane and deploy default-deny ingress and egress policies through the namespace provisioning process.

  • CCC.K8S.CN06.AR02

    When communication is required, each allow policy MUST identify the approved source, destination, protocol, and port using stable namespace, workload, or network selectors.

    Applicability: tlp-cleartlp-greentlp-ambertlp-red

    Recommendation: Generate explicit application flow policies and test both expected connections and denied lateral or external connections.

Threats CCC.K8S.Threats
  • CCC.K8S.TH06Workload Network Segmentation is Not Enforced
  • CCC.K8S.TH10Workload Endpoints are Exposed Unintentionally
Guidelines NIST_800_53
  • AC-4Information Flow Enforcement
  • SC-7Boundary Protection

Orchestration

The Orchestration group covers entries related to coordinating and managing workloads across distributed systems. This includes container orchestration, job scheduling, CI/CD pipelines, build automation, and service mesh management.

CCC.K8S.CN08Allowlist CSP-Provided Cluster Add-ons and Extensions
Objective

Restrict enabled CSP-provided cluster add-ons, extensions, and managed features to an organization-controlled allowlist.

Assessment Requirements
  • CCC.K8S.CN08.AR01

    When a CSP-provided cluster add-on, extension, or managed feature is enabled, it MUST be included in an organization-controlled allowlist.

    Applicability: tlp-cleartlp-greentlp-ambertlp-red

    Recommendation: Assign a cluster platform owner to maintain the allowlist through change control and continuously reconcile installed components against it.

Threats CCC.K8S.Threats
  • CCC.K8S.TH08Cluster Extensions Execute Untrusted Code
Guidelines NIST_800_53
  • SI-7Software, Firmware, and Information Integrity
  • SR-3Supply Chain Controls and Processes

Data Resilience

The Data Resilience group covers entries related to ensuring data availability, integrity, and sovereignty across its lifecycle. This includes replication, backup, recovery, region restrictions, and protection against data loss or corruption.

CCC.K8S.CN10Restrict Persistent Volume Access
Objective

Confine persistent storage provisioning and mounts to their approved namespace, workload, access mode, and ownership boundary.

Assessment Requirements
  • CCC.K8S.CN10.AR01

    When a persistent volume claim is created, its namespace, storage class, access mode, and requesting service account MUST match an approved workload storage policy.

    Applicability: tlp-cleartlp-greentlp-ambertlp-red

    Recommendation: Restrict storage classes through admission policy and use dedicated service accounts for stateful workloads.

  • CCC.K8S.CN10.AR02

    When a persistent volume is statically provisioned or rebound, its underlying storage identity and prior ownership MUST be verified before it is mounted by a different workload.

    Applicability: tlp-greentlp-ambertlp-red

    Recommendation: Prefer dynamic provisioning and require sanitization or cryptographic erasure before reusing storage across ownership boundaries.

Threats CCC.K8S.Threats
  • CCC.K8S.TH11Persistent Volumes are Bound to Unauthorized Workloads
Guidelines NIST_800_53
  • AC-3Access Enforcement
  • AC-4Information Flow Enforcement
CCC.Core.CN06Restrict Deployments to Trust Perimeterimported

Imported from CCC.Core.Controls

Objective

Ensure that the service and its child resources are only deployed on infrastructure in locations that are explicitly included within a defined trust perimeter.

Assessment Requirements
  • CCC.Core.CN06.AR01

    When the service is running, its region and availability zone MUST be included in a list of explicitly trusted or approved locations within the trust perimeter.

    Applicability: tlp-cleartlp-greentlp-ambertlp-red

    Recommendation: Maintain an up-to-date list of trusted and approved regions based on organizational policies. Validate the service's deployment location is included in this list.

  • CCC.Core.CN06.AR02

    When a child resource is deployed, its region and availability zone MUST be included in a list of explicitly trusted or approved locations within the trust perimeter.

    Applicability: tlp-cleartlp-greentlp-ambertlp-red

    Recommendation: Maintain an up-to-date list of trusted and approved regions based on organizational policies. Validate that child resources can only be deployed to locations included in this list.

Threats CCC.Core.Threats
  • CCC.Core.TH03
Guidelines CCM
  • DSP-19Data Location (specify and document processing and backup locations)

Observability

The Observability group covers entries related to logging, monitoring, metrics, alerting, and event publication. This includes audit trail integrity, enumeration detection, and protection against tampering or unauthorized access to operational telemetry.

CCC.K8S.CN14Preserve Kubernetes Audit and Monitoring Records
Objective

Maintain complete, externally retained, access-controlled, and monitored records of security-relevant Kubernetes activity and health signals.

Assessment Requirements
  • CCC.K8S.CN14.AR01

    When a cluster is operational, Kubernetes API audit logs, control-plane logs, and security-relevant node, workload, and network activity records MUST be enabled and exported to an approved external logging destination.

    Applicability: tlp-cleartlp-greentlp-ambertlp-red

    Recommendation: Enable each CSP control-plane logging category and export cluster telemetry to a centrally governed logging account or project.

  • CCC.K8S.CN14.AR02

    When Kubernetes audit or monitoring records are retained, write, delete, and configuration access MUST be separated from cluster workload and routine cluster administration identities.

    Applicability: tlp-cleartlp-greentlp-ambertlp-red

    Recommendation: Use a separate security logging boundary with retention protection and narrowly scoped read access for monitoring and investigation roles.

  • CCC.K8S.CN14.AR03

    When cluster-admin bindings, admission controls, audit settings, network exposure, or security extensions change, the monitoring system MUST generate an alert for review by an authorized security function.

    Applicability: tlp-greentlp-ambertlp-red

    Recommendation: Create detections for security-sensitive Kubernetes audit events and CSP cluster configuration changes, and test alert delivery regularly.

Threats CCC.Core.Threats
  • CCC.Core.TH07Logs are Tampered With or Deleted
  • CCC.Core.TH09Runtime Logs are Read by Unauthorized Entities
  • CCC.Core.TH10State-change Events are Read by Unauthorized Entities
  • CCC.Core.TH11Publications are Incorrectly Triggered
  • CCC.Core.TH16Publications are Disabled
Threats CCC.K8S.Threats
  • CCC.K8S.TH10Workload Endpoints are Exposed Unintentionally
  • CCC.K8S.TH15Kubernetes Audit Records are Incomplete or Unavailable
Guidelines NIST_800_53
  • AU-2Event Logging
  • AU-6Audit Record Review, Analysis, and Reporting
  • AU-9Protection of Audit Information
  • AU-12Audit Record Generation
CCC.Core.CN04Log All Access and Changesimported

Imported from CCC.Core.Controls

Objective

Ensure that all access attempts are logged to maintain a detailed audit trail for security and compliance purposes.

Assessment Requirements
  • CCC.Core.CN04.AR01

    When administrative access or configuration change is attempted on the service or a child resource, the service MUST log the client identity, time, and result of the attempt.

    Applicability: tlp-cleartlp-greentlp-ambertlp-red

  • CCC.Core.CN04.AR02

    When any attempt is made to modify data on the service or a child resource, the service MUST log the client identity, time, and result of the attempt.

    Applicability: tlp-ambertlp-red

  • CCC.Core.CN04.AR03

    When any attempt is made to read data on the service or a child resource, the service MUST log the client identity, time, and result of the attempt.

    Applicability: tlp-red

Threats CCC.Core.Threats
  • CCC.Core.TH01
Guidelines CCM
  • LOG-08Log Records (Generate audit records containing relevant security information)
CCC.Core.CN07Alert on Unusual Enumeration Activityimported

Imported from CCC.Core.Controls

Objective

Ensure that logs and associated alerts are generated when unusual enumeration activity is detected that may indicate reconnaissance activities.

Assessment Requirements
  • CCC.Core.CN07.AR01

    When enumeration activities are detected, the service MUST publish an event to a monitored channel which includes the client identity, time, and nature of the activity.

    Applicability: tlp-ambertlp-red

    Recommendation: Implement event publication mechanisms and alerts for patterns indicative of enumeration activities, such as repeated access attempts, requests, or liveness probes. Configure alerts to notify security teams of any activities that merit further investigation.

  • CCC.Core.CN07.AR02

    When enumeration activities are detected, the service MUST log the client identity, time, and nature of the activity.

    Applicability: tlp-cleartlp-greentlp-ambertlp-red

    Recommendation: Implement logging mechanisms to capture details of enumeration activities, including client identity, timestamps, and activity nature. Retain logs according to organizational policies, and occasionally review them for patterns that may indicate reconnaissance activities.

Threats CCC.Core.Threats
  • CCC.Core.TH15
Guidelines CCM
  • LOG-05Audit Logs Monitoring and Response (take action on detected anomalies)
  • SEF-05Incident Response Metrics (establish and monitor metrics)
CCC.Core.CN09Ensure Integrity of Access Logsimported

Imported from CCC.Core.Controls

Objective

Ensure that access logs are always recorded to an external location that cannot be manipulated from the context of the service(s) it contains logs for.

Assessment Requirements
  • CCC.Core.CN09.AR01

    When the service is operational, its logs and any child resource logs MUST NOT be accessible from the resource they record access to.

    Applicability: tlp-cleartlp-greentlp-ambertlp-red

  • CCC.Core.CN09.AR02

    When the service is operational, disabling the logs for the service or its child resources MUST NOT be possible without also disabling the corresponding resource.

    Applicability: tlp-cleartlp-greentlp-ambertlp-red

    Recommendation: No normal business operations should disable logs, as this could indicate an attempt to cover up unauthorized access. Ensure that logging mechanisms are tightly integrated with service operations, so that logging cannot be disabled without stopping the service itself.

  • CCC.Core.CN09.AR03

    When the service is operational, any attempt to redirect logs for the service or its child resources MUST NOT be possible without halting operation of the corresponding resource and publishing corresponding events to monitored channels.

    Applicability: tlp-ambertlp-red

    Recommendation: No normal business operations should result in the redirection of logs, as this could indicate an attempt to cover up unauthorized access. Ensure that logging configurations are immutable during service operation so that any changes require stopping the service and publishing corresponding events to monitored channels.

Threats CCC.Core.Threats
  • CCC.Core.TH07
  • CCC.Core.TH09
  • CCC.Core.TH04
Guidelines CCM
  • LOG-02Audit Logs Protection (security and retention)
  • LOG-04Audit Logs Access and Accountability (Restrict audit logs access to authorized personnel)
  • LOG-09Log Protection (protects audit records from unauthorized access)

Encryption

The Encryption group covers entries related to protecting data confidentiality and integrity through cryptographic mechanisms. This includes encryption in transit and at rest, key management, and certificate lifecycle management.

CCC.Core.CN01Encrypt Data for Transmissionimported

Imported from CCC.Core.Controls

Objective

Ensure that all communications are encrypted in transit to protect data integrity and confidentiality.

Assessment Requirements
  • CCC.Core.CN01.AR01

    When a port is exposed for non-SSH network traffic, all traffic MUST include a TLS handshake AND be encrypted using TLS 1.3 or higher.

    Applicability: tlp-greentlp-ambertlp-red

    Recommendation: Most cloud services enable TLS 1.3 by default. Where it is not already set, ensure that your services are configured or updated accordingly.

  • CCC.Core.CN01.AR02

    When a port is exposed for SSH network traffic, all traffic MUST include a SSH handshake AND be encrypted using SSHv2 or higher.

    Applicability: tlp-cleartlp-greentlp-ambertlp-red

    Recommendation: Any time port 22 is exposed, ensure that it has a properly implemented SSH server with SSHv2 enabled and configured with strong ciphers.

  • CCC.Core.CN01.AR03

    When the service receives unencrypted traffic, then it MUST either block the request or automatically redirect it to the secure equivalent.

    Applicability: tlp-greentlp-ambertlp-red

    Recommendation: Review firewall, load balancer, and application configurations to ensure insecure protocols such as HTTP, FTP, and Telnet are not exposed. Where possible, implement automatic redirection to secure protocols such as HTTPS, SFTP, SSH, and regularly scan for protocol drift.

  • CCC.Core.CN01.AR07

    When a port is exposed, the service MUST ensure that the protocol and service officially assigned to that port number by the IANA Service Name and Transport Protocol Port Number Registry, and no other, is run on that port.

    Applicability: tlp-cleartlp-greentlp-ambertlp-red

    Recommendation: Reference the IANA Service Name and Transport Protocol Port Number Registry for more information about correct protocol-to-port assignments. Avoid running non-standard services on well-known ports.

  • CCC.Core.CN01.AR08

    When a service transmits data using TLS, mutual TLS (mTLS) MUST be implemented to require both client and server certificate authentication for all connections.

    Applicability: tlp-ambertlp-red

    Recommendation: Configure mTLS for all endpoints that process or transmit sensitive data. Ensure both client and server certificates are validated and managed securely. Regularly review certificate authorities and automate certificate rotation where possible.

Threats CCC.Core.Threats
  • CCC.Core.TH02
Guidelines CCM
  • CEK-03Data Encryption (in transit and at rest)
  • CEK-04Key Management (use strong encryption)
  • IVS-03Network Security (monitor, encrypt, restrict)
  • IVS-07Migration to Cloud Environments (encrypt when migrating servers)
CCC.Core.CN02Encrypt Data for Storageimported

Imported from CCC.Core.Controls

Objective

Ensure that all data stored is encrypted at rest using strong encryption algorithms.

Assessment Requirements
  • CCC.Core.CN02.AR01

    When data is stored, it MUST be encrypted using the latest industry-standard encryption methods.

    Applicability: tlp-greentlp-ambertlp-red

Threats CCC.Core.Threats
  • CCC.Core.TH01
Guidelines CCM
  • CEK-03Data Encryption (in transit and at rest)
  • CEK-04Key Management (use strong encryption)
  • UEM-08Storage Encryption (on managed endpoint devices)
  • DSP-17
CCC.Core.CN13Minimize Lifetime of Encryption and Authentication Certificatesimported

Imported from CCC.Core.Controls

Objective

Ensure that encryption and authentication certificates have a limited lifetime to reduce the risk of compromise and ensure the use of up-to-date security practices.

Assessment Requirements
  • CCC.Core.CN13.AR01

    When a port is exposed that uses certificate-based encryption, the service MUST only use valid, unexpired certificates issued by a trusted certificate authority.

    Applicability: tlp-cleartlp-greentlp-ambertlp-red

    Recommendation: Track certificate expiration dates and automate certificate renewal where possible. Use certificate management tools to ensure only certificates from trusted authorities are deployed.

  • CCC.Core.CN13.AR02

    When a port is exposed that uses certificate-based encryption, the service MUST rotate active certificates within 180 days of issuance.

    Applicability: tlp-amber

    Recommendation: Track certificate expiration dates and automate certificate renewal where possible. Use certificate management tools to ensure only certificates from trusted authorities are deployed.

  • CCC.Core.CN13.AR03

    When a port is exposed that uses certificate-based encryption, the service MUST rotate active certificates within 90 days of issuance.

    Applicability: tlp-red

    Recommendation: Track certificate expiration dates and automate certificate renewal where possible. Use certificate management tools to ensure only certificates from trusted authorities are deployed.

Threats CCC.Core.Threats
  • CCC.Core.TH18