Payment Card Industry Data Security Standard (PCI DSS) v4.0
The Payment Card Industry Data Security Standard (PCI DSS) is a proprietary information security standard. It's administered by the PCI Security Standards Council, which was founded by American Express, Discover Financial Services, JCB International, MasterCard Worldwide, and Visa Inc. PCI DSS applies to entities that store, process, or transmit cardholder data (CHD) or sensitive authentication data (SAD). This includes, but isn't limited to, merchants, processors, acquirers, issuers, and service providers. The PCI DSS is mandated by the card brands and administered by the Payment Card Industry Security Standards Council.
ProwlerRun this compliance with Prowler
Run in Prowler Cloudprowler kubernetes --compliance pci_4.0_kubernetesRequirements (1586)
1.2.5: Network security controls (NSCs) are configured and maintained.175
1.2.5.1Checks if Ingress resources in Kubernetes are configured to redirect HTTP traffic to HTTPS. The rule is NON_COMPLIANT if one or more Ingress resources do not have an appropriate redirect annotation configured for HTTP to HTTPS redirection. The rule is also NON_COMPLIANT if one or more Ingress resources are forwarding traffic to another non-secure endpoint instead of redirecting to HTTPS.0
Attributes
- Section
1.2.5: Network security controls (NSCs) are configured and maintained.
- Service
API Server
1.2.5.2Checks if Kubernetes Ingress resources are using deprecated SSL protocols for HTTPS communication between Ingress controllers and backend services. This rule is NON_COMPLIANT for an Ingress resource if any 'tls' configuration includes 'SSLv3'.0
Attributes
- Section
1.2.5: Network security controls (NSCs) are configured and maintained.
- Service
API Server
1.2.5.3Checks if Kubernetes Ingress resources are configured to enforce a minimum security policy and cipher suite of TLSv1.2 or greater for TLS connections. This rule is NON_COMPLIANT for an Ingress resource if the specified minimum TLS version is below 'TLS1.2'.0
Attributes
- Section
1.2.5: Network security controls (NSCs) are configured and maintained.
- Service
API Server
1.2.5.4Checks if Kubernetes Ingress resources are using a custom TLS certificate and are configured to use SNI for HTTPS traffic. The rule is NON_COMPLIANT if a custom TLS certificate is associated but the Ingress controller is set up to use a dedicated IP address for SSL termination.0
Attributes
- Section
1.2.5: Network security controls (NSCs) are configured and maintained.
- Service
API Server
1.2.5.5Checks if Kubernetes Ingress resources are enforcing HTTPS for traffic to backend services. The rule is NON_COMPLIANT if 'nginx.ingress.kubernetes.io/ssl-redirect' is set to 'false' or if 'nginx.ingress.kubernetes.io/backend-protocol' is 'http' and 'nginx.ingress.kubernetes.io/force-ssl-redirect' is set to 'off'.0
Attributes
- Section
1.2.5: Network security controls (NSCs) are configured and maintained.
- Service
API Server
1.2.5.6Checks if your Kubernetes Ingress resources enforce HTTPS for HTTP traffic. The rule is NON_COMPLIANT if there are Ingress configurations that allow HTTP traffic without a redirect to HTTPS.0
Attributes
- Section
1.2.5: Network security controls (NSCs) are configured and maintained.
- Service
API Server
1.2.5.7Check if OpenSearch nodes are configured with end-to-end encryption. The rule is NON_COMPLIANT if the TLS encryption between pods is not enabled in the cluster.0
Attributes
- Section
1.2.5: Network security controls (NSCs) are configured and maintained.
- Service
OpenSearch
1.2.5.8Checks whether your Kubernetes Ingress controllers are using custom SSL policies. The rule is only applicable if there are SSL termination configurations in the Ingress resource.0
Attributes
- Section
1.2.5: Network security controls (NSCs) are configured and maintained.
- Service
API Server
1.2.5.9Checks if your Kubernetes Ingress resources use a predefined TLS configuration. The rule is NON_COMPLIANT if the Ingress resource's TLS configuration does not match the specified 'predefinedTLSConfig'.1
Attributes
- Section
1.2.5: Network security controls (NSCs) are configured and maintained.
- Service
API Server
1.2.5.10Checks if your Kubernetes Service of type LoadBalancer is configured with SSL or HTTPS through Ingress or directly with LoadBalancer annotations. The rule is NON_COMPLIANT if there is no SSL or HTTPS configuration present.0
Attributes
- Section
1.2.5: Network security controls (NSCs) are configured and maintained.
- Service
Scheduler
1.2.5.11Checks if Kubernetes clusters have Pod Security Policies (PSP) enabled. The rule is NON_COMPLIANT if a security context is not defined in the pods or the security context does not satisfy the specified security requirements.1
Attributes
- Section
1.2.5: Network security controls (NSCs) are configured and maintained.
- Service
API Server
1.2.5.12Checks whether connections to OpenSearch domains are using HTTPS in Kubernetes. The rule is NON_COMPLIANT if the OpenSearch custom resource 'spec.enforceHTTPS' is not set to 'true' or is 'true' and 'spec.tlsSecurityPolicy' is not configured in the accepted TLS policies.0
Attributes
- Section
1.2.5: Network security controls (NSCs) are configured and maintained.
- Service
OpenSearch
1.2.5.13Check if Kubernetes cluster nodes are encrypted end to end. The rule is NON_COMPLIANT if the encryption between nodes is not enabled for the Kubernetes cluster.0
Attributes
- Section
1.2.5: Network security controls (NSCs) are configured and maintained.
- Service
Core
1.2.5.14Checks if Kubernetes clusters require TLS/SSL encryption for API server connections. The rule is NON_COMPLIANT if the Kubernetes API server has the parameter --tls-security-mode not set to 'always'.1
Attributes
- Section
1.2.5: Network security controls (NSCs) are configured and maintained.
- Service
API Server
1.2.5.15Checks if Kubernetes services are configured to require TLS for communication. The rule is NON_COMPLIANT if any service allows HTTP traffic without enforcing TLS.1
Attributes
- Section
1.2.5: Network security controls (NSCs) are configured and maintained.
- Service
API Server
1.2.5.16Checks if a Kubernetes Deployment uses the FTP protocol for service communication. The rule is NON_COMPLIANT if the Deployment exposes a service with the FTP protocol enabled.0
Attributes
- Section
1.2.5: Network security controls (NSCs) are configured and maintained.
- Service
Core
1.2.5.17Checks if Network Policies or Security Groups in Kubernetes allow unrestricted incoming traffic ('0.0.0.0/0' or '::/0') only for authorized ports and protocols (TCP/UDP). The rule is NON_COMPLIANT if such policies do not specify authorized ports.1
Attributes
- Section
1.2.5: Network security controls (NSCs) are configured and maintained.
- Service
Core
1.2.8: Network security controls (NSCs) are configured and maintained.4718
1.2.8.1Checks if Kubernetes Services are of the type specified in the rule parameter serviceType. The rule returns NON_COMPLIANT if the Service does not match the type configured in the rule parameter.0
Attributes
- Section
1.2.8: Network security controls (NSCs) are configured and maintained.
- Service
Core
1.2.8.2Verifies if a Kubernetes service that exposes a REST API is configured with an SSL certificate. The status is NON_COMPLIANT if the service is not using an SSL certificate for secure communication.1
Attributes
- Section
1.2.8: Network security controls (NSCs) are configured and maintained.
- Service
API Server
1.2.8.3Checks if Kubernetes APIs are associated with Network Policies. The rule is NON_COMPLIANT for a Kubernetes API if it is not associated with a Network Policy.0
Attributes
- Section
1.2.8: Network security controls (NSCs) are configured and maintained.
- Service
API Server
1.2.8.4Checks if Kubernetes Ingress resources are associated with Network Policies. The rule is NON_COMPLIANT if an Ingress resource is not associated with any Network Policy.0
Attributes
- Section
1.2.8: Network security controls (NSCs) are configured and maintained.
- Service
API Server
1.2.8.5Checks if the TLS certificate associated with a Kubernetes Ingress resource is the default self-signed certificate. The rule is NON_COMPLIANT if an Ingress resource uses the default self-signed certificate.1
Attributes
- Section
1.2.8: Network security controls (NSCs) are configured and maintained.
- Service
ETCD
1.2.8.6Checks if the Bitbucket source repository URL contains sign-in credentials. The result is NON_COMPLIANT if the URL contains any sign-in information and COMPLIANT if it doesn't.0
Attributes
- Section
1.2.8: Network security controls (NSCs) are configured and maintained.
- Service
Core
1.2.8.7Checks if Kubernetes Pods have public IP addresses. The rule is NON_COMPLIANT if the Pod's IP address is part of a public IP range.0
Attributes
- Section
1.2.8: Network security controls (NSCs) are configured and maintained.
- Service
Core
1.2.8.8Checks if Kubernetes persistent volumes are accessible to all users. The rule is NON_COMPLIANT if any persistent volumes are accessible to any user (i.e., public).1
Attributes
- Section
1.2.8: Network security controls (NSCs) are configured and maintained.
- Service
RBAC
1.2.8.9Checks if the Kubernetes NetworkPolicy allows all ingress traffic for all pods. The rule is NON_COMPLIANT if any NetworkPolicy allows traffic from all sources.0
Attributes
- Section
1.2.8: Network security controls (NSCs) are configured and maintained.
- Service
Core
1.2.8.10Checks if the status of the Kubernetes deployment is AVAILABLE or UNAVAILABLE after the deployment execution on the pod. The rule is compliant if the status is AVAILABLE. For more information about deployments, see What is a deployment?0
Attributes
- Section
1.2.8: Network security controls (NSCs) are configured and maintained.
- Service
Core
1.2.8.11Checks if Kubernetes Network Policies have 'AllowTraffic' enabled. The rule is NON_COMPLIANT for a Network Policy if 'AllowTraffic' is set to 'true'.0
Attributes
- Section
1.2.8: Network security controls (NSCs) are configured and maintained.
- Service
Core
1.2.8.12Checks if the Kubernetes API server endpoint is not publicly accessible. The rule is NON_COMPLIANT if the endpoint is publicly accessible.1
Attributes
- Section
1.2.8: Network security controls (NSCs) are configured and maintained.
- Service
API Server
1.2.8.13Checks if Kubernetes Services are running in a private network. The rule is NON_COMPLIANT if a Service (ClusterIP, NodePort, or LoadBalancer) has a public endpoint exposed.1
Attributes
- Section
1.2.8: Network security controls (NSCs) are configured and maintained.
- Service
Core
1.2.8.14Checks if Kubernetes Services of type LoadBalancer have associated Ingress resources configured to use TLS certificates from a specified secret. This rule is NON_COMPLIANT if at least 1 LoadBalancer Service has an associated Ingress that is either not configured with a TLS certificate or uses a certificate not from the specified secret.1
Attributes
- Section
1.2.8: Network security controls (NSCs) are configured and maintained.
- Service
API Server
1.2.8.15Checks if Kubernetes Services use TLS certificates provided by cert-manager or another certificate management solution. This rule is only applicable to Services with type LoadBalancer that handle HTTPS traffic, and does not apply to ClusterIP or NodePort Services.1
Attributes
- Section
1.2.8: Network security controls (NSCs) are configured and maintained.
- Service
API Server
1.2.8.16Checks if a Kubernetes cluster has restricted external access settings. The rule is NON_COMPLIANT if the NetworkPolicy does not restrict ingress traffic on critical ports, or if restrictions are missing for services other than the desired ports.1
Attributes
- Section
1.2.8: Network security controls (NSCs) are configured and maintained.
- Service
Core
1.2.8.17This rule prevents incoming SSH requests to the Kubernetes cluster, effectively disabling SSH access to the nodes.0
Attributes
- Section
1.2.8: Network security controls (NSCs) are configured and maintained.
- Service
Core
1.2.8.18Checks if LoadBalancers are associated with an authorized Kubernetes Namespace. The rule is NON_COMPLIANT if LoadBalancers are associated with an unauthorized Namespace.1
Attributes
- Section
1.2.8: Network security controls (NSCs) are configured and maintained.
- Service
API Server
1.2.8.19Checks if the Kubernetes ServiceAccount policy attached to the Pod prohibits public access. If the ServiceAccount policy allows public access, it is NON_COMPLIANT.0
Attributes
- Section
1.2.8: Network security controls (NSCs) are configured and maintained.
- Service
RBAC (Role-Based Access Control)
1.2.8.20Checks if a Kubernetes deployment is using a specific network policies to control pod traffic, where the rule is NON_COMPLIANT if the deployment does not implement network policies for security.1
Attributes
- Section
1.2.8: Network security controls (NSCs) are configured and maintained.
- Service
Core
1.2.8.21Checks if default ports for SSH/RDP ingress traffic are unrestricted in Network Policies. The rule is NON_COMPLIANT if a Network Policy allows ingress from any source IP address for ports 22 (SSH) or 3389 (RDP).0
Attributes
- Section
1.2.8: Network security controls (NSCs) are configured and maintained.
- Service
Core
1.2.8.22Checks if a Kubernetes Network Policy is configured with a user-defined policy for fragmented packets. The rule is NON_COMPLIANT if the default action for fragmented packets does not match the user-defined action in the network policy.0
Attributes
- Section
1.2.8: Network security controls (NSCs) are configured and maintained.
- Service
Core
1.2.8.23Check Kubernetes Network Policies are associated with pod selector rules. This rule is NON_COMPLIANT if no Network Policies are associated with the selected pods, else COMPLIANT if any Network Policy is applied to the pods.1
Attributes
- Section
1.2.8: Network security controls (NSCs) are configured and maintained.
- Service
Core
1.2.8.24Checks if a Kubernetes Network Policy has any ingress or egress rules defined. The policy is considered NON_COMPLIANT if there are no rules specified in the Network Policy.0
Attributes
- Section
1.2.8: Network security controls (NSCs) are configured and maintained.
- Service
Core
1.2.8.25Checks if there are public routes in the Kubernetes network configuration that direct traffic to an external service or endpoint. The rule is NON_COMPLIANT if a network policy allows traffic from pods to external IPs that enable unrestricted access to the Internet.0
Attributes
- Section
1.2.8: Network security controls (NSCs) are configured and maintained.
- Service
Core
1.2.8.26Checks if Kubernetes clusters are running in a private network. The rule is NON_COMPLIANT if the cluster API server endpoint is publicly accessible.0
Attributes
- Section
1.2.8: Network security controls (NSCs) are configured and maintained.
- Service
API Server
1.2.8.27Checks if there are any Kubernetes Network Policies that are not the default Network Policy. The rule is NON_COMPLIANT if there are any Network Policies that are not the default Network Policy.1
Attributes
- Section
1.2.8: Network security controls (NSCs) are configured and maintained.
- Service
Core
1.2.8.28Checks if the Kubernetes Pods running in the cluster are not exposed to the public internet. The rule is NON_COMPLIANT if the Pod's service type is LoadBalancer or NodePort.1
Attributes
- Section
1.2.8: Network security controls (NSCs) are configured and maintained.
- Service
Core
1.2.8.29Checks if the Kubernetes services are not exposed externally. The rule is NON_COMPLIANT if the service type is 'LoadBalancer' or 'NodePort' which makes them accessible externally.1
Attributes
- Section
1.2.8: Network security controls (NSCs) are configured and maintained.
- Service
API Server
1.2.8.30Checks if Kubernetes services have network policies in place to block unauthorized access. The rule is NON_COMPLIANT if network policies are not defined to restrict access to services.1
Attributes
- Section
1.2.8: Network security controls (NSCs) are configured and maintained.
- Service
Core
1.2.8.31Checks if the required network policies are configured to restrict public access for the specified Kubernetes pods. The status is only NON_COMPLIANT when the network policies do not match the predefined rules for public access control.0
Attributes
- Section
1.2.8: Network security controls (NSCs) are configured and maintained.
- Service
API Server
1.2.8.32Verifies if the required network policies for public access restrictions are configured at the cluster level. The rule is NON_COMPLIANT if the configuration does not align with defined policies or defaults for restricting external access.0
Attributes
- Section
1.2.8: Network security controls (NSCs) are configured and maintained.
- Service
Core
1.2.8.33Checks if Kubernetes services are publicly accessible. The rule is NON_COMPLIANT if a Kubernetes service is not listed in the excludedPublicServices parameter and service type is LoadBalancer or NodePort.1
Attributes
- Section
1.2.8: Network security controls (NSCs) are configured and maintained.
- Service
API Server
1.2.8.34Checks if your Kubernetes Persistent Volumes do not allow public access. The rule checks the access modes and security contexts configured for the persistent volume claims and associated pods.1
Attributes
- Section
1.2.8: Network security controls (NSCs) are configured and maintained.
- Service
RBAC
1.2.8.35Checks if your Kubernetes buckets (storage classes or persistent volume claims) do not allow public write access. The rule checks the access policies and permissions defined for the storage resources.0
Attributes
- Section
1.2.8: Network security controls (NSCs) are configured and maintained.
- Service
Core
1.2.8.36Checks if a Kubernetes pod is deployed within a specific namespace or within a list of approved node selectors. The rule is NON_COMPLIANT if a pod is not deployed within the specified namespace or if its node selector does not match the approved criteria.0
Attributes
- Section
1.2.8: Network security controls (NSCs) are configured and maintained.
- Service
Core
1.2.8.37Checks if direct internet access is disabled for a Kubernetes pod. The rule is NON_COMPLIANT if a Kubernetes pod has an external IP assigned, allowing internet access.0
Attributes
- Section
1.2.8: Network security controls (NSCs) are configured and maintained.
- Service
Core
1.2.8.38Checks if a Kubernetes Service Endpoint for the specified service is created for each Kubernetes namespace. The status is NON_COMPLIANT if a namespace does not have an endpoint created for the service.0
Attributes
- Section
1.2.8: Network security controls (NSCs) are configured and maintained.
- Service
API Server
1.2.8.39Checks if there are unused Network Policies. The rule is COMPLIANT if each Network Policy is associated with a namespace. The rule is NON_COMPLIANT if a Network Policy is not associated with any namespace.0
Attributes
- Section
1.2.8: Network security controls (NSCs) are configured and maintained.
- Service
Core
1.2.8.40Checks if DNS resolution from the Accepter/Requester VPC to the private IP is enabled in Kubernetes. A NON_COMPLIANT status is indicated if DNS resolution from the Accepter/Requester VPC to the private IP is not enabled.0
Attributes
- Section
1.2.8: Network security controls (NSCs) are configured and maintained.
- Service
API Server
1.2.8.41Checks if Network Policies in Kubernetes allow unrestricted incoming traffic ('0.0.0.0/0' or '::/0') only for authorized ports. The rule is NON_COMPLIANT if such Network Policies do not have ports specified in the rule parameters.1
Attributes
- Section
1.2.8: Network security controls (NSCs) are configured and maintained.
- Service
Core
1.2.8.42Checks if a Kubernetes NetworkPolicy contains any ingress or egress rules. The policy is NON_COMPLIANT if there are no rules present within the NetworkPolicy.0
Attributes
- Section
1.2.8: Network security controls (NSCs) are configured and maintained.
- Service
API Server
1.2.8.43Checks if a Kubernetes NetworkPolicy has any ingress or egress rules defined. The NetworkPolicy is NON_COMPLIANT if no rules are present.0
Attributes
- Section
1.2.8: Network security controls (NSCs) are configured and maintained.
- Service
API Server
1.2.8.44Checks whether a Kubernetes Network Policy contains any ingress or egress rules. This rule is NON_COMPLIANT if a Network Policy does not contain any ingress or egress rules.0
Attributes
- Section
1.2.8: Network security controls (NSCs) are configured and maintained.
- Service
Core
1.2.8.45Checks if a Kubernetes NetworkPolicy has any ingress or egress rules defined. The NetworkPolicy is considered NON_COMPLIANT if there are no rules present within it.0
Attributes
- Section
1.2.8: Network security controls (NSCs) are configured and maintained.
- Service
API Server
1.2.8.46Checks whether Kubernetes NetworkPolicy contains ingress or egress rules. This policy is COMPLIANT if it contains at least one rule and NON_COMPLIANT otherwise.0
Attributes
- Section
1.2.8: Network security controls (NSCs) are configured and maintained.
- Service
API Server
1.2.8.47Checks if a Kubernetes NetworkPolicy contains any ingress or egress rules. The policy is NON_COMPLIANT if there are no ingress or egress rules present within the NetworkPolicy.0
Attributes
- Section
1.2.8: Network security controls (NSCs) are configured and maintained.
- Service
Core
1.3.1: Network access to and from the cardholder data environment is restricted.5219
1.3.1.1Checks if a Kubernetes Ingress resource is using an Ingress Controller that is compliant with the specified security policies (e.g., a Web Application Firewall). The rule is NON_COMPLIANT if an Ingress resource is not associated with a compliant Ingress Controller or if the Ingress Controller does not meet the security policy criteria defined in the rule parameters.0
Attributes
- Section
1.3.1: Network access to and from the cardholder data environment is restricted.
- Service
API Server
1.3.1.2Checks if Kubernetes Services are of the type specified in the rule parameter serviceType. The rule returns NON_COMPLIANT if the Service does not match the service type configured in the rule parameter.0
Attributes
- Section
1.3.1: Network access to and from the cardholder data environment is restricted.
- Service
Core
1.3.1.3Checks if a Kubernetes Ingress resource is configured with TLS settings. The rule is NON_COMPLIANT if the Ingress does not have an associated TLS certificate.1
Attributes
- Section
1.3.1: Network access to and from the cardholder data environment is restricted.
- Service
API Server
1.3.1.4Checks if Kubernetes Ingress resources are associated with NetworkPolicies. The rule is NON_COMPLIANT for a Kubernetes Ingress if it is not associated with a NetworkPolicy.0
Attributes
- Section
1.3.1: Network access to and from the cardholder data environment is restricted.
- Service
API Server
1.3.1.5Checks if Kubernetes Ingress resources are associated with any network policies. The rule is NON_COMPLIANT if an Ingress resource is not associated with a network policy.0
Attributes
- Section
1.3.1: Network access to and from the cardholder data environment is restricted.
- Service
API Server
1.3.1.6Verifies if the TLS certificate associated with a Kubernetes Ingress resource is a custom certificate. The rule is NON_COMPLIANT if an Ingress resource uses the default or self-signed TLS certificate.1
Attributes
- Section
1.3.1: Network access to and from the cardholder data environment is restricted.
- Service
API Server
1.3.1.7Checks if the Bitbucket source repository URL contains sign-in credentials. The rule is NON_COMPLIANT if the URL contains any sign-in information and COMPLIANT if it doesn't.0
Attributes
- Section
1.3.1: Network access to and from the cardholder data environment is restricted.
- Service
Core
1.3.1.8Checks if Kubernetes pods are accessible from outside the cluster via their services. The rule is NON_COMPLIANT if the service type is LoadBalancer or NodePort, which exposes the pods to the public.1
Attributes
- Section
1.3.1: Network access to and from the cardholder data environment is restricted.
- Service
Core
1.3.1.9Checks if Kubernetes persistent volume snapshots are publicly accessible. The rule is NON_COMPLIANT if any Kubernetes persistent volume snapshots are publicly accessible.1
Attributes
- Section
1.3.1: Network access to and from the cardholder data environment is restricted.
- Service
RBAC
1.3.1.10Checks if the Kubernetes NetworkPolicy allows access for all pods. The rule is NON_COMPLIANT if 'allowAll' is present and set to true.0
Attributes
- Section
1.3.1: Network access to and from the cardholder data environment is restricted.
- Service
API Server
1.3.1.11Checks if the status of a Kubernetes configuration or deployment is healthy (COMPLIANT) or unhealthy (NON_COMPLIANT) after applying the configuration to the pod. The rule is compliant if the pod is running without errors. For more information about pod statuses, see Kubernetes Pod Lifecycle.0
Attributes
- Section
1.3.1: Network access to and from the cardholder data environment is restricted.
- Service
Core
1.3.1.12Checks if Kubernetes Network Policies have 'AllowAllIngress' configured. The rule is NON_COMPLIANT for a Network Policy if 'AllowAllIngress' is set to 'true'.0
Attributes
- Section
1.3.1: Network access to and from the cardholder data environment is restricted.
- Service
Core
1.3.1.13Checks if the Kubernetes API server endpoint is not publicly accessible. The rule is NON_COMPLIANT if the endpoint is publicly accessible.1
Attributes
- Section
1.3.1: Network access to and from the cardholder data environment is restricted.
- Service
API Server
1.3.1.14Checks if Kubernetes clusters are configured with custom network policies. The rule is NON_COMPLIANT for a Kubernetes cluster if it is using the default network policies.1
Attributes
- Section
1.3.1: Network access to and from the cardholder data environment is restricted.
- Service
Core
1.3.1.15Checks if Kubernetes services are within a defined Network Policy. The rule is NON_COMPLIANT if a service is exposed publicly without proper network isolation.1
Attributes
- Section
1.3.1: Network access to and from the cardholder data environment is restricted.
- Service
Core
1.3.1.16Checks if Kubernetes Ingress resources have TLS settings configured to use certificates from a trusted certificate management service. This rule is NON_COMPLIANT if at least 1 Ingress has at least 1 TLS entry that is configured without a certificate or is configured with a certificate different from a trusted certificate management service.1
Attributes
- Section
1.3.1: Network access to and from the cardholder data environment is restricted.
- Service
API Server
1.3.1.17Checks if Ingress resources in Kubernetes use SSL certificates provided by a certificate management solution (e.g., Cert-Manager). To use this rule, ensure an Ingress resource is configured with TLS settings. This rule is only applicable to Ingress resources and does not check LoadBalancer services directly.1
Attributes
- Section
1.3.1: Network access to and from the cardholder data environment is restricted.
- Service
API Server
1.3.1.18Checks if a Kubernetes Cluster has network policies that restrict public access. The rule is NON_COMPLIANT if network policies allow access to any port other than Port 22.0
Attributes
- Section
1.3.1: Network access to and from the cardholder data environment is restricted.
- Service
API Server
1.3.1.19In Kubernetes, the rule INCOMING_SSH_DISABLED corresponds to a NetworkPolicy that restricts incoming traffic on port 22 (SSH) to prevent unauthorized access, reflecting the restricted-ssh policy. This NetworkPolicy can be used to control the flow of traffic to pods in a namespace, effectively disabling incoming SSH access as specified by the rule name.0
Attributes
- Section
1.3.1: Network access to and from the cardholder data environment is restricted.
- Service
API Server
1.3.1.20The rule identifier for Kubernetes resources is commonly the name of the resource, while the rule name can refer to the specific configuration or a higher-level abstraction. For example, in Kubernetes, a Deployment (which could represent multiple instances of pods) could be associated with a label that identifies it, but the deployment itself may have a distinct name. This mirrors the difference between the rule identifier and rule name for EC2 instances in VPC.0
Attributes
- Section
1.3.1: Network access to and from the cardholder data environment is restricted.
- Service
Core
1.3.1.21Checks if Kubernetes services are associated with an authorized namespace. The rule is NON_COMPLIANT if services are linked to an unauthorized namespace.1
Attributes
- Section
1.3.1: Network access to and from the cardholder data environment is restricted.
- Service
API Server
1.3.1.22Checks if the Kubernetes Service account policy attached to the Pod prohibits public access. If the Service account policy allows public access, it is NON_COMPLIANT.0
Attributes
- Section
1.3.1: Network access to and from the cardholder data environment is restricted.
- Service
Core
1.3.1.23Checks if a Kubernetes Pod is allowed access to a specific namespace. The rule is NON_COMPLIANT if the Pod does not have appropriate Network Policies enabling access to the namespace.0
Attributes
- Section
1.3.1: Network access to and from the cardholder data environment is restricted.
- Service
Core
1.3.1.24Checks if default ports for SSH/RDP ingress traffic for Network Policies is unrestricted. The policy is NON_COMPLIANT if a Network Policy allows ingress traffic from any source IP address to ports 22 (SSH) or 3389 (RDP).0
Attributes
- Section
1.3.1: Network access to and from the cardholder data environment is restricted.
- Service
Network Policies
1.3.1.25Checks if a Kubernetes Network Policy is configured with a user defined default action for fragmented packets. The rule is NON_COMPLIANT if the default action for fragmented packets does not match with user defined default action.0
Attributes
- Section
1.3.1: Network access to and from the cardholder data environment is restricted.
- Service
Core
1.3.1.26Check if Kubernetes NetworkPolicy has ingress or egress rules defined. The policy is NON_COMPLIANT if no ingress or egress rules are defined, otherwise it is COMPLIANT if at least one rule exists.0
Attributes
- Section
1.3.1: Network access to and from the cardholder data environment is restricted.
- Service
API Server
1.3.1.27Checks if a Kubernetes NetworkPolicy object has any ingress or egress rules defined. The rule is NON_COMPLIANT if there are no rules in the NetworkPolicy.0
Attributes
- Section
1.3.1: Network access to and from the cardholder data environment is restricted.
- Service
API Server
1.3.1.28Checks if there are public routes in the Kubernetes networking configuration to an Internet Gateway (IGW). The rule is NON_COMPLIANT if a route to an IGW has a destination CIDR block of '0.0.0.0/0' or '::/0' or if a destination CIDR block does not match the rule parameter.0
Attributes
- Section
1.3.1: Network access to and from the cardholder data environment is restricted.
- Service
Core
1.3.1.29Checks if Kubernetes services are configured to only be accessible within a cluster network. The rule is NON_COMPLIANT if a service has a type of LoadBalancer or NodePort, which exposes it publicly.1
Attributes
- Section
1.3.1: Network access to and from the cardholder data environment is restricted.
- Service
Core
1.3.1.30Checks if there are any Kubernetes Network Policies that are not the default Network Policy. The rule is NON_COMPLIANT if there are any Network Policies that are not the default Network Policy.1
Attributes
- Section
1.3.1: Network access to and from the cardholder data environment is restricted.
- Service
Core
1.3.1.31Checks if the Kubernetes services of type LoadBalancer are not publicly accessible. The rule is NON_COMPLIANT if the externalTrafficPolicy field is set to Local, allowing direct access from outside the cluster.1
Attributes
- Section
1.3.1: Network access to and from the cardholder data environment is restricted.
- Service
API Server
1.3.1.32Checks if Kubernetes clusters are not publicly accessible. The rule is NON_COMPLIANT if the service is exposed through a LoadBalancer type service or has a public IP assigned.1
Attributes
- Section
1.3.1: Network access to and from the cardholder data environment is restricted.
- Service
API Server
1.3.1.33Checks if a Kubernetes cluster has 'NetworkPolicy' applied. The rule is NON_COMPLIANT if 'NetworkPolicy' is not enforced or if the configuration.networkPolicy field is 'false'.0
Attributes
- Section
1.3.1: Network access to and from the cardholder data environment is restricted.
- Service
Core
1.3.1.34Checks if Kubernetes services have network policies that block public access to sensitive endpoints. The rule is NON_COMPLIANT if network policies are not in place to restrict public access to these services.1
Attributes
- Section
1.3.1: Network access to and from the cardholder data environment is restricted.
- Service
Core
1.3.1.35Checks if the required Network Policies to restrict public access are configured at the cluster level. The rule is only NON_COMPLIANT when the specified NetworkPolicy settings do not match the desired configuration.0
Attributes
- Section
1.3.1: Network access to and from the cardholder data environment is restricted.
- Service
API Server
1.3.1.36Checks if the required network policies for pod security are configured at the namespace level. The rule is NON_COMPLIANT if the configuration item does not align with one or more settings from the defined policies (or default).1
Attributes
- Section
1.3.1: Network access to and from the cardholder data environment is restricted.
- Service
Core
1.3.1.37Checks if Kubernetes services are publicly accessible. The rule is NON_COMPLIANT if a Kubernetes service is not listed in the excludedPublicServices parameter and service type is LoadBalancer or NodePort.1
Attributes
- Section
1.3.1: Network access to and from the cardholder data environment is restricted.
- Service
API Server
1.3.1.38Checks if your Kubernetes Secrets do not allow public access. The rule checks the Secret's permissions (RBAC), the Namespace isolation, and the network policies.1
Attributes
- Section
1.3.1: Network access to and from the cardholder data environment is restricted.
- Service
RBAC
1.3.1.39Checks if your Kubernetes Persistent Volumes do not allow public write access by evaluating the access modes and appropriate role-based access control (RBAC) settings.1
Attributes
- Section
1.3.1: Network access to and from the cardholder data environment is restricted.
- Service
RBAC
1.3.1.40Checks if a Kubernetes Pod is running within a specific Namespace or within a list of approved Labels. The rule is NON_COMPLIANT if a Pod is not running within the specified Namespace or if its Labels are not included in the parameter list.0
Attributes
- Section
1.3.1: Network access to and from the cardholder data environment is restricted.
- Service
Core
1.3.1.41Checks if direct internet access is disabled for a Kubernetes pod. The rule is NON_COMPLIANT if a pod has an external access configuration or uses LoadBalancer type service.0
Attributes
- Section
1.3.1: Network access to and from the cardholder data environment is restricted.
- Service
Core
1.3.1.42Checks if a Kubernetes Service has an Endpoint for each corresponding Pod in the specified namespace. The rule is NON_COMPLIANT if a Kubernetes Service does not have an Endpoint created for its Pods.0
Attributes
- Section
1.3.1: Network access to and from the cardholder data environment is restricted.
- Service
Core
1.3.1.43Checks if there are unused network policies. The rule is COMPLIANT if each network policy is associated with a pod or service. The rule is NON_COMPLIANT if a network policy is not associated with a pod or service.0
Attributes
- Section
1.3.1: Network access to and from the cardholder data environment is restricted.
- Service
Core
1.3.1.44Checks if DNS resolution between pods in different namespaces within the Kubernetes cluster is enabled. The rule is NON_COMPLIANT if DNS resolution between those pods is not enabled.0
Attributes
- Section
1.3.1: Network access to and from the cardholder data environment is restricted.
- Service
Core
1.3.1.45Verifies that NetworkPolicies are configured to restrict unrestricted incoming traffic ('0.0.0.0/0' or '::/0') and only allow inbound TCP or UDP connections on specified ports. The rule is considered NON_COMPLIANT if any NetworkPolicy does not specify allowed ports.0
Attributes
- Section
1.3.1: Network access to and from the cardholder data environment is restricted.
- Service
Core
1.3.1.46Checks if both network policies in Kubernetes are in 'Active' status. The rule is NON_COMPLIANT if one or both network policies are not 'Active'.0
Attributes
- Section
1.3.1: Network access to and from the cardholder data environment is restricted.
- Service
Core
1.3.1.47Checks if a Kubernetes Network Policy contains any ingress or egress rules. The policy is NON_COMPLIANT if there are no rules specified within the Network Policy.0
Attributes
- Section
1.3.1: Network access to and from the cardholder data environment is restricted.
- Service
Core
1.3.1.48Checks if a Kubernetes NetworkPolicy contains any ingress or egress rules. The policy is NON_COMPLIANT if no rules are present within the NetworkPolicy.0
Attributes
- Section
1.3.1: Network access to and from the cardholder data environment is restricted.
- Service
API Server
1.3.1.49Checks whether a Kubernetes Ingress resource has any associated Ingress rules for routing traffic. This state is considered NON_COMPLIANT if the Ingress resource does not contain any Ingress rules.0
Attributes
- Section
1.3.1: Network access to and from the cardholder data environment is restricted.
- Service
API Server
1.3.1.50Checks if a Kubernetes Network Policy has any ingress or egress rules. The policy is NON_COMPLIANT if there are no rules defined within the Network Policy.0
Attributes
- Section
1.3.1: Network access to and from the cardholder data environment is restricted.
- Service
Core
1.3.1.51Checks whether a Kubernetes NetworkPolicy contains at least one rule. This NetworkPolicy is COMPLIANT if it contains at least one rule, and NON_COMPLIANT otherwise.0
Attributes
- Section
1.3.1: Network access to and from the cardholder data environment is restricted.
- Service
API Server
1.3.1.52Checks if a Kubernetes Network Policy exists within a namespace. The policy is NON_COMPLIANT if there are no Network Policies defined in the namespace.0
Attributes
- Section
1.3.1: Network access to and from the cardholder data environment is restricted.
- Service
Core
1.3.2: Network access to and from the cardholder data environment is restricted.5221
1.3.2.1Checks if a Kubernetes Ingress resource is using an associated NetworkPolicy to control access. The rule is NON_COMPLIANT if a NetworkPolicy is not used or if the used NetworkPolicy does not match the criteria specified in the rule parameter.0
Attributes
- Section
1.3.2: Network access to and from the cardholder data environment is restricted.
- Service
API Server
1.3.2.2Checks if Kubernetes Services are of the type specified in the rule parameter serviceType. The rule returns NON_COMPLIANT if the Service does not match the endpoint type configured in the rule parameter.0
Attributes
- Section
1.3.2: Network access to and from the cardholder data environment is restricted.
- Service
Core
1.3.2.3Verifies if a Kubernetes Ingress resource is configured with TLS settings. The status is NON_COMPLIANT if the Ingress does not have TLS defined, indicating that SSL certificates are not associated.1
Attributes
- Section
1.3.2: Network access to and from the cardholder data environment is restricted.
- Service
API Server
1.3.2.4Checks if Kubernetes services are protected by Network Policies. The rule is NON_COMPLIANT for a Kubernetes service if it is not associated with a Network Policy.1
Attributes
- Section
1.3.2: Network access to and from the cardholder data environment is restricted.
- Service
Core
1.3.2.5Checks if Kubernetes Ingress resources are associated with Network Policies. The rule is NON_COMPLIANT if an Ingress resource is not associated with a Network Policy that restricts traffic.0
Attributes
- Section
1.3.2: Network access to and from the cardholder data environment is restricted.
- Service
API Server
1.3.2.6Checks if the TLS certificate associated with a Kubernetes Ingress resource is the default TLS certificate. The rule is NON_COMPLIANT if an Ingress resource uses the default TLS certificate.1
Attributes
- Section
1.3.2: Network access to and from the cardholder data environment is restricted.
- Service
API Server
1.3.2.7Verifies if the Bitbucket source repository URL includes authentication credentials. The status is NON_COMPLIANT if the URL contains any credentials, otherwise it is COMPLIANT.0
Attributes
- Section
1.3.2: Network access to and from the cardholder data environment is restricted.
- Service
Core
1.3.2.8Checks if Kubernetes pods are running with public IP addresses. The rule is NON_COMPLIANT if the pod's service type is set to 'LoadBalancer' and an external IP is assigned.1
Attributes
- Section
1.3.2: Network access to and from the cardholder data environment is restricted.
- Service
API Server
1.3.2.9Checks if Kubernetes PersistentVolumeClaims (PVCs) are using publicly accessible storage classes. The rule is NON_COMPLIANT if any PVCs are using public storage classes that expose sensitive data.1
Attributes
- Section
1.3.2: Network access to and from the cardholder data environment is restricted.
- Service
RBAC
1.3.2.10Checks if the Kubernetes NetworkPolicy allows access for all clients. The rule is NON_COMPLIANT if 'allow All' is present and set to true.0
Attributes
- Section
1.3.2: Network access to and from the cardholder data environment is restricted.
- Service
API Server
1.3.2.11Checks if the status of a Kubernetes deployment is AVAILABLE or NOT_AVAILABLE after the deployment execution on the cluster. The rule is compliant if the field status is AVAILABLE. For more information about deployments, see What is a deployment?.0
Attributes
- Section
1.3.2: Network access to and from the cardholder data environment is restricted.
- Service
Core
1.3.2.12Checks if Kubernetes Cluster has 'AutoAcceptSharedAttachments' enabled for network routing. The rule is NON_COMPLIANT for a Cluster if 'AutoAcceptSharedAttachments' is set to 'enable'.0
Attributes
- Section
1.3.2: Network access to and from the cardholder data environment is restricted.
- Service
Core
1.3.2.13Checks if the Kubernetes API server endpoint is configured to be private and not publicly accessible. The rule is NON_COMPLIANT if the endpoint is accessible from the public internet.1
Attributes
- Section
1.3.2: Network access to and from the cardholder data environment is restricted.
- Service
API Server
1.3.2.14Checks if Kubernetes pods are configured with a custom network policy. The rule is NON_COMPLIANT for a pod if it is using the default network policy.1
Attributes
- Section
1.3.2: Network access to and from the cardholder data environment is restricted.
- Service
Core
1.3.2.15Checks if Kubernetes OpenSearch deployments are within a Kubernetes cluster and not exposed through a public service. The rule is NON_COMPLIANT if an OpenSearch deployment is exposed via a LoadBalancer service type.0
Attributes
- Section
1.3.2: Network access to and from the cardholder data environment is restricted.
- Service
Core
1.3.2.16Verifies if Kubernetes Ingress resources are configured with TLS settings that utilize certificates from a configured certificate manager, such as Cert-Manager. The rule is NON_COMPLIANT if at least 1 Ingress resource has at least 1 rule that is configured without a TLS certificate or is configured with a certificate that is not managed by the certificate manager.1
Attributes
- Section
1.3.2: Network access to and from the cardholder data environment is restricted.
- Service
API Server
1.3.2.17Checks if the Kubernetes Ingress uses SSL certificates provided by a Certificate Manager. To use this rule, configure an Ingress resource with SSL or HTTPS settings. This rule is only applicable to Ingress resources. This rule does not check Services of type NodePort or ClusterIP.0
Attributes
- Section
1.3.2: Network access to and from the cardholder data environment is restricted.
- Service
API Server
1.3.2.18Checks if a Kubernetes account has network policies configured to prevent public access. The rule is NON_COMPLIANT if any network policies allow traffic from outside the cluster or if services other than Port 22 are exposed without proper restrictions.1
Attributes
- Section
1.3.2: Network access to and from the cardholder data environment is restricted.
- Service
Core
1.3.2.19The Kubernetes equivalent of this rule involves creating a NetworkPolicy that restricts incoming SSH traffic (port 22) to pods, effectively disabling SSH access for incoming connections. The rule identifier is designed to prevent unauthorized access to the service running in the cluster.0
Attributes
- Section
1.3.2: Network access to and from the cardholder data environment is restricted.
- Service
API Server
1.3.2.20The rule identifier (INSTANCES_IN_VPC) represents a specific rule for managing instances in a VPC, while the rule name (ec2-instances-in-vpc) provides a human-readable label for the same rule within a Kubernetes context. This can be associated with network policies or security groups managing pod communication within a cluster.0
Attributes
- Section
1.3.2: Network access to and from the cardholder data environment is restricted.
- Service
API Server
1.3.2.21Checks if Kubernetes services are attached to authorized namespaces. The rule is NON_COMPLIANT if services are attached to unauthorized namespaces.1
Attributes
- Section
1.3.2: Network access to and from the cardholder data environment is restricted.
- Service
API Server
1.3.2.22Checks if the Kubernetes Pod's NetworkPolicy prevents public access to the Pods. If the NetworkPolicy allows public access, it is considered NON_COMPLIANT.0
Attributes
- Section
1.3.2: Network access to and from the cardholder data environment is restricted.
- Service
Core
1.3.2.23Checks if a Kubernetes deployment is configured to run within a specified network policy. The rule is NON_COMPLIANT if the deployment is not using the appropriate network policy to restrict access to the cluster.1
Attributes
- Section
1.3.2: Network access to and from the cardholder data environment is restricted.
- Service
Core
1.3.2.24Checks if the Kubernetes NetworkPolicy allows unrestricted ingress traffic on ports 22 (SSH) and 3389 (RDP) from any source IP. The rule is NON_COMPLIANT if a NetworkPolicy permits ingress on these ports without restrictions.0
Attributes
- Section
1.3.2: Network access to and from the cardholder data environment is restricted.
- Service
API Server
1.3.2.25Checks if a Kubernetes NetworkPolicy is configured with a user-defined action for fragmented packets. The rule is NON_COMPLIANT if the action for fragmented packets does not match the user-defined default action.0
Attributes
- Section
1.3.2: Network access to and from the cardholder data environment is restricted.
- Service
API Server
1.3.2.26Verify if a Kubernetes NetworkPolicy is associated with at least one ingress or egress rule. The policy is NON_COMPLIANT if there are no ingress or egress rules defined, otherwise COMPLIANT if at least one rule exists.0
Attributes
- Section
1.3.2: Network access to and from the cardholder data environment is restricted.
- Service
API Server
1.3.2.27Checks if a Kubernetes Network Policy contains ingress or egress rules. The policy is NON_COMPLIANT if there are no rules defined in the Network Policy.0
Attributes
- Section
1.3.2: Network access to and from the cardholder data environment is restricted.
- Service
Core
1.3.2.28Verifies if there are Kubernetes services with type LoadBalancer that expose ports to external traffic. The status is NON_COMPLIANT if a service allows unrestricted access (i.e., has '0.0.0.0/0' in its ingress rules) or if the service does not comply with the specified network policies.1
Attributes
- Section
1.3.2: Network access to and from the cardholder data environment is restricted.
- Service
Core
1.3.2.29Checks if Kubernetes pods are running inside a Kubernetes cluster network (VPC equivalent). The rule is NON_COMPLIANT if a pod is exposed via a public IP address or LoadBalancer service type without appropriate network policies.1
Attributes
- Section
1.3.2: Network access to and from the cardholder data environment is restricted.
- Service
Core
1.3.2.30Checks if there are any Kubernetes NetworkPolicies that are not the default NetworkPolicy. The rule is NON_COMPLIANT if there are any NetworkPolicies that are not the default NetworkPolicy.0
Attributes
- Section
1.3.2: Network access to and from the cardholder data environment is restricted.
- Service
Core
1.3.2.31Checks if the Kubernetes Database (e.g., PostgreSQL, MySQL) instances are not publicly accessible. The rule is NON_COMPLIANT if the service type is LoadBalancer or Ingress and has an external IP.0
Attributes
- Section
1.3.2: Network access to and from the cardholder data environment is restricted.
- Service
Core
1.3.2.32Checks if Kubernetes clusters are not publicly accessible. The rule is NON_COMPLIANT if the service is exposed via a LoadBalancer type with an external IP address.1
Attributes
- Section
1.3.2: Network access to and from the cardholder data environment is restricted.
- Service
API Server
1.3.2.33Checks if a Kubernetes Cluster has 'Network Policy' enabled to restrict pod communication. The rule is NON_COMPLIANT if 'networkPolicy' is not enabled or if the Network Policy configuration field is 'false'.0
Attributes
- Section
1.3.2: Network access to and from the cardholder data environment is restricted.
- Service
Core
1.3.2.34Checks if Kubernetes Secrets have restrictive access control policies. The rule is NON_COMPLIANT if Secrets are not configured with appropriate role-based access controls (RBAC) to restrict access.1
Attributes
- Section
1.3.2: Network access to and from the cardholder data environment is restricted.
- Service
RBAC
1.3.2.35Checks if the required network policies are configured at the namespace level. The rule is only NON_COMPLIANT when the network policies defined do not match the corresponding settings in the Kubernetes configuration.1
Attributes
- Section
1.3.2: Network access to and from the cardholder data environment is restricted.
- Service
Core
1.3.2.36Checks if the required network policies are configured at the namespace level. The rule is NON_COMPLIANT if the configuration item does not match one or more settings from parameters (or default).0
Attributes
- Section
1.3.2: Network access to and from the cardholder data environment is restricted.
- Service
API Server
1.3.2.37Checks if Kubernetes services are publicly accessible. The rule is NON_COMPLIANT if a Kubernetes service is not listed in the excludedPublicServices parameter and service type is LoadBalancer or NodePort.1
Attributes
- Section
1.3.2: Network access to and from the cardholder data environment is restricted.
- Service
API Server
1.3.2.38Checks if your Kubernetes PersistentVolumeClaims do not allow public access. The rule verifies the access modes and any role-based access control (RBAC) policies applied to the persistent volumes.1
Attributes
- Section
1.3.2: Network access to and from the cardholder data environment is restricted.
- Service
RBAC
1.3.2.39Checks if your Kubernetes Persistent Volume Claims (PVCs) do not allow public write access. The rule examines the access modes defined in the PVC, the associated Persistent Volumes (PVs), and the underlying StorageClass configurations to ensure they do not permit public write operations.1
Attributes
- Section
1.3.2: Network access to and from the cardholder data environment is restricted.
- Service
RBAC
1.3.2.40Checks if a Kubernetes pod is deployed within a specific namespace or within a list of approved network policies. The rule is NON_COMPLIANT if a pod is not deployed within the specified namespace or if the applied network policy does not match the approved list.1
Attributes
- Section
1.3.2: Network access to and from the cardholder data environment is restricted.
- Service
Core
1.3.2.41Checks if direct internet access is disabled for a Kubernetes Pod. The rule is NON_COMPLIANT if a Pod is configured with a public IP or can communicate with the internet directly.0
Attributes
- Section
1.3.2: Network access to and from the cardholder data environment is restricted.
- Service
Core
1.3.2.42Checks if a Kubernetes Service has an Endpoints object created for each defined Service. The rule is NON_COMPLIANT if a Kubernetes Service does not have an Endpoints object created.0
Attributes
- Section
1.3.2: Network access to and from the cardholder data environment is restricted.
- Service
Core
1.3.2.43Checks if there are unused network policies in Kubernetes. The rule is COMPLIANT if each network policy is associated with a pod or namespace. The rule is NON_COMPLIANT if a network policy is not associated with a pod or namespace.0
Attributes
- Section
1.3.2: Network access to and from the cardholder data environment is restricted.
- Service
Core
1.3.2.44Checks if DNS resolution from Kubernetes cluster to private IP is enabled. The rule is NON_COMPLIANT if DNS resolution from Kubernetes cluster to private IP is not enabled.0
Attributes
- Section
1.3.2: Network access to and from the cardholder data environment is restricted.
- Service
Core
1.3.2.45Checks if Network Policies or Security Groups in Kubernetes allow unrestricted incoming traffic ('0.0.0.0/0') only for TCP or UDP connections on authorized ports. The rule is NON_COMPLIANT if such policies or configurations do not restrict to specified ports.1
Attributes
- Section
1.3.2: Network access to and from the cardholder data environment is restricted.
- Service
Core
1.3.2.46Verifies if both Kubernetes cluster nodes in a specified node pool are in Ready status. The rule is NON_COMPLIANT if one or more nodes are in NotReady status.0
Attributes
- Section
1.3.2: Network access to and from the cardholder data environment is restricted.
- Service
Core
1.3.2.47Checks if a Kubernetes Network Policy contains any ingress or egress rules. The policy is NON_COMPLIANT if there are no rules defined within the Network Policy.0
Attributes
- Section
1.3.2: Network access to and from the cardholder data environment is restricted.
- Service
Core
1.3.2.48Checks if a Kubernetes NetworkPolicy contains any ingress or egress rules. The NetworkPolicy is NON_COMPLIANT if no ingress or egress rules are present.0
Attributes
- Section
1.3.2: Network access to and from the cardholder data environment is restricted.
- Service
API Server
1.3.2.49Checks whether a Kubernetes Network Policy contains any ingress or egress rules. This policy is NON_COMPLIANT if a Network Policy does not contain any ingress or egress rules.0
Attributes
- Section
1.3.2: Network access to and from the cardholder data environment is restricted.
- Service
Core
1.3.2.50Checks if the Network Policies in the Kubernetes cluster contain any ingress or egress rules. The policy is marked NON_COMPLIANT if there are no rules present within a Network Policy.0
Attributes
- Section
1.3.2: Network access to and from the cardholder data environment is restricted.
- Service
Core
1.3.2.51Checks whether the Kubernetes NetworkPolicy includes at least one ingress or egress rule. This policy is COMPLIANT if it contains at least one rule and NON_COMPLIANT otherwise.0
Attributes
- Section
1.3.2: Network access to and from the cardholder data environment is restricted.
- Service
API Server
1.3.2.52Checks if a Kubernetes NetworkPolicy contains any ingress or egress rules. The policy is NON_COMPLIANT if there are no ingress or egress rules defined within the NetworkPolicy.0
Attributes
- Section
1.3.2: Network access to and from the cardholder data environment is restricted.
- Service
API Server
1.4.1: Network connections between trusted and untrusted networks are controlled.103
1.4.1.1Checks if a Kubernetes Ingress resource is using an NGINX Ingress Controller with a specified set of annotations for WAF rules. The rule is NON_COMPLIANT if an Ingress resource does not use the specified NGINX Ingress Controller or if the associated WAF settings do not match those defined in the rule parameters.0
Attributes
- Section
1.4.1: Network connections between trusted and untrusted networks are controlled.
- Service
API Server
1.4.1.2Checks if Kubernetes Services are of the type specified in the rule parameter serviceType. The rule returns NON_COMPLIANT if the Service does not match the service type configured in the rule parameter.0
Attributes
- Section
1.4.1: Network connections between trusted and untrusted networks are controlled.
- Service
Core
1.4.1.3Checks if Kubernetes clusters are configured with a custom network policy. The rule is NON_COMPLIANT for a Kubernetes deployment if it is using the default network policy.1
Attributes
- Section
1.4.1: Network connections between trusted and untrusted networks are controlled.
- Service
Core
1.4.1.4The rule identifier INSTANCES_IN_VPC and rule name ec2-instances-in-vpc represent configurations that allow EC2 instances within a specific Virtual Private Cloud (VPC) to communicate with each other. In Kubernetes, a similar concept entails configuring network policies that control traffic between pods within a namespace or cluster, ensuring that only authorized communications are permitted.0
Attributes
- Section
1.4.1: Network connections between trusted and untrusted networks are controlled.
- Service
Core
1.4.1.5Checks if network policies are enforced for authorized namespaces in Kubernetes. The rule is NON_COMPLIANT if network policies are applied to unauthorized namespaces.1
Attributes
- Section
1.4.1: Network connections between trusted and untrusted networks are controlled.
- Service
Core
1.4.1.6Check if there are public routes in the route table in Kubernetes. The rule is NON_COMPLIANT if there is an ingress rule allowing traffic to pod IPs or services exposed to the internet with a target CIDR block of '0.0.0.0/0' or if the ingress rule does not match the specified parameters.0
Attributes
- Section
1.4.1: Network connections between trusted and untrusted networks are controlled.
- Service
Core
1.4.1.7Checks if Kubernetes cluster has network policies enabled. The rule is NON_COMPLIANT if network policies are not enabled or if any namespace does not have at least one network policy configured.1
Attributes
- Section
1.4.1: Network connections between trusted and untrusted networks are controlled.
- Service
Core
1.4.1.8Checks if a Kubernetes Pod is deployed within a specified namespace or within a list of approved labels. The rule is NON_COMPLIANT if a Pod is not deployed within the specified namespace or if its labels do not match the approved list.0
Attributes
- Section
1.4.1: Network connections between trusted and untrusted networks are controlled.
- Service
Core
1.4.1.9Verifies that DNS resolution is enabled for services within the Kubernetes cluster and that pods can resolve private IPs appropriately. The rule is NON_COMPLIANT if DNS resolution from a pod in one namespace to a service in another namespace using private IP addresses is not enabled.0
Attributes
- Section
1.4.1: Network connections between trusted and untrusted networks are controlled.
- Service
Core
1.4.1.10Checks if both Kubernetes network connections (e.g., ingress controllers or service mesh tunnels) are healthy and operational. The rule is NON_COMPLIANT if one or both connections report an unhealthy status.0
Attributes
- Section
1.4.1: Network connections between trusted and untrusted networks are controlled.
- Service
Core
1.4.2: Network connections between trusted and untrusted networks are controlled.4913
1.4.2.1Checks if a Kubernetes Ingress resource is using a configured Network Policy. The rule is NON_COMPLIANT if no Network Policy is applied to the Ingress or if the applied Network Policy does not match the expected configuration defined in the rule parameters.0
Attributes
- Section
1.4.2: Network connections between trusted and untrusted networks are controlled.
- Service
API Server
1.4.2.2Checks if Kubernetes Services are of the type specified in the rule parameter serviceType. The rule returns NON_COMPLIANT if the Service does not match the type configured in the rule parameter.0
Attributes
- Section
1.4.2: Network connections between trusted and untrusted networks are controlled.
- Service
Core
1.4.2.3Checks if a Kubernetes Ingress resource has an associated TLS secret. The rule is NON_COMPLIANT if the Ingress does not have a defined TLS configuration.0
Attributes
- Section
1.4.2: Network connections between trusted and untrusted networks are controlled.
- Service
API Server
1.4.2.4Checks if Kubernetes APIs are associated with Network Policies. The rule is NON_COMPLIANT for a Kubernetes API if it is not associated with a Network Policy.0
Attributes
- Section
1.4.2: Network connections between trusted and untrusted networks are controlled.
- Service
Core
1.4.2.5Checks if Kubernetes Ingress resources are associated with a Network Policy. The rule is NON_COMPLIANT if an Ingress resource is not associated with any Network Policy.0
Attributes
- Section
1.4.2: Network connections between trusted and untrusted networks are controlled.
- Service
Core
1.4.2.6Checks if the certificate associated with a Kubernetes Ingress resource is the default SSL certificate. The rule is NON_COMPLIANT if an Ingress resource uses the default SSL certificate instead of a custom one.0
Attributes
- Section
1.4.2: Network connections between trusted and untrusted networks are controlled.
- Service
API Server
1.4.2.7Checks if the Bitbucket source repository URL contains sign-in credentials or not. The rule is NON_COMPLIANT if the URL contains any sign-in information and COMPLIANT if it doesn't.0
Attributes
- Section
1.4.2: Network connections between trusted and untrusted networks are controlled.
- Service
Core
1.4.2.8Checks if Kubernetes services are exposed to the public. The rule is NON_COMPLIANT if the service type is set to LoadBalancer and it has an external IP address.1
Attributes
- Section
1.4.2: Network connections between trusted and untrusted networks are controlled.
- Service
API Server
1.4.2.9Checks if Kubernetes persistent volume snapshots are public. The rule is NON_COMPLIANT if any Kubernetes persistent volume snapshots are public.0
Attributes
- Section
1.4.2: Network connections between trusted and untrusted networks are controlled.
- Service
Core
1.4.2.10Checks if the Kubernetes NetworkPolicy allows all Pods to communicate with each other. The policy is NON_COMPLIANT if 'allowAll' is present and set to true.0
Attributes
- Section
1.4.2: Network connections between trusted and untrusted networks are controlled.
- Service
API Server
1.4.2.11Checks if the status of the Kubernetes job execution is COMPLETE or FAILED after the job execution on the pod. The job is compliant if the field status is COMPLETE.0
Attributes
- Section
1.4.2: Network connections between trusted and untrusted networks are controlled.
- Service
Kubernetes Jobs
1.4.2.12Checks if Kubernetes Network Policies have 'Ingress' rules set to allow traffic from specific namespaces. The rule is NON_COMPLIANT for a Network Policy if 'Ingress' rules allow traffic from any source.0
Attributes
- Section
1.4.2: Network connections between trusted and untrusted networks are controlled.
- Service
Core
1.4.2.13Checks if the Kubernetes API server endpoint is not publicly accessible. The rule is NON_COMPLIANT if the endpoint is publicly accessible.1
Attributes
- Section
1.4.2: Network connections between trusted and untrusted networks are controlled.
- Service
API Server
1.4.2.14Checks if Kubernetes clusters are running in a private network. The rule is NON_COMPLIANT if a Kubernetes service has a public IP address exposed.1
Attributes
- Section
1.4.2: Network connections between trusted and untrusted networks are controlled.
- Service
Core
1.4.2.15Checks if Kubernetes Ingress resources are configured to use TLS certificates from a trusted certificate provider (like Cert Manager). This rule is NON_COMPLIANT if at least 1 Ingress resource has at least 1 HTTPS entry that is configured without a TLS certificate or is configured with a certificate not issued by a trusted certificate authority.1
Attributes
- Section
1.4.2: Network connections between trusted and untrusted networks are controlled.
- Service
API Server
1.4.2.17Checks if an account in Kubernetes has network policies that restrict public access. The rule is NON_COMPLIANT if AllowAllIngress is true, or if true, ports other than Port 22 are listed in IngressRules.0
Attributes
- Section
1.4.2: Network connections between trusted and untrusted networks are controlled.
- Service
Core
1.4.2.18The rule identifier INCOMING_SSH_DISABLED indicates that incoming SSH traffic is disabled, while the rule name restricted-ssh suggests a restriction on SSH access.0
Attributes
- Section
1.4.2: Network connections between trusted and untrusted networks are controlled.
- Service
Network Policy
1.4.2.19Checks if Kubernetes Ingress Controllers are attached to an authorized namespace. The rule is NON_COMPLIANT if Ingress Controllers are attached to an unauthorized namespace.0
Attributes
- Section
1.4.2: Network connections between trusted and untrusted networks are controlled.
- Service
Core
1.4.2.20Checks if the Kubernetes Pod Security Policy attached to the Pod resource prohibits public access. If the Pod Security Policy allows public access it is NON_COMPLIANT.0
Attributes
- Section
1.4.2: Network connections between trusted and untrusted networks are controlled.
- Service
Core
1.4.2.21Checks if a Kubernetes Pod is allowed access to a virtual private cloud (VPC). The rule is NON_COMPLIANT if the Pod does not specify a VPC network (using the appropriate CNI plugin).0
Attributes
- Section
1.4.2: Network connections between trusted and untrusted networks are controlled.
- Service
Core
1.4.2.22Checks if Kubernetes network policies allow unrestricted ingress traffic for SSH (port 22) and RDP (port 3389) to the specified pods. The rule is NON_COMPLIANT if a network policy does not restrict ingress traffic from certain CIDR blocks for these ports.0
Attributes
- Section
1.4.2: Network connections between trusted and untrusted networks are controlled.
- Service
API Server
1.4.2.23Checks if a Kubernetes NetworkPolicy is configured with a user-defined ingress or egress rule that includes specific handling of fragmented packets. The rule is NON_COMPLIANT if the handling of fragmented packets does not match the user-defined rule.0
Attributes
- Section
1.4.2: Network connections between trusted and untrusted networks are controlled.
- Service
API Server
1.4.2.24Check if a Kubernetes Network Policy is associated with PodSelectors that define stateful or stateless traffic rules. This rule is NON_COMPLIANT if no PodSelectors are defined for the Network Policy, otherwise it is COMPLIANT if any PodSelector exists.0
Attributes
- Section
1.4.2: Network connections between trusted and untrusted networks are controlled.
- Service
Core
1.4.2.25Checks if a Kubernetes NetworkPolicy contains ingress or egress rules. The policy is NON_COMPLIANT if there are no rules defined in a NetworkPolicy.0
Attributes
- Section
1.4.2: Network connections between trusted and untrusted networks are controlled.
- Service
API Server
1.4.2.26Checks for public routes in the Kubernetes network configuration. The rule is NON_COMPLIANT if a service is exposed to the internet with a LoadBalancer or NodePort type that allows access to all IP ranges (0.0.0.0/0 or ::/0) without restrictions on CIDR blocks.1
Attributes
- Section
1.4.2: Network connections between trusted and untrusted networks are controlled.
- Service
Core
1.4.2.27Checks if Kubernetes Elasticsearch clusters are running within a Kubernetes cluster with no public access. The rule is NON_COMPLIANT if an Elasticsearch service endpoint is publicly accessible.0
Attributes
- Section
1.4.2: Network connections between trusted and untrusted networks are controlled.
- Service
Kubernetes Elasticsearch
1.4.2.28Checks if there are any Kubernetes Network Policies that are not the default Network Policy. The rule is NON_COMPLIANT if there are any Network Policies that are not the default Network Policy.1
Attributes
- Section
1.4.2: Network connections between trusted and untrusted networks are controlled.
- Service
Core
1.4.2.29Checks if the Kubernetes databases are not publicly accessible. The rule is NON_COMPLIANT if the service is exposed through a LoadBalancer type or NodePort type which allows external traffic.0
Attributes
- Section
1.4.2: Network connections between trusted and untrusted networks are controlled.
- Service
Core
1.4.2.30Checks if Kubernetes clusters are not publicly accessible. The rule is NON_COMPLIANT if the externalIPs field is set in the Service configuration.1
Attributes
- Section
1.4.2: Network connections between trusted and untrusted networks are controlled.
- Service
API Server
1.4.2.31Checks if a Kubernetes cluster has the NetworkPolicy enabled for enhanced security. The rule is NON_COMPLIANT if NetworkPolicy is not enabled or if there are no defined ingress/egress rules that enforce strict network traffic controls.0
Attributes
- Section
1.4.2: Network connections between trusted and untrusted networks are controlled.
- Service
Core
1.4.2.32Checks if Kubernetes Services have `spec.type` set to `ClusterIP` to restrict external access. The rule is NON_COMPLIANT if `spec.type` is set to `NodePort` or `LoadBalancer`, allowing external access.1
Attributes
- Section
1.4.2: Network connections between trusted and untrusted networks are controlled.
- Service
API Server
1.4.2.33Checks if the required NetworkPolicy settings for public access are configured at the namespace level in Kubernetes. The rule is only NON_COMPLIANT when the NetworkPolicy does not restrict traffic accordingly to the desired configuration.0
Attributes
- Section
1.4.2: Network connections between trusted and untrusted networks are controlled.
- Service
Core
1.4.2.34Verifies that the necessary Kubernetes Network Policy measures are enforced at the cluster level. The rule is NON_COMPLIANT if the network policies do not align with the specified requirements or defaults.1
Attributes
- Section
1.4.2: Network connections between trusted and untrusted networks are controlled.
- Service
Core
1.4.2.35Checks if Kubernetes ConfigMaps and Secrets are publicly accessible. The rule is NON_COMPLIANT if a ConfigMap or Secret is not listed in the excludedPublicConfigMaps and excludedPublicSecrets parameters and is exposed through a public service.1
Attributes
- Section
1.4.2: Network connections between trusted and untrusted networks are controlled.
- Service
RBAC
1.4.2.36Checks if your Kubernetes Pods do not allow unauthorized access by verifying Network Policies, Pod Security Policies, and Role-Based Access Control (RBAC) settings.1
Attributes
- Section
1.4.2: Network connections between trusted and untrusted networks are controlled.
- Service
RBAC
1.4.2.37Checks if your Kubernetes Persistent Volumes do not allow public write access. The rule checks the Volume Permissions, StorageClass settings, and Role-Based Access Control (RBAC) configurations.1
Attributes
- Section
1.4.2: Network connections between trusted and untrusted networks are controlled.
- Service
RBAC
1.4.2.38Checks if a Kubernetes pod is deployed in a specific namespace and if its node is part of an approved node pool. The rule is NON_COMPLIANT if a pod is not deployed within the specified namespace or if its node is not included in the parameter list of approved node pools.0
Attributes
- Section
1.4.2: Network connections between trusted and untrusted networks are controlled.
- Service
Core
1.4.2.39Checks if direct internet access is disabled for a Kubernetes pod. The rule is NON_COMPLIANT if a pod is internet-enabled (i.e., has an external IP or is not using a NetworkPolicy to restrict internet access).0
Attributes
- Section
1.4.2: Network connections between trusted and untrusted networks are controlled.
- Service
Core
1.4.2.40Checks if Kubernetes Endpoints for the service specified are created for each namespace. The rule is NON_COMPLIANT if a namespace doesn't have an Endpoint created for the specified service.0
Attributes
- Section
1.4.2: Network connections between trusted and untrusted networks are controlled.
- Service
Core
1.4.2.41Checks if there are unused network policies. The rule is COMPLIANT if each network policy is associated with a pod or namespace. The rule is NON_COMPLIANT if a network policy is not associated with a pod or namespace.0
Attributes
- Section
1.4.2: Network connections between trusted and untrusted networks are controlled.
- Service
Core
1.4.2.42Checks if DNS resolution from the Kubernetes pod network to the service's private IP is enabled. The rule is NON_COMPLIANT if DNS resolution from the pod network to the service's private IP is not enabled.0
Attributes
- Section
1.4.2: Network connections between trusted and untrusted networks are controlled.
- Service
Core
1.4.2.43Validates that Kubernetes NetworkPolicies permit only specific ingress traffic, disallowing unrestricted access ('0.0.0.0/0' or '::/0') and restricting allowed protocols (TCP or UDP) to defined ports. A NetworkPolicy is deemed NON_COMPLIANT if it allows access on ports that are not specified in the policy criteria.1
Attributes
- Section
1.4.2: Network connections between trusted and untrusted networks are controlled.
- Service
Core
1.4.2.44Checks if both Kubernetes network interfaces (e.g., pod network and service network) are operational. The rule is NON_COMPLIANT if one or both interfaces are not responding.0
Attributes
- Section
1.4.2: Network connections between trusted and untrusted networks are controlled.
- Service
Core
1.4.2.45Checks if a Kubernetes Network Policy contains any ingress or egress rules. The policy is NON_COMPLIANT if there are no rules present within the policy.0
Attributes
- Section
1.4.2: Network connections between trusted and untrusted networks are controlled.
- Service
Core
1.4.2.46Checks if a Kubernetes Network Policy defines any ingress or egress rules. The policy is NON_COMPLIANT if no rules are present within the Network Policy.0
Attributes
- Section
1.4.2: Network connections between trusted and untrusted networks are controlled.
- Service
Core
1.4.2.47Checks whether a Kubernetes NetworkPolicy contains any ingress or egress rules. This policy is NON_COMPLIANT if a NetworkPolicy does not contain any rules.0
Attributes
- Section
1.4.2: Network connections between trusted and untrusted networks are controlled.
- Service
API Server
1.4.2.48Checks if Kubernetes Network Policies contain any rules. The policy is NON_COMPLIANT if there are no rules present within a Kubernetes Network Policy.0
Attributes
- Section
1.4.2: Network connections between trusted and untrusted networks are controlled.
- Service
Core
1.4.2.49Checks whether an Ingress resource in Kubernetes has defined annotations for security policies. This Ingress is COMPLIANT if it includes at least one security policy annotation and NON_COMPLIANT otherwise.0
Attributes
- Section
1.4.2: Network connections between trusted and untrusted networks are controlled.
- Service
API Server
1.4.2.50Checks if a Kubernetes Network Policy is defined for a namespace. The policy is NON_COMPLIANT if there are no Network Policies present within the namespace.0
Attributes
- Section
1.4.2: Network connections between trusted and untrusted networks are controlled.
- Service
Core
1.4.3: Network connections between trusted and untrusted networks are controlled.30
1.4.3.1Checks if a Kubernetes NetworkPolicy is configured with a user-defined default action for fragmented packets. The rule is NON_COMPLIANT if the default action for fragmented packets does not match the user-defined default action.0
Attributes
- Section
1.4.3: Network connections between trusted and untrusted networks are controlled.
- Service
Core
1.4.3.2Checks if a Kubernetes Network Policy is configured with a user-defined default action for ingress and egress traffic. This rule is NON_COMPLIANT if the default action for traffic does not match the user-defined default action.0
Attributes
- Section
1.4.3: Network connections between trusted and untrusted networks are controlled.
- Service
API Server
1.4.3.3Check Kubernetes NetworkPolicy is defined with at least one ingress or egress rule. This rule is NON_COMPLIANT if no ingress or egress rules are included in the NetworkPolicy else COMPLIANT if any one of the rules exists.0
Attributes
- Section
1.4.3: Network connections between trusted and untrusted networks are controlled.
- Service
API Server
1.4.4: Network connections between trusted and untrusted networks are controlled.103
1.4.4.1Checks if a Kubernetes Ingress resource is using a specific NetworkPolicy. The rule is NON_COMPLIANT if a NetworkPolicy is not applied to the Ingress or if the applied NetworkPolicy does not match the specified criteria.0
Attributes
- Section
1.4.4: Network connections between trusted and untrusted networks are controlled.
- Service
Core
1.4.4.2Checks if Kubernetes Ingress resources are configured with the specified type in the rule parameter. The rule returns NON_COMPLIANT if the Ingress resource does not match the specified configuration type set in the rule parameter.0
Attributes
- Section
1.4.4: Network connections between trusted and untrusted networks are controlled.
- Service
API Server
1.4.4.3Checks if Kubernetes clusters are configured with a custom network policy. The rule is NON_COMPLIANT for a Kubernetes cluster if it is using the default network policy.1
Attributes
- Section
1.4.4: Network connections between trusted and untrusted networks are controlled.
- Service
Core
1.4.4.4Kubernetes equivalent for managing instances within a specific pod network, ensuring that the pods communicate internally while restricting external access.0
Attributes
- Section
1.4.4: Network connections between trusted and untrusted networks are controlled.
- Service
Core
1.4.4.5Checks if ingress or egress network policies are attached to an authorized Kubernetes namespace. The rule is NON_COMPLIANT if network policies are attached to an unauthorized namespace.1
Attributes
- Section
1.4.4: Network connections between trusted and untrusted networks are controlled.
- Service
Core
1.4.4.6Checks if there are public ingress rules in the Kubernetes NetworkPolicy that allow traffic from external sources. The rule is NON_COMPLIANT if a NetworkPolicy allows traffic from any external IP address (e.g., 0.0.0.0/0) or if an ingress rule does not match the specified allowed source CIDR blocks.0
Attributes
- Section
1.4.4: Network connections between trusted and untrusted networks are controlled.
- Service
Core
1.4.4.7Checks if a Kubernetes cluster has network policies implemented. The rule is NON_COMPLIANT if network policies are not defined or if the policies.allowIngress field is 'false'.1
Attributes
- Section
1.4.4: Network connections between trusted and untrusted networks are controlled.
- Service
Core
1.4.4.8Checks if a Kubernetes pod is deployed within a specific namespace or within a list of approved labels. The rule is NON_COMPLIANT if a pod is not deployed within the specified namespace or if its labels are not included in the parameter list.0
Attributes
- Section
1.4.4: Network connections between trusted and untrusted networks are controlled.
- Service
Core
1.4.4.9Verifies whether DNS resolution between the accepter/requester VPC and private IP is enabled in Kubernetes. The state is considered NON_COMPLIANT if DNS resolution from the specified VPC to the private IP is not enabled.0
Attributes
- Section
1.4.4: Network connections between trusted and untrusted networks are controlled.
- Service
API Server
1.4.4.10Checks if both Kubernetes Network Policies associated with the pod are in ENFORCED status. The rule is NON_COMPLIANT if one or both policies are in DISABLED status.0
Attributes
- Section
1.4.4: Network connections between trusted and untrusted networks are controlled.
- Service
Core
1.4.5: Network connections between trusted and untrusted networks are controlled.22
1.4.5.1Checks if Kubernetes Pods are configured to use public IP addresses for their Network Interfaces. The rule is NON_COMPLIANT if the default Pod specification has at least 1 Network Interface with 'hostNetwork' set to 'true'.1
Attributes
- Section
1.4.5: Network connections between trusted and untrusted networks are controlled.
- Service
Core
1.4.5.2Checks if Kubernetes Pods are configured to share the host's process namespace. The rule is NON_COMPLIANT if the hostPID parameter is set to 'true'.1
Attributes
- Section
1.4.5: Network connections between trusted and untrusted networks are controlled.
- Service
Core
1.5.1: Risks to the CDE from computing devices that are able to connect to both untrusted networks and the CDE are mitigated.4618
1.5.1.1Checks if Kubernetes Services are of the type specified in the rule parameter serviceType. The rule returns NON_COMPLIANT if the Service does not match the type configured in the rule parameter.0
Attributes
- Section
1.5.1: Risks to the CDE from computing devices that are able to connect to both untrusted networks and the CDE are mitigated.
- Service
Core
1.5.1.2Checks if a Kubernetes Ingress resource has TLS configuration. The rule is NON_COMPLIANT if the Ingress does not have an associated TLS secret for HTTPS.1
Attributes
- Section
1.5.1: Risks to the CDE from computing devices that are able to connect to both untrusted networks and the CDE are mitigated.
- Service
API Server
1.5.1.3Checks if Kubernetes Services are associated with Network Policies. The rule is NON_COMPLIANT for a Kubernetes Service if it is not associated with a Network Policy.0
Attributes
- Section
1.5.1: Risks to the CDE from computing devices that are able to connect to both untrusted networks and the CDE are mitigated.
- Service
Core
1.5.1.4Checks if Kubernetes Ingress resources are associated with a network policy. The rule is NON_COMPLIANT if an Ingress resource is not associated with a network policy.0
Attributes
- Section
1.5.1: Risks to the CDE from computing devices that are able to connect to both untrusted networks and the CDE are mitigated.
- Service
API Server
1.5.1.5Checks if the TLS certificate associated with a Kubernetes Ingress resource is the default certificate. The rule is NON_COMPLIANT if an Ingress uses the default TLS certificate.1
Attributes
- Section
1.5.1: Risks to the CDE from computing devices that are able to connect to both untrusted networks and the CDE are mitigated.
- Service
API Server
1.5.1.6Checks if the Bitbucket source repository URL contains sign-in credentials. The status is NON_COMPLIANT if the URL contains any sign-in information and COMPLIANT if it doesn't.0
Attributes
- Section
1.5.1: Risks to the CDE from computing devices that are able to connect to both untrusted networks and the CDE are mitigated.
- Service
Core
1.5.1.7Checks if Kubernetes services are of type LoadBalancer, as they can be publicly accessible. The rule is NON_COMPLIANT if the service type is LoadBalancer and it exposes the service to the public network.1
Attributes
- Section
1.5.1: Risks to the CDE from computing devices that are able to connect to both untrusted networks and the CDE are mitigated.
- Service
API Server
1.5.1.8Checks if Kubernetes persistent volumes are public. The rule is NON_COMPLIANT if any persistent volumes are accessible publicly without appropriate security measures.1
Attributes
- Section
1.5.1: Risks to the CDE from computing devices that are able to connect to both untrusted networks and the CDE are mitigated.
- Service
RBAC
1.5.1.9Checks if the Kubernetes Network Policy permits traffic for all pods in the selected namespace. The policy is NON_COMPLIANT if 'ingress' rules allow traffic from all sources.0
Attributes
- Section
1.5.1: Risks to the CDE from computing devices that are able to connect to both untrusted networks and the CDE are mitigated.
- Service
Core
1.5.1.10Checks if the status of the Kubernetes Deployment is 'AVAILABLE' or 'UNAVAILABLE' after the deployment process. The deployment is compliant if the status is 'AVAILABLE'.0
Attributes
- Section
1.5.1: Risks to the CDE from computing devices that are able to connect to both untrusted networks and the CDE are mitigated.
- Service
Core
1.5.1.11Checks if Kubernetes Network Policies have 'allowExternal' enabled. The rule is NON_COMPLIANT for a Network Policy if 'allowExternal' is set to 'false'.0
Attributes
- Section
1.5.1: Risks to the CDE from computing devices that are able to connect to both untrusted networks and the CDE are mitigated.
- Service
API Server
1.5.1.12Checks if the Kubernetes API server endpoint is not publicly accessible. The rule is NON_COMPLIANT if the endpoint is publicly accessible.1
Attributes
- Section
1.5.1: Risks to the CDE from computing devices that are able to connect to both untrusted networks and the CDE are mitigated.
- Service
API Server
1.5.1.13Checks if Kubernetes OpenSearch (Elasticsearch) instances are configured within a Kubernetes cluster. The rule is NON_COMPLIANT if an OpenSearch Service instance is exposed outside of the cluster.0
Attributes
- Section
1.5.1: Risks to the CDE from computing devices that are able to connect to both untrusted networks and the CDE are mitigated.
- Service
Scheduler
1.5.1.14Checks if Ingress resources in Kubernetes have TLS configured with certificates from a trusted certificate provider. This rule is NON_COMPLIANT if at least 1 Ingress has at least 1 TLS secret that is either missing or uses a certificate not issued by a trusted Certificate Authority.1
Attributes
- Section
1.5.1: Risks to the CDE from computing devices that are able to connect to both untrusted networks and the CDE are mitigated.
- Service
API Server
1.5.1.15Checks if Kubernetes Ingress Resources are configured to use TLS certificates provided by a Certificate Manager. To use this rule, ensure that TLS configuration is present in your Ingress Resource. This rule is only applicable to Kubernetes Ingress Resources and does not check other service types such as ClusterIP or NodePort.1
Attributes
- Section
1.5.1: Risks to the CDE from computing devices that are able to connect to both untrusted networks and the CDE are mitigated.
- Service
API Server
1.5.1.16Checks if a Kubernetes cluster has network policies that restrict public access. The rule is NON_COMPLIANT if NetworkPolicySpec.PodSelector does not restrict access to specific pods, or if it allows traffic on ports other than the specified secure ports (e.g., Port 22).1
Attributes
- Section
1.5.1: Risks to the CDE from computing devices that are able to connect to both untrusted networks and the CDE are mitigated.
- Service
Core
1.5.1.17A Kubernetes Network Policy that restricts all incoming traffic to a pod, preventing SSH access from any external source, thus effectively disabling incoming SSH traffic.0
Attributes
- Section
1.5.1: Risks to the CDE from computing devices that are able to connect to both untrusted networks and the CDE are mitigated.
- Service
API Server
1.5.1.18Checks if network policies are applied to authorized namespaces in Kubernetes. The rule is NON_COMPLIANT if network policies are applied to unauthorized namespaces.1
Attributes
- Section
1.5.1: Risks to the CDE from computing devices that are able to connect to both untrusted networks and the CDE are mitigated.
- Service
Core
1.5.1.19Checks if the Kubernetes PodSecurityPolicy attached to the Pod resource prohibits public access. If the PodSecurityPolicy allows public access, it is NON_COMPLIANT.0
Attributes
- Section
1.5.1: Risks to the CDE from computing devices that are able to connect to both untrusted networks and the CDE are mitigated.
- Service
Core
1.5.1.20Checks if a Kubernetes Pod (representing a Lambda function) is allowed access to a Virtual Private Cloud (VPC). The rule is NON_COMPLIANT if the Pod is not configured to use a specific VPC network through Kubernetes Network Policies or specific annotations.0
Attributes
- Section
1.5.1: Risks to the CDE from computing devices that are able to connect to both untrusted networks and the CDE are mitigated.
- Service
Core
1.5.1.21Checks if default ports for SSH/RDP ingress traffic for Kubernetes Network Policies are unrestricted. The rule is NON_COMPLIANT if a Network Policy allows an ingress traffic rule from any source CIDR block for ports 22 (SSH) or 3389 (RDP).0
Attributes
- Section
1.5.1: Risks to the CDE from computing devices that are able to connect to both untrusted networks and the CDE are mitigated.
- Service
API Server
1.5.1.22Checks if a Kubernetes NetworkPolicy is configured with a user-defined action for fragmented packets. The rule is NON_COMPLIANT if the action for fragmented packets does not match the user-defined default action.0
Attributes
- Section
1.5.1: Risks to the CDE from computing devices that are able to connect to both untrusted networks and the CDE are mitigated.
- Service
API Server
1.5.1.23Check Kubernetes NetworkPolicy is associated with at least one ingress or egress rule. This rule is NON_COMPLIANT if no ingress or egress rules are associated with the NetworkPolicy else COMPLIANT if any one of the rule types exists.0
Attributes
- Section
1.5.1: Risks to the CDE from computing devices that are able to connect to both untrusted networks and the CDE are mitigated.
- Service
Core
1.5.1.24Checks if a Kubernetes Network Policy contains ingress or egress rules. The policy is NON_COMPLIANT if there are no rules defined in the Network Policy.0
Attributes
- Section
1.5.1: Risks to the CDE from computing devices that are able to connect to both untrusted networks and the CDE are mitigated.
- Service
Core
1.5.1.25Checks if there are public routes in the Kubernetes network configuration that allow external access. The rule is NON_COMPLIANT if a network policy allows all traffic to/from the pod(s) without restriction (similar to having a route to an IGW with a destination CIDR block of '0.0.0.0/0' or '::/0').0
Attributes
- Section
1.5.1: Risks to the CDE from computing devices that are able to connect to both untrusted networks and the CDE are mitigated.
- Service
Core
1.5.1.26Checks if Kubernetes clusters are deployed within a Virtual Private Cloud (VPC). The rule is NON_COMPLIANT if a Kubernetes service is exposed with a LoadBalancer type that allows public access.0
Attributes
- Section
1.5.1: Risks to the CDE from computing devices that are able to connect to both untrusted networks and the CDE are mitigated.
- Service
Core
1.5.1.27Checks if there are any Kubernetes Network Policies that are not the default Network Policy. The rule is NON_COMPLIANT if there are any Network Policies that are not the default Network Policy.1
Attributes
- Section
1.5.1: Risks to the CDE from computing devices that are able to connect to both untrusted networks and the CDE are mitigated.
- Service
Core
1.5.1.28Checks if the Kubernetes services are not exposed externally. The rule is NON_COMPLIANT if the type field of the service is set to 'LoadBalancer' or 'NodePort'.1
Attributes
- Section
1.5.1: Risks to the CDE from computing devices that are able to connect to both untrusted networks and the CDE are mitigated.
- Service
API Server
1.5.1.29Checks if Kubernetes services are not publicly accessible. The rule is NON_COMPLIANT if the service type is 'LoadBalancer' or 'NodePort' allowing external access.1
Attributes
- Section
1.5.1: Risks to the CDE from computing devices that are able to connect to both untrusted networks and the CDE are mitigated.
- Service
API Server
1.5.1.30Checks if Kubernetes services have network policies that prevent public access. The rule is NON_COMPLIANT if network policies are not configured to restrict public access to Kubernetes services.1
Attributes
- Section
1.5.1: Risks to the CDE from computing devices that are able to connect to both untrusted networks and the CDE are mitigated.
- Service
API Server
1.5.1.31Verifies if the necessary public access settings for Kubernetes resources are configured at the cluster level. The status is marked as NON_COMPLIANT only when the specified security settings do not align with the expected configurations.0
Attributes
- Section
1.5.1: Risks to the CDE from computing devices that are able to connect to both untrusted networks and the CDE are mitigated.
- Service
Core
1.5.1.32Verifies if the required network policies for ingress and egress traffic are configured for the Kubernetes cluster. The rule is NON_COMPLIANT if the network policy does not match one or more settings from parameters (or default).1
Attributes
- Section
1.5.1: Risks to the CDE from computing devices that are able to connect to both untrusted networks and the CDE are mitigated.
- Service
Core
1.5.1.33Checks if Kubernetes Services are publicly accessible. The rule is NON_COMPLIANT if a Service type is LoadBalancer or NodePort and not listed in the excludedServices parameter.1
Attributes
- Section
1.5.1: Risks to the CDE from computing devices that are able to connect to both untrusted networks and the CDE are mitigated.
- Service
API Server
1.5.1.34Checks if your Kubernetes Cluster does not allow public access to sensitive services. The rule checks the Network Policies, the Service type (such as LoadBalancer or NodePort), and the RBAC permissions.1
Attributes
- Section
1.5.1: Risks to the CDE from computing devices that are able to connect to both untrusted networks and the CDE are mitigated.
- Service
API Server
1.5.1.35Checks if your Kubernetes persistent volumes do not allow public write access. The rule checks the PersistentVolumeClaim settings, the storage class, and the access modes of the persistent volumes.1
Attributes
- Section
1.5.1: Risks to the CDE from computing devices that are able to connect to both untrusted networks and the CDE are mitigated.
- Service
RBAC
1.5.1.36Checks if a Kubernetes pod is deployed within a specific namespace or within a list of approved namespaces. The rule is NON_COMPLIANT if a pod is not deployed within the designated namespace or if its namespace is not included in the parameter list.0
Attributes
- Section
1.5.1: Risks to the CDE from computing devices that are able to connect to both untrusted networks and the CDE are mitigated.
- Service
Core
1.5.1.37Checks if direct internet access is disabled for a Kubernetes pod. The rule is NON_COMPLIANT if the pod has an outgoing IP address allowing internet access.0
Attributes
- Section
1.5.1: Risks to the CDE from computing devices that are able to connect to both untrusted networks and the CDE are mitigated.
- Service
Core
1.5.1.38Checks if a Kubernetes Service has Endpoints created for each associated Pod within the specified namespace. The state is NON_COMPLIANT if any Pod associated with the Kubernetes Service does not have an Endpoint created.0
Attributes
- Section
1.5.1: Risks to the CDE from computing devices that are able to connect to both untrusted networks and the CDE are mitigated.
- Service
Core
1.5.1.39Checks if there are unused Network Policies. The rule is COMPLIANT if each Network Policy is associated with a Pod. The rule is NON_COMPLIANT if a Network Policy is not associated with a Pod.0
Attributes
- Section
1.5.1: Risks to the CDE from computing devices that are able to connect to both untrusted networks and the CDE are mitigated.
- Service
API Server
1.5.1.40Verifies Kubernetes NetworkPolicies to ensure that unrestricted ingress connections (from '0.0.0.0/0') only allow inbound TCP or UDP traffic on specified ports. NetworkPolicies are considered NON_COMPLIANT if they do not define allowed ports in their specifications.1
Attributes
- Section
1.5.1: Risks to the CDE from computing devices that are able to connect to both untrusted networks and the CDE are mitigated.
- Service
Core
1.5.1.41Checks if a Kubernetes NetworkPolicy contains any ingress or egress rules. The policy is NON_COMPLIANT if there are no rules present within the NetworkPolicy.0
Attributes
- Section
1.5.1: Risks to the CDE from computing devices that are able to connect to both untrusted networks and the CDE are mitigated.
- Service
API Server
1.5.1.42Checks if a Kubernetes NetworkPolicy contains any ingress or egress rules. The NetworkPolicy is NON_COMPLIANT if no rules are defined within it.0
Attributes
- Section
1.5.1: Risks to the CDE from computing devices that are able to connect to both untrusted networks and the CDE are mitigated.
- Service
API Server
1.5.1.43Checks whether a Kubernetes NetworkPolicy contains any ingress or egress rules. This rule is NON_COMPLIANT if a NetworkPolicy does not contain any ingress or egress rules.0
Attributes
- Section
1.5.1: Risks to the CDE from computing devices that are able to connect to both untrusted networks and the CDE are mitigated.
- Service
Core
1.5.1.44Checks if Kubernetes Network Policies contain any rules. The rule is NON_COMPLIANT if there are no rules present within a Kubernetes Network Policy.0
Attributes
- Section
1.5.1: Risks to the CDE from computing devices that are able to connect to both untrusted networks and the CDE are mitigated.
- Service
Core
1.5.1.45Checks whether the Kubernetes Network Policy contains ingress or egress rules. This Network Policy is COMPLIANT if it defines at least one ingress or egress rule and NON_COMPLIANT otherwise.0
Attributes
- Section
1.5.1: Risks to the CDE from computing devices that are able to connect to both untrusted networks and the CDE are mitigated.
- Service
Core
1.5.1.46Checks if a Kubernetes NetworkPolicy contains any ingress or egress rules. The rule is NON_COMPLIANT if there are no ingress or egress rules present within a NetworkPolicy.0
Attributes
- Section
1.5.1: Risks to the CDE from computing devices that are able to connect to both untrusted networks and the CDE are mitigated.
- Service
API Server
2.2.5: System components are configured and managed securely.177
2.2.5.1Checks if HTTP to HTTPS redirection is configured on all Ingress resources of the Kubernetes cluster. The rule is NON_COMPLIANT if one or more Ingress resources do not have an HTTP to HTTPS redirection configured. The rule is also NON_COMPLIANT if one or more Ingress resources have forwarding to an HTTP service instead of redirection.0
Attributes
- Section
2.2.5: System components are configured and managed securely.
- Service
API Server
2.2.5.2Checks if Kubernetes Ingress resources are using deprecated SSL protocols for HTTPS communication between Ingress controllers and backend services. This rule is NON_COMPLIANT if any Ingress definition includes 'sslPolicy' that allows 'SSLv3'.0
Attributes
- Section
2.2.5: System components are configured and managed securely.
- Service
API Server
2.2.5.3Checks if Kubernetes Ingress resources are using a minimum security policy and cipher suite of TLSv1.2 or greater for HTTPS connections. This rule is NON_COMPLIANT for an Ingress resource if the minTLSVersion is below 'VersionTLS12'.0
Attributes
- Section
2.2.5: System components are configured and managed securely.
- Service
API Server
2.2.5.4Checks if Kubernetes Ingress resources are using a custom TLS secret and are configured to use SNI to serve HTTPS requests. The rule is NON_COMPLIANT if a custom TLS secret is associated but the Ingress is not configured for SNI.0
Attributes
- Section
2.2.5: System components are configured and managed securely.
- Service
API Server
2.2.5.5Checks if Kubernetes Ingress resources are encrypting traffic to backend services. The rule is NON_COMPLIANT if 'backendService' is using unencrypted HTTP endpoints instead of HTTPS or if 'TLS settings' are not properly configured for secure connections.0
Attributes
- Section
2.2.5: System components are configured and managed securely.
- Service
API Server
2.2.5.6Checks if your Kubernetes Ingress resources enforce HTTPS. The rule is NON_COMPLIANT if any Ingress resource allows HTTP traffic without redirecting to HTTPS.0
Attributes
- Section
2.2.5: System components are configured and managed securely.
- Service
API Server
2.2.5.7Check if Kubernetes pods that require encrypted communications between instances have TLS (Transport Layer Security) enabled for pod-to-pod communication. The rule is NON_COMPLIANT if TLS encryption is not enabled for these communications.1
Attributes
- Section
2.2.5: System components are configured and managed securely.
- Service
API Server
2.2.5.8Checks whether your Kubernetes Ingress resources are using a custom SSL certificate for secure connections. This rule only applies if there are Ingress resources defined with SSL settings.0
Attributes
- Section
2.2.5: System components are configured and managed securely.
- Service
API Server
2.2.5.9Checks if your Kubernetes Ingress resource uses a predefined TLS configuration. The rule is NON_COMPLIANT if the Ingress TLS configuration does not equal the value of the parameter 'predefinedPolicyName'.1
Attributes
- Section
2.2.5: System components are configured and managed securely.
- Service
API Server
2.2.5.10Checks if your Kubernetes Service is configured with TLS for secure communication. The rule is NON_COMPLIANT if a Service does not have an associated TLS configuration for HTTPS traffic.1
Attributes
- Section
2.2.5: System components are configured and managed securely.
- Service
API Server
2.2.5.11Checks if Kubernetes clusters have Pod Security Policies enabled. The rule is NON_COMPLIANT if a Pod Security Policy is not attached to the cluster or the policy does not satisfy the specified rule parameters.1
Attributes
- Section
2.2.5: System components are configured and managed securely.
- Service
API Server
2.2.5.12Checks whether connections to OpenSearch domains are using HTTPS. The rule is NON_COMPLIANT if the Kubernetes OpenSearch deployment is not configured to enforce HTTPS connections.0
Attributes
- Section
2.2.5: System components are configured and managed securely.
- Service
OpenSearch
2.2.5.13Check if Kubernetes Secrets are encrypted at rest and if communication between pods is encrypted. The rule is NON_COMPLIANT if encryption for Secrets is not enabled or if Network Policies do not ensure encrypted communication between pods.1
Attributes
- Section
2.2.5: System components are configured and managed securely.
- Service
Core
2.2.5.14Checks if Kubernetes clusters require TLS encryption for communication. The rule is NON_COMPLIANT if any Kubernetes cluster has the API Server's --insecure-port parameter set to a value other than 0, allowing unencrypted traffic.1
Attributes
- Section
2.2.5: System components are configured and managed securely.
- Service
API Server
2.2.5.15Checks if Ingress resources have rules that require TLS for connections. The rule is NON_COMPLIANT if any Ingress resource allows HTTP connections without TLS.0
Attributes
- Section
2.2.5: System components are configured and managed securely.
- Service
API Server
2.2.5.16Checks if a Kubernetes service uses FTP for endpoint connection. The rule is NON_COMPLIANT if the service type is set to 'ClusterIP' with a port configuration for FTP (port 21).0
Attributes
- Section
2.2.5: System components are configured and managed securely.
- Service
Core
2.2.5.17Verifies that NetworkPolicies in Kubernetes are configured to limit incoming traffic only to specified ports, ensuring that unrestricted traffic ('0.0.0.0/0' or '::/0') is not allowed except on authorized TCP or UDP ports. If there are NetworkPolicies that do not specify the allowed ports, they are considered NON_COMPLIANT.1
Attributes
- Section
2.2.5: System components are configured and managed securely.
- Service
Core
2.2.7: System components are configured and managed securely.197
2.2.7.1Checks if Ingress resources in Kubernetes are configured to redirect HTTP traffic to HTTPS. The rule is NON_COMPLIANT if one or more Ingress resources do not have HTTP to HTTPS redirection configured or if they forward traffic to another HTTP service instead of redirecting.0
Attributes
- Section
2.2.7: System components are configured and managed securely.
- Service
API Server
2.2.7.2Checks if Kubernetes Ingress Controllers are using deprecated SSL protocols for HTTPS communication between clients and services. This rule is NON_COMPLIANT for an Ingress if any SSL configuration allows 'SSLv3'.0
Attributes
- Section
2.2.7: System components are configured and managed securely.
- Service
Kubernetes Ingress Controller
2.2.7.3Checks if Kubernetes Ingress resources are enforcing SSL/TLS for traffic to backend services. The rule is NON_COMPLIANT if 'backendProtocol' is 'http' or if 'backendProtocol' is 'https' but 'tls' is not specified for the Ingress resource.0
Attributes
- Section
2.2.7: System components are configured and managed securely.
- Service
API Server
2.2.7.4Checks if your Kubernetes Ingress resources enforce HTTPS connections. The rule is NON_COMPLIANT if the Ingress resource allows HTTP traffic without redirecting to HTTPS.0
Attributes
- Section
2.2.7: System components are configured and managed securely.
- Service
API Server
2.2.7.5Checks if your Kubernetes Pods have NetworkPolicies set to enforce traffic control. The rule is NON_COMPLIANT if a Pod is not restricted by NetworkPolicies to prevent unauthorized access.1
Attributes
- Section
2.2.7: System components are configured and managed securely.
- Service
Core
2.2.7.6Checks if Kubernetes Database (such as PostgreSQL or MySQL) service connections are configured with SSL. The rule is NON_COMPLIANT if the database service does not have an SSL connection configured.0
Attributes
- Section
2.2.7: System components are configured and managed securely.
- Service
Kubernetes Database Service
2.2.7.7Checks if Kubernetes clusters have TLS encryption enabled for communication between pods and services. The rule is NON_COMPLIANT if TLS encryption is not enabled.1
Attributes
- Section
2.2.7: System components are configured and managed securely.
- Service
API Server
2.2.7.8Checks if Kubernetes Secrets are encrypted in transit. The rule is NON_COMPLIANT for a Kubernetes cluster if 'encryptionProviders' are not configured to enable encryption for Secrets during transit.1
Attributes
- Section
2.2.7: System components are configured and managed securely.
- Service
Core
2.2.7.9Check if OpenSearch (Elasticsearch) nodes in Kubernetes are configured with end-to-end encryption. The rule is considered NON_COMPLIANT if the node-to-node encryption is not enabled in the OpenSearch cluster configuration.0
Attributes
- Section
2.2.7: System components are configured and managed securely.
- Service
OpenSearch
2.2.7.10Checks if the Ingress resources in Kubernetes use SSL certificates provided by a Certificate Manager (e.g., Cert-Manager or similar). To use this rule, an Ingress resource should be configured with TLS settings. This rule is only applicable to Ingress resources. This rule does not check services without Ingress, such as NodePorts or ClusterIPs.0
Attributes
- Section
2.2.7: System components are configured and managed securely.
- Service
API Server
2.2.7.11Checks whether your Kubernetes Ingress resources are using a custom TLS configuration. The rule is only applicable if there are TLS-enabled Ingress resources defined.1
Attributes
- Section
2.2.7: System components are configured and managed securely.
- Service
API Server
2.2.7.12Checks if your Kubernetes Ingress controllers use a predefined TLS policy. The rule is NON_COMPLIANT if the Ingress TLS configuration does not match the specified 'predefinedPolicyName'.1
Attributes
- Section
2.2.7: System components are configured and managed securely.
- Service
API Server
2.2.7.13Checks if the Kubernetes Service is configured with HTTPS or SSL settings for its corresponding LoadBalancer. The rule is NON_COMPLIANT if the Service is not configured with SSL or HTTPS.0
Attributes
- Section
2.2.7: System components are configured and managed securely.
- Service
Core
2.2.7.14Verifies if Kubernetes clusters have security contexts with Kerberos enabled. The rule is NON_COMPLIANT if a security context is not defined for the pod or the security context does not satisfy the specified rule parameters for Kerberos authentication.1
Attributes
- Section
2.2.7: System components are configured and managed securely.
- Service
API Server
2.2.7.15Checks if a Kubernetes cluster enforces encrypted communication (TLS) for inter-pod communication. The rule is NON_COMPLIANT if plain text communication is allowed between pods.0
Attributes
- Section
2.2.7: System components are configured and managed securely.
- Service
Core
2.2.7.16Verifies if connections to OpenSearch domains are secured with HTTPS. The system is considered NON_COMPLIANT if the Kubernetes OpenSearch Custom Resource 'EnforceHTTPS' is not set to 'true' or is 'true' and 'TLSSecurityPolicy' is not configured within the 'tlsPolicies'.0
Attributes
- Section
2.2.7: System components are configured and managed securely.
- Service
OpenSearch
2.2.7.17Check if Kubernetes cluster nodes have encrypted communication enabled. The rule is NON_COMPLIANT if the encryption between nodes is not enabled.0
Attributes
- Section
2.2.7: System components are configured and managed securely.
- Service
Core
2.2.7.18Checks if Kubernetes clusters require TLS/SSL encryption for connections to SQL clients. The rule is NON_COMPLIANT if any Kubernetes cluster has the configuration for TLS/SSL not enabled.0
Attributes
- Section
2.2.7: System components are configured and managed securely.
- Service
Core
2.2.7.19Checks if Kubernetes services have Network Policies that require requests to use secure connections (TLS). The rule is NON_COMPLIANT if any service allows HTTP traffic without enforcing TLS.1
Attributes
- Section
2.2.7: System components are configured and managed securely.
- Service
API Server
3.2.1: Storage of account data is kept to a minimum.70
3.2.1.1Verifies if a backup policy has a backup schedule that meets the defined intervals and retention timelines. The policy is considered NON_COMPLIANT if recovery snapshots are not generated at least as frequently as required by the schedule or if they expire before the designated retention period.0
Attributes
- Section
3.2.1: Storage of account data is kept to a minimum.
- Service
Kubernetes Backup Operator
3.2.1.2Checks if a Persistent Volume Claim (PVC) retains data for a specified duration, ensuring that the data retains its state not earlier than the defined retention policy. The rule is NON_COMPLIANT if the PVC's retention settings are less than the required retention period.0
Attributes
- Section
3.2.1: Storage of account data is kept to a minimum.
- Service
Persistent Volumes
3.2.1.3Checks if a Kubernetes ConfigMap or Secret has a retention policy configured to retain data for greater than 365 days; the rule is NON_COMPLIANT if the retention policy is less than MinRetentionTime, if specified, or else the default of 365 days.0
Attributes
- Section
3.2.1: Storage of account data is kept to a minimum.
- Service
Kubernetes ConfigMap/Secret
3.2.1.6Checks if Persistent Volumes (PVs) are bound to Persistent Volume Claims (PVCs) in Kubernetes. Optionally checks if the storage class of the PVC specifies reclaim policy as 'Delete' when the PVC is deleted.0
Attributes
- Section
3.2.1: Storage of account data is kept to a minimum.
- Service
Core
3.2.1.7Checks if a private Kubernetes container registry has at least one lifecycle policy configured. The rule is NON_COMPLIANT if no lifecycle policy is configured for the Kubernetes container registry.0
Attributes
- Section
3.2.1: Storage of account data is kept to a minimum.
- Service
Core
3.2.1.8Checks if a lifecycle policy is configured for a Kubernetes Persistent Volume (PV). The policy is NON_COMPLIANT if there is no active lifecycle policy or the policy does not match with the specified criteria.0
Attributes
- Section
3.2.1: Storage of account data is kept to a minimum.
- Service
Kubernetes Persistent Storage
3.2.1.9Checks if Kubernetes persistent volumes (PVs) have lifecycle policies configured. The rule is NON_COMPLIANT if a Kubernetes persistent volume does not have a defined reclaim policy.0
Attributes
- Section
3.2.1: Storage of account data is kept to a minimum.
- Service
Core
3.3.1.1: Sensitive authentication data (SAD) is not stored after authorization.80
3.3.1.1.1Verifies that a Kubernetes backup plan has a backup schedule (CronJob) that adheres to the defined frequency and retention policies. The schedule is NON_COMPLIANT if backup jobs are not executed at least as often as specified or if backup artifacts are deleted before the retention period is met.0
Attributes
- Section
3.3.1.1: Sensitive authentication data (SAD) is not stored after authorization.
- Service
Kubernetes Backup Service
3.3.1.1.2Checks if a Kubernetes snapshot retention policy adheres to a specified retention period. The policy is NON_COMPLIANT if the snapshot retention period is shorter than the required retention duration.0
Attributes
- Section
3.3.1.1: Sensitive authentication data (SAD) is not stored after authorization.
- Service
Kubernetes Storage
3.3.1.1.3Checks if a Kubernetes Namespace's resource quota for log retention is set to greater than 365 days or else a specified retention limit. The rule is NON_COMPLIANT if the log retention period is less than MinRetentionTime, if specified, or else 365 days.0
Attributes
- Section
3.3.1.1: Sensitive authentication data (SAD) is not stored after authorization.
- Service
Core
3.3.1.1.4Checks if a Kubernetes Persistent Volume retention period is configured to a specific number of days. The rule is NON_COMPLIANT if the retention period is less than the value specified by the parameter.0
Attributes
- Section
3.3.1.1: Sensitive authentication data (SAD) is not stored after authorization.
- Service
Kubernetes Persistent Volumes
3.3.1.1.6Checks if Persistent Volumes (PVs) are bound to Persistent Volume Claims (PVCs). Optionally checks if PVCs have a finalizer to ensure they are deleted when the associated Pods are terminated.0
Attributes
- Section
3.3.1.1: Sensitive authentication data (SAD) is not stored after authorization.
- Service
Core
3.3.1.1.7Checks if a private Kubernetes container registry has at least one lifecycle policy configured. The rule is NON_COMPLIANT if no lifecycle policy is configured for the private registry.0
Attributes
- Section
3.3.1.1: Sensitive authentication data (SAD) is not stored after authorization.
- Service
Core
3.3.1.1.8Checks if a Kubernetes Persistent Volume (PV) has a Retain policy set for its lifecycle. The PV is considered NON_COMPLIANT if there are no active reclaim policies or the policies do not match the desired parameter values.0
Attributes
- Section
3.3.1.1: Sensitive authentication data (SAD) is not stored after authorization.
- Service
Core
3.3.1.1.9Checks if Kubernetes buckets (such as those used with object storage solutions like MinIO or cloud providers) have a lifecycle management policy configured. The rule is NON_COMPLIANT if the lifecycle policy is not enabled.0
Attributes
- Section
3.3.1.1: Sensitive authentication data (SAD) is not stored after authorization.
- Service
Core
3.3.1.3: Sensitive authentication data (SAD) is not stored after authorization.72
3.3.1.3.1Evaluates if a Kubernetes CronJob has a schedule that meets the required execution frequency and retention strategy. The CronJob is NON_COMPLIANT if it does not run at least as often as the defined schedule or if the created Job resources expire before the designated retention period.0
Attributes
- Section
3.3.1.3: Sensitive authentication data (SAD) is not stored after authorization.
- Service
Kubernetes CronJob
3.3.1.3.3Checks if a Kubernetes Cluster's Log retention policy is set to retain logs for more than 365 days. The policy is NON_COMPLIANT if the retention period is less than MinRetentionTime, if specified, or else 365 days.1
Attributes
- Section
3.3.1.3: Sensitive authentication data (SAD) is not stored after authorization.
- Service
API Server
3.3.1.3.4Checks if a Kubernetes persistent volume claim (PVC) retention period is set to a specific number of days. The rule is NON_COMPLIANT if the retention period is less than the value specified by the parameter.0
Attributes
- Section
3.3.1.3: Sensitive authentication data (SAD) is not stored after authorization.
- Service
Kubernetes (Persistent Volume Claims)
3.3.1.3.5Checks if point-in-time recovery (PITR) is enabled for Persistent Volumes in Kubernetes. The rule is NON_COMPLIANT if PITR is not enabled for Persistent Volumes.0
Attributes
- Section
3.3.1.3: Sensitive authentication data (SAD) is not stored after authorization.
- Service
Persistent Volume
3.3.1.3.6Checks if Persistent Volumes (PVs) are bound to Persistent Volume Claims (PVCs). Optionally checks if the volumes are set to delete upon PVC deletion.0
Attributes
- Section
3.3.1.3: Sensitive authentication data (SAD) is not stored after authorization.
- Service
Core
3.3.1.3.7Checks if a private Kubernetes container registry has at least one lifecycle policy configured. The rule is NON_COMPLIANT if no lifecycle policy is configured for the Kubernetes container registry.0
Attributes
- Section
3.3.1.3: Sensitive authentication data (SAD) is not stored after authorization.
- Service
Core
3.3.1.3.9Checks if Kubernetes Persistent Volumes (PVs) have a retention policy configured. The rule is NON_COMPLIANT if a retention policy is not enabled on the Persistent Volume.1
Attributes
- Section
3.3.1.3: Sensitive authentication data (SAD) is not stored after authorization.
- Service
RBAC
3.3.2: Sensitive authentication data (SAD) is not stored after authorization.80
3.3.2.1Verifies if a Kubernetes backup plan has a backup schedule that meets the required interval and retention duration. The backup is deemed NON_COMPLIANT if snapshots are not taken at least as frequently as defined in the schedule or if they are deleted before the specified retention period has passed.0
Attributes
- Section
3.3.2: Sensitive authentication data (SAD) is not stored after authorization.
- Service
Kubernetes Backup Service
3.3.2.2Checks if a Persistent Volume Claim (PVC) is retained no earlier than after the specified period. The rule is NON_COMPLIANT if the Persistent Volume (PV) has a retention policy that is less than the required retention period.0
Attributes
- Section
3.3.2: Sensitive authentication data (SAD) is not stored after authorization.
- Service
Persistent Volume Management
3.3.2.3Checks if a Kubernetes Pod's logging retention policy is set to greater than 365 days or a specified minimum retention time. The rule is NON_COMPLIANT if the retention period is less than MinRetentionTime, if specified, or else 365 days.0
Attributes
- Section
3.3.2: Sensitive authentication data (SAD) is not stored after authorization.
- Service
Core
3.3.2.5Checks if point-in-time recovery (PITR) is enabled for persistent volumes in Kubernetes. The rule is NON_COMPLIANT if PITR is not configured for persistent volumes.0
Attributes
- Section
3.3.2: Sensitive authentication data (SAD) is not stored after authorization.
- Service
Kubernetes Persistent Volumes
3.3.2.6Checks if Persistent Volumes (PVs) are bound to Pods in a Kubernetes cluster. Optionally checks if Persistent Volumes are configured to be deleted when their associated Pods are deleted.0
Attributes
- Section
3.3.2: Sensitive authentication data (SAD) is not stored after authorization.
- Service
Core
3.3.2.7Checks if a private Kubernetes image registry has at least one lifecycle policy configured. The rule is NON_COMPLIANT if no lifecycle policy is configured for the Kubernetes private image registry.0
Attributes
- Section
3.3.2: Sensitive authentication data (SAD) is not stored after authorization.
- Service
Core
3.3.2.8Checks if a Kubernetes Persistent Volume (PV) has a defined reclaim policy. The status is NON_COMPLIANT if there is no active reclaim policy or the policy does not match the required values.0
Attributes
- Section
3.3.2: Sensitive authentication data (SAD) is not stored after authorization.
- Service
Core
3.3.2.9Checks if Kubernetes persistent volumes have lifecycle policies configured. The rule is NON_COMPLIANT if Kubernetes persistent volumes do not have lifecycle policies enabled.0
Attributes
- Section
3.3.2: Sensitive authentication data (SAD) is not stored after authorization.
- Service
Core
3.3.3: Sensitive authentication data (SAD) is not stored after authorization.91
3.3.3.1Verifies if a Kubernetes backup strategy has a backup schedule that meets the necessary interval and retention criteria. The backup status is NON_COMPLIANT if snapshots are not captured at the required frequency or if they are deleted before the specified retention duration.0
Attributes
- Section
3.3.3: Sensitive authentication data (SAD) is not stored after authorization.
- Service
Kubernetes Backup Operator
3.3.3.2Checks if a backup retention policy for a volume in Kubernetes is compliant with specified retention periods. The rule is NON_COMPLIANT if the backup retention time for a persistent volume claim is less than the required retention period.0
Attributes
- Section
3.3.3: Sensitive authentication data (SAD) is not stored after authorization.
- Service
Kubernetes Persistent Volume Claims
3.3.3.3Checks if a Kubernetes Cluster's log retention policy for the logging service is set to retain logs for more than 365 days or else a specified retention period. The rule is NON_COMPLIANT if the retention period is less than MinRetentionTime, if specified, or else 365 days.1
Attributes
- Section
3.3.3: Sensitive authentication data (SAD) is not stored after authorization.
- Service
API Server
3.3.3.4Checks if a Kubernetes Persistent Volume Claim (PVC) storage class retention period is set to a specific value. The rule is NON_COMPLIANT if the retention period is less than the value specified by the parameter.0
Attributes
- Section
3.3.3: Sensitive authentication data (SAD) is not stored after authorization.
- Service
Core
3.3.3.5Checks if point-in-time recovery (PITR) is enabled for etcd data used in Kubernetes clusters. The rule is NON_COMPLIANT if PITR is not enabled for the etcd datastore.0
Attributes
- Section
3.3.3: Sensitive authentication data (SAD) is not stored after authorization.
- Service
etcd
3.3.3.6Checks if Persistent Volumes (PVs) are bound to Persistent Volume Claims (PVCs). Optionally checks if the PVCs are set to be deleted when their pods are terminated.0
Attributes
- Section
3.3.3: Sensitive authentication data (SAD) is not stored after authorization.
- Service
Kubernetes Storage
3.3.3.7Checks if a private Kubernetes container registry has at least one retention policy configured. The rule is NON_COMPLIANT if no retention policy is configured for the Kubernetes private container registry.0
Attributes
- Section
3.3.3: Sensitive authentication data (SAD) is not stored after authorization.
- Service
Core
3.3.3.8Verifies if a lifecycle policy is applied to a Kubernetes PersistentVolume that dictates its retention and deletion behavior. The policy is considered NON_COMPLIANT if there are no active lifecycle settings or the settings do not align with the specified parameters.0
Attributes
- Section
3.3.3: Sensitive authentication data (SAD) is not stored after authorization.
- Service
Kubernetes PersistentVolume
3.3.3.9Checks if Kubernetes persistent volume claims (PVCs) have a storage lifecycle management policy configured. The rule is NON_COMPLIANT if the lifecycle policy for PVCs is not enabled.0
Attributes
- Section
3.3.3: Sensitive authentication data (SAD) is not stored after authorization.
- Service
Core
3.5.1: Primary account number (PAN) is secured wherever it is stored.2918
3.5.1.1Checks if all methods in Kubernetes Ingress resources have caching enabled and are using TLS. The rule is NON_COMPLIANT if any method in a Kubernetes Ingress resource is not configured to use caching or is not served over TLS.0
Attributes
- Section
3.5.1: Primary account number (PAN) is secured wherever it is stored.
- Service
API Server
3.5.1.3Checks if the backup volume in Kubernetes is encrypted. The rule is NON_COMPLIANT if the backup volume is not encrypted.0
Attributes
- Section
3.5.1: Primary account number (PAN) is secured wherever it is stored.
- Service
Kubernetes Backup Service
3.5.1.4Verifies that Kubernetes Log Storage (such as Fluentd or Elasticsearch) has encryption enabled using a specific encryption key or a key management service (KMS). The status is NON_COMPLIANT if the log storage is not encrypted or is encrypted with a key that does not match the specified key.0
Attributes
- Section
3.5.1: Primary account number (PAN) is secured wherever it is stored.
- Service
Kubernetes Log Storage
3.5.1.5Checks if Kubernetes Secrets are configured to use encryption at rest. The rule is COMPLIANT if the encryption provider configuration is defined in the Kubernetes API server configuration.1
Attributes
- Section
3.5.1: Primary account number (PAN) is secured wherever it is stored.
- Service
API Server
3.5.1.6Checks if a Kubernetes Job has encryption enabled for all of its secrets. The rule is NON_COMPLIANT if 'encryptionEnabled' is set to 'false' for any secrets used in the Job's specifications.0
Attributes
- Section
3.5.1: Primary account number (PAN) is secured wherever it is stored.
- Service
Core
3.5.1.8Checks if a Kubernetes Pod's logs configured with a persistent volume have encryption enabled for its logs. The rule is NON_COMPLIANT if 'encryptionEnabled' is set to 'false' in the volume configuration of a Pod.0
Attributes
- Section
3.5.1: Primary account number (PAN) is secured wherever it is stored.
- Service
Core
3.5.1.9Checks if Kubernetes etcd clusters are encrypted at rest. The rule is NON_COMPLIANT if an etcd cluster is not encrypted.1
Attributes
- Section
3.5.1: Primary account number (PAN) is secured wherever it is stored.
- Service
ETCD
3.5.1.10Checks if storage encryption is enabled for your Kubernetes Persistent Volume Claims (PVCs). The rule is NON_COMPLIANT if storage encryption is not enabled.1
Attributes
- Section
3.5.1: Primary account number (PAN) is secured wherever it is stored.
- Service
RBAC
3.5.1.12Checks if the Kubernetes etcd database is encrypted and checks its status. The rule is COMPLIANT if the status is enabled or enabling.1
Attributes
- Section
3.5.1: Primary account number (PAN) is secured wherever it is stored.
- Service
ETCD
3.5.1.13Checks if Kubernetes Persistent Volume (PV) encryption at rest is enabled by default. The rule is NON_COMPLIANT if the encryption is not enabled.0
Attributes
- Section
3.5.1: Primary account number (PAN) is secured wherever it is stored.
- Service
Core
3.5.1.14Checks if Kubernetes Secrets are exposed as environment variables in Pods. The rule is NON_COMPLIANT if one or more environment variable key matches a key listed in the 'secretKeys' parameter, excluding environment variables sourced from other locations such as ConfigMaps.1
Attributes
- Section
3.5.1: Primary account number (PAN) is secured wherever it is stored.
- Service
Core
3.5.1.15Checks if Kubernetes Persistent Volume (PV) is configured to encrypt the data using Kubernetes Secrets for key management. The rule is NON_COMPLIANT if the encryption is not enabled in the Persistent Volume configuration or if the specified encryption key does not match the expected key.0
Attributes
- Section
3.5.1: Primary account number (PAN) is secured wherever it is stored.
- Service
Core
3.5.1.16Checks if Kubernetes clusters are configured to have secrets encrypted. The rule is NON_COMPLIANT if a Kubernetes cluster does not have EncryptionConfiguration set, or if EncryptionConfiguration does not include 'secrets' as a resource.1
Attributes
- Section
3.5.1: Primary account number (PAN) is secured wherever it is stored.
- Service
Core
3.5.1.19Checks if Kubernetes clusters have encryption at rest configuration enabled for secrets. The rule is NON_COMPLIANT if the encryption configuration for secrets in the Kubernetes API server is not set.1
Attributes
- Section
3.5.1: Primary account number (PAN) is secured wherever it is stored.
- Service
API Server
3.5.1.20Checks if attached Persistent Volumes (PVs) are encrypted and optionally are encrypted with a specified key. The rule is NON_COMPLIANT if attached PVs are unencrypted or are encrypted with a key not in the supplied parameters.0
Attributes
- Section
3.5.1: Primary account number (PAN) is secured wherever it is stored.
- Service
Persistent Volumes (PVs)
3.5.1.21Checks if Kubernetes persistent volumes are encrypted at rest with server-side encryption. The rule is NON_COMPLIANT for a persistent volume if 'encryption' is not enabled.1
Attributes
- Section
3.5.1: Primary account number (PAN) is secured wherever it is stored.
- Service
API Server
3.5.1.22Checks if storage encryption is enabled for your Kubernetes Persistent Volumes (PVs). The rule is NON_COMPLIANT if storage encryption is not enabled.0
Attributes
- Section
3.5.1: Primary account number (PAN) is secured wherever it is stored.
- Service
Core
3.5.1.23Checks if a Kubernetes cluster has encrypted etcd storage. The rule is NON_COMPLIANT if the etcd storage used by the Kubernetes cluster is not encrypted.1
Attributes
- Section
3.5.1: Primary account number (PAN) is secured wherever it is stored.
- Service
ETCD
3.5.1.24Checks if Kubernetes clusters have encryption at rest configuration enabled for secrets. The rule is NON_COMPLIANT if the encryption of secrets at rest is not configured properly.1
Attributes
- Section
3.5.1: Primary account number (PAN) is secured wherever it is stored.
- Service
API Server
3.5.1.26Checks if Kubernetes Persistent Volumes (PVs) are using encryption at rest. The rule is NON_COMPLIANT if the Kubernetes Persistent Volumes do not have encryption enabled.1
Attributes
- Section
3.5.1: Primary account number (PAN) is secured wherever it is stored.
- Service
RBAC
3.5.1.27Checks if encryption is enabled for Kubernetes Persistent Volumes (PVs). The rule is NON_COMPLIANT if storage encryption is not enabled.0
Attributes
- Section
3.5.1: Primary account number (PAN) is secured wherever it is stored.
- Service
Core
3.5.1.28Checks if Kubernetes clusters have the specified settings. The rule is NON_COMPLIANT if the Kubernetes cluster is not configured for RBAC (Role-Based Access Control), or if the cluster does not have audit logging enabled.1
Attributes
- Section
3.5.1: Primary account number (PAN) is secured wherever it is stored.
- Service
API Server
3.5.1.29Checks if Kubernetes clusters are using a specified secret for encryption. The rule is COMPLIANT if encryption is enabled and the cluster uses the secret specified for encryption. The rule is NON_COMPLIANT if the cluster is not encrypted or encrypted with another secret.0
Attributes
- Section
3.5.1: Primary account number (PAN) is secured wherever it is stored.
- Service
Core
3.5.1.30Checks if your Kubernetes Persistent Volume (PV) is configured with encryption enabled at rest, or if the Persistent Volume claim (PVC) policy explicitly denies access to volumes that are not encrypted. The rule is NON_COMPLIANT if your Persistent Volume is not encrypted by default.1
Attributes
- Section
3.5.1: Primary account number (PAN) is secured wherever it is stored.
- Service
RBAC
3.5.1.31Checks if the Kubernetes Secrets are encrypted at rest. The rule is NON_COMPLIANT if the Secrets are not encrypted with a defined encryption provider.1
Attributes
- Section
3.5.1: Primary account number (PAN) is secured wherever it is stored.
- Service
Core
3.5.1.32Checks if a Kubernetes Secret containing encryption keys is configured for a specific Deployment. The rule is NON_COMPLIANT if 'encryptionKey' is not specified in the Deployment's environment variables.1
Attributes
- Section
3.5.1: Primary account number (PAN) is secured wherever it is stored.
- Service
Core
3.5.1.33Checks if a Kubernetes Secret is configured for a pod. The rule is NON_COMPLIANT if the pod does not specify a 'secret' volumne or environment variable referencing a Kubernetes Secret.1
Attributes
- Section
3.5.1: Primary account number (PAN) is secured wherever it is stored.
- Service
Core
3.5.1.34Checks if all Kubernetes Secrets are encrypted using a customer-managed key configured for the Kubernetes cluster or are not using the default encryption settings. The rule is COMPLIANT if a secret is encrypted using a customer-managed key; otherwise, it is NON_COMPLIANT if it uses the default encryption settings.1
Attributes
- Section
3.5.1: Primary account number (PAN) is secured wherever it is stored.
- Service
Core
3.5.1.35Checks if Kubernetes Secrets are encrypted using the configured encryption providers. The rule is NON_COMPLIANT if a Secret is not encrypted. Optionally, specify the encryption provider configuration for the rule to check.1
Attributes
- Section
3.5.1: Primary account number (PAN) is secured wherever it is stored.
- Service
API Server
3.5.1.1: Primary account number (PAN) is secured wherever it is stored.96
3.5.1.1.1Checks if Kubernetes Secrets that contain TLS certificates are about to expire within the specified number of days. TLS certificates in Kubernetes can be renewed, but manually managed certificates may not be automatically updated. The rule is NON_COMPLIANT if your certificates are about to expire.0
Attributes
- Section
3.5.1.1: Primary account number (PAN) is secured wherever it is stored.
- Service
RBAC (Role-Based Access Control)
3.5.1.1.2Checks if Kubernetes CertificateSigningRequests (CSRs) exist that are not in 'Approved' status. The rule is NON_COMPLIANT for CSRs that are not approved by the controller (i.e., in 'Pending' status).1
Attributes
- Section
3.5.1.1: Primary account number (PAN) is secured wherever it is stored.
- Service
RBAC
3.5.1.1.3Checks if a Kubernetes Ingress resource is configured with TLS. The rule is NON_COMPLIANT if the Ingress does not have an associated TLS secret for SSL termination.0
Attributes
- Section
3.5.1.1: Primary account number (PAN) is secured wherever it is stored.
- Service
API Server
3.5.1.1.4Checks if the certificate associated with a Kubernetes Ingress resource is a custom SSL certificate. The rule is NON_COMPLIANT if an Ingress resource uses the default SSL certificate (kubernetes.io/tls-cert).1
Attributes
- Section
3.5.1.1: Primary account number (PAN) is secured wherever it is stored.
- Service
API Server
3.5.1.1.5Checks if Kubernetes Services of type LoadBalancer have TLS configured correctly using certificates from a trusted Certificate Authority (CA). This rule is NON_COMPLIANT if at least 1 LoadBalancer service has at least 1 listener (Ingress) that is configured without a valid TLS certificate from a supported CA or is configured with a certificate that is not trusted.1
Attributes
- Section
3.5.1.1: Primary account number (PAN) is secured wherever it is stored.
- Service
API Server
3.5.1.1.6Checks if the Ingress resources in Kubernetes use TLS certificates provided by a certificate management solution (like Cert-Manager). To use this rule, an Ingress resource with a TLS section must be configured in the cluster. This rule is only applicable to Ingress resources. This rule does not check for services without Ingress or other types of Load Balancers.1
Attributes
- Section
3.5.1.1: Primary account number (PAN) is secured wherever it is stored.
- Service
API Server
3.5.1.1.7Checks if the Kubernetes Role or ClusterRole definitions do not allow actions on Kubernetes secrets that are disallowed by policy. The rule is NON_COMPLIANT if any disallowed action is permitted on Kubernetes secrets by the managed Role or ClusterRole.1
Attributes
- Section
3.5.1.1: Primary account number (PAN) is secured wherever it is stored.
- Service
RBAC
3.5.1.1.8Checks if the Role-Based Access Control (RBAC) settings in your Kubernetes cluster do not allow blocked actions on all cluster resources. The rule is NON_COMPLIANT if any blocked action is allowed on any resources in the cluster role bindings.1
Attributes
- Section
3.5.1.1: Primary account number (PAN) is secured wherever it is stored.
- Service
RBAC
3.5.1.1.9Checks if Kubernetes Secrets are not marked for deletion. The rule is NON_COMPLIANT if Secrets are scheduled for deletion.0
Attributes
- Section
3.5.1.1: Primary account number (PAN) is secured wherever it is stored.
- Service
Core
3.5.1.3: Primary account number (PAN) is secured wherever it is stored.2921
3.5.1.3.1Checks if Kubernetes TLS Secrets in your cluster are nearing expiration. Kubernetes does not automatically renew TLS Secrets. The rule is NON_COMPLIANT if your TLS Secrets are about to expire.0
Attributes
- Section
3.5.1.3: Primary account number (PAN) is secured wherever it is stored.
- Service
Core
3.5.1.3.2Checks if Kubernetes Certificate Authority (CA) has a root CA that is disabled. The rule is NON_COMPLIANT for root CAs with status that is not DISABLED.1
Attributes
- Section
3.5.1.3: Primary account number (PAN) is secured wherever it is stored.
- Service
CONTROLLERMANAGER
3.5.1.3.3Checks if a Kubernetes Ingress resource uses TLS. The rule is NON_COMPLIANT if the Ingress does not have an associated TLS certificate.0
Attributes
- Section
3.5.1.3: Primary account number (PAN) is secured wherever it is stored.
- Service
API Server
3.5.1.3.5Checks if the TLS certificate associated with a Kubernetes Ingress resource is the default certificate. The rule is NON_COMPLIANT if the Ingress resource uses the default TLS certificate.1
Attributes
- Section
3.5.1.3: Primary account number (PAN) is secured wherever it is stored.
- Service
API Server
3.5.1.3.6Checks if Kubernetes Pods are exposed to the public. The rule is NON_COMPLIANT if the Service type is set to 'LoadBalancer' or 'NodePort' without appropriate network policies.1
Attributes
- Section
3.5.1.3: Primary account number (PAN) is secured wherever it is stored.
- Service
Core
3.5.1.3.7Checks if Kubernetes persistent volume claims (PVCs) are publicly accessible. The rule is NON_COMPLIANT if any Kubernetes PVCs are accessible from outside the cluster.1
Attributes
- Section
3.5.1.3: Primary account number (PAN) is secured wherever it is stored.
- Service
RBAC
3.5.1.3.8Checks if Kubernetes Persistent Volume Claims (PVC) are not configured to allow public access. The rule is NON_COMPLIANT if any PVC has an access mode that allows public or excessive permissions, potentially exposing sensitive data.1
Attributes
- Section
3.5.1.3: Primary account number (PAN) is secured wherever it is stored.
- Service
RBAC
3.5.1.3.9Checks if Kubernetes Pods only have read-only access to their root filesystems. The rule is NON_COMPLIANT if the readOnlyRootFilesystem parameter in the pod's SecurityContext is set to 'false'.1
Attributes
- Section
3.5.1.3: Primary account number (PAN) is secured wherever it is stored.
- Service
Core
3.5.1.3.10Checks if Kubernetes Persistent Volumes (PVs) are configured to use a specific mount path other than the default root directory. The rule is NON_COMPLIANT if the specified mount path is '/' (default root directory of the volume).1
Attributes
- Section
3.5.1.3: Primary account number (PAN) is secured wherever it is stored.
- Service
RBAC
3.5.1.3.11Checks if Kubernetes Persistent Volume (PV) access modes enforce a user identity. The rule is NON_COMPLIANT if 'spec.accessModes' is not defined to restrict access, or if specific user identities are not matched with the corresponding Access Control List (ACL) settings.1
Attributes
- Section
3.5.1.3: Primary account number (PAN) is secured wherever it is stored.
- Service
RBAC
3.5.1.3.12Checks if Kubernetes Ingress resources are configured to use TLS certificates from a valid certificate issuer, such as cert-manager, ensuring that all Ingress resources have appropriate TLS settings. This rule is NON_COMPLIANT if at least one Ingress resource has at least one path that is configured without TLS or with a certificate not managed by the specified issuer.1
Attributes
- Section
3.5.1.3: Primary account number (PAN) is secured wherever it is stored.
- Service
API Server
3.5.1.3.13Checks if the Ingress resources in Kubernetes use TLS certificates provided by Kubernetes Secrets. To use this rule, ensure that your Ingress controller is configured with an SSL or HTTPS listener. This rule is only applicable to Ingress resources managing traffic for services in Kubernetes. This rule does not check other types of services like LoadBalancer or NodePort services.1
Attributes
- Section
3.5.1.3: Primary account number (PAN) is secured wherever it is stored.
- Service
API Server
3.5.1.3.14Checks if a Kubernetes cluster has network policies in place to block public access settings. The rule is NON_COMPLIANT if NetworkPolicy is not applied to deny all ingress traffic, or if a NetworkPolicy allows traffic from external sources on ports other than Port 22.1
Attributes
- Section
3.5.1.3: Primary account number (PAN) is secured wherever it is stored.
- Service
Core
3.5.1.3.15Checks if the Kubernetes Role or ClusterRole policies do not allow blocked actions on Kubernetes resources. The rule is NON_COMPLIANT if any blocked action is allowed on Kubernetes resources by the managed Role or ClusterRole policy.0
Attributes
- Section
3.5.1.3: Primary account number (PAN) is secured wherever it is stored.
- Service
Core
3.5.1.3.16Checks if the role-based access control (RBAC) permissions attached to your Kubernetes Service Accounts, Roles, and RoleBindings do not allow unauthorized actions on all Kubernetes resources. The rule is NON_COMPLIANT if any unauthorized action is allowed on all Kubernetes resources in the access control policies.1
Attributes
- Section
3.5.1.3: Primary account number (PAN) is secured wherever it is stored.
- Service
API Server
3.5.1.3.17Checks if Kubernetes Secrets are not marked for deletion. The rule is NON_COMPLIANT if any Secrets are scheduled for deletion.0
Attributes
- Section
3.5.1.3: Primary account number (PAN) is secured wherever it is stored.
- Service
Core
3.5.1.3.18Checks if the Kubernetes Deployment configuration allows public access to its services through LoadBalancer type services or NodePort. If the Deployment configuration allows public access, it is NON_COMPLIANT.0
Attributes
- Section
3.5.1.3: Primary account number (PAN) is secured wherever it is stored.
- Service
Core
3.5.1.3.19Checks if a Kubernetes PersistentVolume (PV) is public. The rule is NON_COMPLIANT if any existing and new PersistentVolume is accessible from outside the cluster.1
Attributes
- Section
3.5.1.3: Primary account number (PAN) is secured wherever it is stored.
- Service
RBAC
3.5.1.3.20Checks if the Kubernetes Pods are not exposed to the public. The rule is NON_COMPLIANT if the Pod's service type is LoadBalancer or NodePort, allowing external access.1
Attributes
- Section
3.5.1.3: Primary account number (PAN) is secured wherever it is stored.
- Service
Core
3.5.1.3.21Checks if Kubernetes PersistentVolume (PV) claims are publicly accessible. The rule is NON_COMPLIANT if any existing and new PersistentVolume claims have public access configurations.1
Attributes
- Section
3.5.1.3: Primary account number (PAN) is secured wherever it is stored.
- Service
RBAC
3.5.1.3.22Checks if Kubernetes clusters have public access enabled. The rule is NON_COMPLIANT if the service is exposed to the internet without proper configuration.1
Attributes
- Section
3.5.1.3: Primary account number (PAN) is secured wherever it is stored.
- Service
API Server
3.5.1.3.23Checks if Kubernetes services have network policies applied that restrict public access. The rule is NON_COMPLIANT if network policies are not in place for the services.1
Attributes
- Section
3.5.1.3: Primary account number (PAN) is secured wherever it is stored.
- Service
Core
3.5.1.3.24Checks if the required network policies for public access are configured at the namespace level. The rule is only NON_COMPLIANT when the network policies do not match the corresponding configurations for public ingress/egress settings.0
Attributes
- Section
3.5.1.3: Primary account number (PAN) is secured wherever it is stored.
- Service
Core
3.5.1.3.25Checks if the required Kubernetes Network Policies are configured at the namespace level. The rule is NON_COMPLIANT if the configuration item does not match one or more settings from parameters (or default).1
Attributes
- Section
3.5.1.3: Primary account number (PAN) is secured wherever it is stored.
- Service
Core
3.5.1.3.26Checks if Kubernetes services are publicly accessible. The rule is NON_COMPLIANT if a Kubernetes service is not listed in the excludedPublicServices parameter and the service type is LoadBalancer or NodePort.1
Attributes
- Section
3.5.1.3: Primary account number (PAN) is secured wherever it is stored.
- Service
API Server
3.5.1.3.28Checks if your Kubernetes persistent volumes do not allow public access. The rule checks the Persistent Volume settings, the StorageClass policies, and the Role-Based Access Control (RBAC) settings.1
Attributes
- Section
3.5.1.3: Primary account number (PAN) is secured wherever it is stored.
- Service
RBAC
3.5.1.3.29Checks if your Kubernetes Persistent Volumes do not allow public write access. The rule verifies the Persistent Volume Claims (PVC), the StorageClass settings, and the access modes of the Persistent Volumes (PV).1
Attributes
- Section
3.5.1.3: Primary account number (PAN) is secured wherever it is stored.
- Service
RBAC
3.5.1.3.30Checks if direct internet access is disabled for a Kubernetes Pod. The rule is NON_COMPLIANT if the Pod is allowed to access the internet.0
Attributes
- Section
3.5.1.3: Primary account number (PAN) is secured wherever it is stored.
- Service
Core
3.5.1.3.31Checks if Kubernetes ConfigMaps owned by the namespace are publicly accessible. The rule is NON_COMPLIANT if ConfigMaps with the owner 'Self' are accessible to unauthorized users.0
Attributes
- Section
3.5.1.3: Primary account number (PAN) is secured wherever it is stored.
- Service
Core
3.6.1: Cryptographic keys used to protect stored account data are secured.94
3.6.1.1Checks if Kubernetes Secrets containing TLS certificates are nearing expiration based on a specified time frame. Secrets can be renewed, but those manually created or managed may not have automatic renewal, leading to a NON_COMPLIANT status if they are about to expire.0
Attributes
- Section
3.6.1: Cryptographic keys used to protect stored account data are secured.
- Service
Core
3.6.1.2Checks if Kubernetes CertificateSigningRequests (CSR) have a root CA that is disabled. The rule is NON_COMPLIANT for CSRs with a status that is not DISABLED.1
Attributes
- Section
3.6.1: Cryptographic keys used to protect stored account data are secured.
- Service
RBAC
3.6.1.3Checks if a Kubernetes ingress resource is configured with an SSL certificate. The rule is NON_COMPLIANT if the ingress does not have an associated TLS secret for HTTPS endpoints.1
Attributes
- Section
3.6.1: Cryptographic keys used to protect stored account data are secured.
- Service
API Server
3.6.1.4Checks if the certificate associated with a Kubernetes Ingress resource is a default certificate. The rule is NON_COMPLIANT if an Ingress resource uses a default SSL certificate provided by the cloud provider.0
Attributes
- Section
3.6.1: Cryptographic keys used to protect stored account data are secured.
- Service
API Server
3.6.1.5Checks if Kubernetes Ingress resources have TLS configurations that use certificates from a trusted certificate authority, ensuring that at least one certificate from a valid source is associated with each Ingress. This rule is NON_COMPLIANT if at least one Ingress resource has a TLS configuration without a valid certificate or is configured with a certificate that is not from a trusted certificate authority.1
Attributes
- Section
3.6.1: Cryptographic keys used to protect stored account data are secured.
- Service
API Server
3.6.1.6Checks if Ingress resources in Kubernetes use SSL certificates provided by Kubernetes Secrets. To use this rule, an Ingress resource must be configured with an HTTPS backend. This rule is only applicable to Ingress resources and does not check Services of type LoadBalancer, ClusterIP, or NodePort.0
Attributes
- Section
3.6.1: Cryptographic keys used to protect stored account data are secured.
- Service
API Server
3.6.1.7Checks if the Kubernetes Role or ClusterRole do not allow blocked actions on Kubernetes resources. The rule is NON_COMPLIANT if any blocked action is allowed by the Role or ClusterRole.0
Attributes
- Section
3.6.1: Cryptographic keys used to protect stored account data are secured.
- Service
RBAC (Role-Based Access Control)
3.6.1.8Checks if the Role-based Access Control (RBAC) policies applied to your Kubernetes users, roles, and service accounts do not allow prohibited actions on all Kubernetes resources. The rule is NON_COMPLIANT if any prohibited action is allowed on any Kubernetes resource in an RBAC policy.1
Attributes
- Section
3.6.1: Cryptographic keys used to protect stored account data are secured.
- Service
RBAC
3.6.1.9Checks if Kubernetes Secrets are not marked for deletion in Kubernetes. The rule is NON_COMPLIANT if any Secrets are scheduled for deletion.0
Attributes
- Section
3.6.1: Cryptographic keys used to protect stored account data are secured.
- Service
RBAC (Role-Based Access Control)
3.6.1.2: Cryptographic keys used to protect stored account data are secured.96
3.6.1.2.1Checks if Kubernetes TLS secrets are due for renewal within the specified number of days. TLS secrets in Kubernetes may need to be manually renewed if they are not automatically managed. The rule is NON_COMPLIANT if your TLS secrets are about to expire.0
Attributes
- Section
3.6.1.2: Cryptographic keys used to protect stored account data are secured.
- Service
Core
3.6.1.2.2Checks if Kubernetes Cluster has a Certificate Authority (CA) that is disabled. The rule is NON_COMPLIANT for root CAs with status that is not DISABLED.1
Attributes
- Section
3.6.1.2: Cryptographic keys used to protect stored account data are secured.
- Service
CONTROLLERMANAGER
3.6.1.2.3Checks if an Ingress resource in Kubernetes uses a TLS certificate. The rule is NON_COMPLIANT if the Ingress resource does not have an associated TLS secret.1
Attributes
- Section
3.6.1.2: Cryptographic keys used to protect stored account data are secured.
- Service
API Server
3.6.1.2.4Checks if the certificate associated with a Kubernetes Ingress resource is the default SSL certificate. The rule is NON_COMPLIANT if an Ingress resource uses the default SSL certificate.0
Attributes
- Section
3.6.1.2: Cryptographic keys used to protect stored account data are secured.
- Service
API Server
3.6.1.2.5Checks if Kubernetes Ingress resources are configured to use TLS certificates from a trusted certificate provider. This rule is NON_COMPLIANT if at least 1 Ingress resource has at least 1 rule configured without a TLS certificate or is configured with a certificate not from a trusted provider.1
Attributes
- Section
3.6.1.2: Cryptographic keys used to protect stored account data are secured.
- Service
API Server
3.6.1.2.6Checks if Ingress resources in Kubernetes use TLS certificates provided by a secret in Kubernetes. To use this rule, an Ingress resource should be configured with a TLS section that references the secret containing the TLS certificate. This rule is only applicable to Ingress configurations and does not apply to other services like NodePort or LoadBalancer services.1
Attributes
- Section
3.6.1.2: Cryptographic keys used to protect stored account data are secured.
- Service
API Server
3.6.1.2.7Checks if the Kubernetes Role-Based Access Control (RBAC) policies that you create do not allow blocked actions on Kubernetes Secrets. The rule is NON_COMPLIANT if any blocked action is allowed on Kubernetes Secrets by the managed RBAC policy.1
Attributes
- Section
3.6.1.2: Cryptographic keys used to protect stored account data are secured.
- Service
RBAC
3.6.1.2.8Checks if the Role-based Access Control (RBAC) policies applied to Kubernetes users, roles, and role bindings do not allow access to restricted actions on all Kubernetes resources. The rule is NON_COMPLIANT if any restricted action is permitted on all Kubernetes resources in a role or role binding.1
Attributes
- Section
3.6.1.2: Cryptographic keys used to protect stored account data are secured.
- Service
API Server
3.6.1.2.9Checks if Kubernetes Secrets are not marked for deletion in the Kubernetes cluster. The rule is NON_COMPLIANT if Secrets are scheduled for deletion.0
Attributes
- Section
3.6.1.2: Cryptographic keys used to protect stored account data are secured.
- Service
Core
3.6.1.3: Cryptographic keys used to protect stored account data are secured.95
3.6.1.3.1Checks if Kubernetes Secrets containing TLS certificates are about to expire within a specified number of days. Certificates can be automatically renewed if managed by cert-manager; however, manually imported certificates may not be renewed automatically. If the TLS certificates in Secrets are nearing expiration, the state is marked as NON_COMPLIANT.0
Attributes
- Section
3.6.1.3: Cryptographic keys used to protect stored account data are secured.
- Service
Core
3.6.1.3.2Checks if Kubernetes Certificate Authority has a root CA that is disabled. The rule is NON_COMPLIANT for root CAs with a status that is not DISABLED.1
Attributes
- Section
3.6.1.3: Cryptographic keys used to protect stored account data are secured.
- Service
CONTROLLERMANAGER
3.6.1.3.3Checks if a Kubernetes Ingress resource is configured with TLS settings. The rule is NON_COMPLIANT if the Ingress resource does not have an associated TLS certificate.1
Attributes
- Section
3.6.1.3: Cryptographic keys used to protect stored account data are secured.
- Service
API Server
3.6.1.3.4Checks if the certificate associated with a Kubernetes Ingress resource is the default SSL certificate. The rule is NON_COMPLIANT if an Ingress resource uses the default SSL certificate.0
Attributes
- Section
3.6.1.3: Cryptographic keys used to protect stored account data are secured.
- Service
API Server
3.6.1.3.5Checks if Kubernetes Ingress resources are configured to use certificates from a certificate management service (e.g., cert-manager) for TLS termination. This rule is NON_COMPLIANT if at least 1 Ingress resource has at least 1 rule that is configured without a TLS certificate or is configured with a non-approved certificate.1
Attributes
- Section
3.6.1.3: Cryptographic keys used to protect stored account data are secured.
- Service
API Server
3.6.1.3.6Checks if the Kubernetes Ingress resource uses SSL certificates provided by a Certificate Manager, such as cert-manager. To use this rule, an HTTPS or TLS-enabled Ingress must be configured. This rule is only applicable to Ingress resources and does not check services directly or other types of load balancers.0
Attributes
- Section
3.6.1.3: Cryptographic keys used to protect stored account data are secured.
- Service
API Server
3.6.1.3.7Checks if the Kubernetes Role-Based Access Control (RBAC) policies that you create do not allow blocked actions on Kubernetes secrets. The rule is NON_COMPLIANT if any blocked action is allowed on Kubernetes secrets by the RBAC policy.1
Attributes
- Section
3.6.1.3: Cryptographic keys used to protect stored account data are secured.
- Service
RBAC
3.6.1.3.8Checks if the role or service accounts in Kubernetes have permissions that allow actions on Kubernetes resources that should be restricted. The rule is NON_COMPLIANT if any disallowed action is permitted through a Role or ClusterRole in Kubernetes RBAC settings.1
Attributes
- Section
3.6.1.3: Cryptographic keys used to protect stored account data are secured.
- Service
RBAC
3.6.1.3.9Checks if Kubernetes Secrets are not marked for deletion. The rule is NON_COMPLIANT if Secrets are scheduled for deletion.0
Attributes
- Section
3.6.1.3: Cryptographic keys used to protect stored account data are secured.
- Service
Core
3.6.1.4: Cryptographic keys used to protect stored account data are secured.85
3.6.1.4.1Checks if Kubernetes Secrets containing TLS certificates are due for renewal within the specified number of days. Certificates managed by external certificate issuers, such as Cert-Manager, may automatically renew, while manually created secrets may require manual intervention. The status is NON_COMPLIANT if secrets with certificates are about to expire.0
Attributes
- Section
3.6.1.4: Cryptographic keys used to protect stored account data are secured.
- Service
Core
3.6.1.4.2Checks if Kubernetes CertificateSigningRequests (CSRs) have a root CA that is not in a valid state. The rule is NON_COMPLIANT for root CAs with status that is not 'Approved' or 'Pending'.1
Attributes
- Section
3.6.1.4: Cryptographic keys used to protect stored account data are secured.
- Service
RBAC
3.6.1.4.3Checks if a Kubernetes Ingress resource is configured with TLS. The rule is NON_COMPLIANT if the Ingress resource does not have an associated TLS secret.1
Attributes
- Section
3.6.1.4: Cryptographic keys used to protect stored account data are secured.
- Service
API Server
3.6.1.4.4Checks if the TLS certificate associated with a Kubernetes Ingress resource is the default SSL certificate. The rule is NON_COMPLIANT if an Ingress resource uses the default SSL certificate.0
Attributes
- Section
3.6.1.4: Cryptographic keys used to protect stored account data are secured.
- Service
API Server
3.6.1.4.5Checks if Kubernetes Ingress resources have TLS configurations that use certificates from a trusted certificate management solution, such as cert-manager. This rule is NON_COMPLIANT if at least 1 Ingress resource has at least 1 TLS configuration that is either missing a certificate or is configured with a certificate that is not managed by cert-manager.1
Attributes
- Section
3.6.1.4: Cryptographic keys used to protect stored account data are secured.
- Service
API Server
3.6.1.4.6Checks if Ingress resources in Kubernetes use SSL certificates provided by Kubernetes Secrets. To use this rule, ensure an Ingress resource is configured with an SSL or HTTPS backend. This rule is only applicable to Ingress configurations targeting HTTP routes and does not apply to ClusterIP or NodePort services.0
Attributes
- Section
3.6.1.4: Cryptographic keys used to protect stored account data are secured.
- Service
API Server
3.6.1.4.7Checks if the Kubernetes Role-Based Access Control (RBAC) policies that you create do not allow actions that are blocked on Kubernetes resources. The rule is NON_COMPLIANT if any blocked action is allowed on Kubernetes resources by the configured RBAC policies.1
Attributes
- Section
3.6.1.4: Cryptographic keys used to protect stored account data are secured.
- Service
RBAC
3.6.1.4.8Checks if the role-based access control (RBAC) policies attached to your Kubernetes service accounts, roles, and role bindings do not allow blocked actions on all Kubernetes resources. The rule is NON_COMPLIANT if any blocked action is allowed on all Kubernetes resources in a RBAC policy.1
Attributes
- Section
3.6.1.4: Cryptographic keys used to protect stored account data are secured.
- Service
API Server
3.7.1: Where cryptography is used to protect stored account data, key management processes and procedures covering all aspects of the key lifecycle are defined and implemented.106
3.7.1.1Checks if Kubernetes Secrets or Ingress resources containing TLS certificates are about to expire within the specified number of days. Certificates issued by external cert management tools (like CertManager) can be automatically renewed, but manually managed certificates require manual renewal. The rule is NON_COMPLIANT if any of your certificates are nearing expiration.0
Attributes
- Section
3.7.1: Where cryptography is used to protect stored account data, key management processes and procedures covering all aspects of the key lifecycle are defined and implemented.
- Service
Core
3.7.1.2Checks if RSA certificates managed by Kubernetes have a key length of at least '2048' bits. The rule is NON_COMPLIANT if the minimum key length is less than 2048 bits.0
Attributes
- Section
3.7.1: Where cryptography is used to protect stored account data, key management processes and procedures covering all aspects of the key lifecycle are defined and implemented.
- Service
Core
3.7.1.3Checks if Kubernetes has a Certificate Authority (CA) that is disabled. The rule is NON_COMPLIANT for root CAs with a status that is not DISABLED.1
Attributes
- Section
3.7.1: Where cryptography is used to protect stored account data, key management processes and procedures covering all aspects of the key lifecycle are defined and implemented.
- Service
CONTROLLERMANAGER
3.7.1.4Checks if a Kubernetes Ingress resource has an associated TLS secret for SSL termination. The rule is NON_COMPLIANT if the Ingress resource does not reference a TLS secret.0
Attributes
- Section
3.7.1: Where cryptography is used to protect stored account data, key management processes and procedures covering all aspects of the key lifecycle are defined and implemented.
- Service
API Server
3.7.1.5Checks if the TLS certificate associated with a Kubernetes Ingress resource is the default certificate. The rule is NON_COMPLIANT if an Ingress uses the default TLS certificate.1
Attributes
- Section
3.7.1: Where cryptography is used to protect stored account data, key management processes and procedures covering all aspects of the key lifecycle are defined and implemented.
- Service
API Server
3.7.1.6Checks if Kubernetes Ingress resources have TLS configurations that are using certificates from a certificate management solution, like Cert-Manager. This rule is NON_COMPLIANT if at least 1 Ingress resource has at least 1 TLS configuration that is not using a certificate from the managed solution or is configured with a certificate that is not managed.1
Attributes
- Section
3.7.1: Where cryptography is used to protect stored account data, key management processes and procedures covering all aspects of the key lifecycle are defined and implemented.
- Service
API Server
3.7.1.7Checks if Kubernetes Ingress resources use SSL certificates provided by a Certificate Authority (e.g., Let's Encrypt) or Kubernetes secrets. To use this rule, configure a TLS section in your Ingress resource. This rule is only applicable to Ingress resources using SSL termination. This rule does not check other service types like NodePort or LoadBalancer services.1
Attributes
- Section
3.7.1: Where cryptography is used to protect stored account data, key management processes and procedures covering all aspects of the key lifecycle are defined and implemented.
- Service
API Server
3.7.1.8Checks if the managed Kubernetes Role-Based Access Control (RBAC) policies that you create do not allow forbidden actions on Kubernetes resources. The rule is NON_COMPLIANT if any forbidden action is allowed on Kubernetes resources by the managed RBAC policy.1
Attributes
- Section
3.7.1: Where cryptography is used to protect stored account data, key management processes and procedures covering all aspects of the key lifecycle are defined and implemented.
- Service
RBAC
3.7.1.9Checks if the Role-based Access Control (RBAC) policies attached to your Kubernetes users, roles, and role bindings do not allow blocked actions on all Kubernetes resources. The rule is NON_COMPLIANT if any blocked action is allowed on all Kubernetes resources in a RBAC policy.1
Attributes
- Section
3.7.1: Where cryptography is used to protect stored account data, key management processes and procedures covering all aspects of the key lifecycle are defined and implemented.
- Service
API Server
3.7.1.10Checks if Kubernetes Secrets are not marked for deletion in Kubernetes. The rule is NON_COMPLIANT if Secrets are scheduled for deletion.0
Attributes
- Section
3.7.1: Where cryptography is used to protect stored account data, key management processes and procedures covering all aspects of the key lifecycle are defined and implemented.
- Service
Core
3.7.2: Where cryptography is used to protect stored account data, key management processes and procedures covering all aspects of the key lifecycle are defined and implemented.97
3.7.2.1Checks if Kubernetes Secrets containing TLS certificates are nearing expiration based on a specified threshold of days. Kubernetes does not automatically renew certificates unless managed by an external controller like cert-manager. The status is NON_COMPLIANT if any managed certificates are about to expire.0
Attributes
- Section
3.7.2: Where cryptography is used to protect stored account data, key management processes and procedures covering all aspects of the key lifecycle are defined and implemented.
- Service
Core
3.7.2.2Checks if Kubernetes CertificateSigningRequest (CSR) has a root certificate that is not marked as revoked. The rule is NON_COMPLIANT for CSRs with a status that is not REVOKED.1
Attributes
- Section
3.7.2: Where cryptography is used to protect stored account data, key management processes and procedures covering all aspects of the key lifecycle are defined and implemented.
- Service
RBAC
3.7.2.3Checks if a Kubernetes Ingress resource is configured with TLS and an associated SSL certificate. The rule is NON_COMPLIANT if the Ingress resource does not have TLS configured or lacks a valid SSL certificate.1
Attributes
- Section
3.7.2: Where cryptography is used to protect stored account data, key management processes and procedures covering all aspects of the key lifecycle are defined and implemented.
- Service
API Server
3.7.2.4Checks if the TLS certificate associated with a Kubernetes Ingress resource is a default SSL certificate. The rule is NON_COMPLIANT if an Ingress uses the default TLS certificate.1
Attributes
- Section
3.7.2: Where cryptography is used to protect stored account data, key management processes and procedures covering all aspects of the key lifecycle are defined and implemented.
- Service
API Server
3.7.2.5Checks if Kubernetes Services of type LoadBalancer have TLS configured with Secrets that contain certificates from Kubernetes Secret Management. This rule is NON_COMPLIANT if at least 1 LoadBalancer service has at least 1 listener that is configured without a TLS Secret or is configured with a TLS Secret that does not contain a valid certificate.1
Attributes
- Section
3.7.2: Where cryptography is used to protect stored account data, key management processes and procedures covering all aspects of the key lifecycle are defined and implemented.
- Service
API Server
3.7.2.6Checks if Ingress controllers use SSL certificates provided by Kubernetes Secrets. To use this rule, ensure that Ingress resources are configured with TLS settings. This rule is only applicable to Ingress controllers. This rule does not check Services or other types of load balancing like NodePort.0
Attributes
- Section
3.7.2: Where cryptography is used to protect stored account data, key management processes and procedures covering all aspects of the key lifecycle are defined and implemented.
- Service
API Server
3.7.2.7Checks if the Kubernetes Role-Based Access Control (RBAC) policies that you create do not allow forbidden actions on Kubernetes resources. The rule is NON_COMPLIANT if any forbidden action is permitted on Kubernetes resources by the managed RBAC policy.1
Attributes
- Section
3.7.2: Where cryptography is used to protect stored account data, key management processes and procedures covering all aspects of the key lifecycle are defined and implemented.
- Service
RBAC
3.7.2.8Checks if the Role-based Access Control (RBAC) policies attached to your Kubernetes users, roles, and clusters do not allow blocked actions on all Kubernetes resources. The rule is NON_COMPLIANT if any blocked action is allowed on all Kubernetes resources in a policy.1
Attributes
- Section
3.7.2: Where cryptography is used to protect stored account data, key management processes and procedures covering all aspects of the key lifecycle are defined and implemented.
- Service
API Server
3.7.2.9Checks if Kubernetes Secrets are not set for deletion. The rule is NON_COMPLIANT if Secrets are marked for deletion.1
Attributes
- Section
3.7.2: Where cryptography is used to protect stored account data, key management processes and procedures covering all aspects of the key lifecycle are defined and implemented.
- Service
Core
3.7.4: Where cryptography is used to protect stored account data, key management processes and procedures covering all aspects of the key lifecycle are defined and implemented.107
3.7.4.1Checks if Kubernetes TLS Secrets in your namespace are marked for expiration within the specified number of days. TLS Certificates managed within Kubernetes can be set for automatic renewal using tools like cert-manager. The rule is NON_COMPLIANT if your TLS secrets are about to expire.1
Attributes
- Section
3.7.4: Where cryptography is used to protect stored account data, key management processes and procedures covering all aspects of the key lifecycle are defined and implemented.
- Service
API Server
3.7.4.2Checks if Kubernetes has a Certificate Signing Request (CSR) approved that is not in a terminal state. The rule is NON_COMPLIANT for CSRs that are not approved or rejected.0
Attributes
- Section
3.7.4: Where cryptography is used to protect stored account data, key management processes and procedures covering all aspects of the key lifecycle are defined and implemented.
- Service
Core
3.7.4.3Checks if a Kubernetes Ingress resource has TLS configured. The rule is NON_COMPLIANT if the Ingress does not have an associated TLS secret for SSL termination.0
Attributes
- Section
3.7.4: Where cryptography is used to protect stored account data, key management processes and procedures covering all aspects of the key lifecycle are defined and implemented.
- Service
API Server
3.7.4.4Checks if the TLS certificate associated with an Ingress resource in Kubernetes is a default or autogenerated certificate. The rule is NON_COMPLIANT if an Ingress resource is using a default or autogenerated TLS certificate instead of a managed or custom TLS certificate.1
Attributes
- Section
3.7.4: Where cryptography is used to protect stored account data, key management processes and procedures covering all aspects of the key lifecycle are defined and implemented.
- Service
API Server
3.7.4.5Checks if automatic key rotation is enabled for each key and matches to the key ID of the customer created Kubernetes Secret. The rule is NON_COMPLIANT if the Kubernetes ServiceAccount role for a resource does not have the ability to get and describe Secrets.1
Attributes
- Section
3.7.4: Where cryptography is used to protect stored account data, key management processes and procedures covering all aspects of the key lifecycle are defined and implemented.
- Service
CONTROLLERMANAGER
3.7.4.6Checks if Kubernetes Services of type LoadBalancer have TLS settings configured with certificates from a specified secret. This rule is NON_COMPLIANT if at least 1 LoadBalancer service has at least 1 listener that is configured without a valid TLS secret or is configured with a certificate different from the specified one.1
Attributes
- Section
3.7.4: Where cryptography is used to protect stored account data, key management processes and procedures covering all aspects of the key lifecycle are defined and implemented.
- Service
API Server
3.7.4.7Checks if the Ingress resources in Kubernetes use TLS certificates provided by Kubernetes Secrets. To use this rule, configure an Ingress resource with TLS settings using the appropriate Secret. This rule is only applicable to Ingress resources and does not apply to Services or other types of Load Balancers.1
Attributes
- Section
3.7.4: Where cryptography is used to protect stored account data, key management processes and procedures covering all aspects of the key lifecycle are defined and implemented.
- Service
API Server
3.7.4.8Checks if the managed Kubernetes Role-Based Access Control (RBAC) policies that you create do not allow blocked actions on Kubernetes resources. The rule is NON_COMPLIANT if any blocked action is allowed on Kubernetes resources by the managed RBAC policy.1
Attributes
- Section
3.7.4: Where cryptography is used to protect stored account data, key management processes and procedures covering all aspects of the key lifecycle are defined and implemented.
- Service
RBAC
3.7.4.9Checks if the Role policies attached to your Kubernetes service accounts do not allow actions that are restricted on all cluster resources. The rule is considered NON_COMPLIANT if any restricted action is allowed in the Role binding policies.1
Attributes
- Section
3.7.4: Where cryptography is used to protect stored account data, key management processes and procedures covering all aspects of the key lifecycle are defined and implemented.
- Service
RBAC
3.7.4.10Checks if Kubernetes Secrets are not marked for deletion. The rule is NON_COMPLIANT if Secrets are scheduled for deletion.0
Attributes
- Section
3.7.4: Where cryptography is used to protect stored account data, key management processes and procedures covering all aspects of the key lifecycle are defined and implemented.
- Service
Core
3.7.5: Where cryptography is used to protect stored account data, key management processes and procedures covering all aspects of the key lifecycle are defined and implemented.20
3.7.5.1Checks if Kubernetes TLS Secrets in your cluster are marked for expiration within the specified number of days. TLS Secrets in Kubernetes must be manually renewed; Kubernetes does not automatically renew them. The rule is NON_COMPLIANT if your TLS Secrets are about to expire.0
Attributes
- Section
3.7.5: Where cryptography is used to protect stored account data, key management processes and procedures covering all aspects of the key lifecycle are defined and implemented.
- Service
Core
3.7.5.2Verifies if automatic key rotation is enabled for each key and matches to the key ID of the customer created Kubernetes Secret. The rule is NON_COMPLIANT if the Service Account for a resource does not have the required permissions to manage Secrets.0
Attributes
- Section
3.7.5: Where cryptography is used to protect stored account data, key management processes and procedures covering all aspects of the key lifecycle are defined and implemented.
- Service
Core
3.7.6: Where cryptography is used to protect stored account data, key management processes and procedures covering all aspects of the key lifecycle are defined and implemented.95
3.7.6.1Checks if Kubernetes Secrets containing TLS certificates are nearing expiration based on specified threshold. Kubernetes does not automatically renew imported certificates unless managed through an appropriate controller. The rule is NON_COMPLIANT if any certificates are about to expire.1
Attributes
- Section
3.7.6: Where cryptography is used to protect stored account data, key management processes and procedures covering all aspects of the key lifecycle are defined and implemented.
- Service
KUBELET
3.7.6.2Checks if Kubernetes has a CertificateSigningRequest (CSR) that is approved. The rule is NON_COMPLIANT for CSRs that are not approved.1
Attributes
- Section
3.7.6: Where cryptography is used to protect stored account data, key management processes and procedures covering all aspects of the key lifecycle are defined and implemented.
- Service
RBAC
3.7.6.3Checks if a Kubernetes Ingress resource uses TLS for secure connections. The rule is NON_COMPLIANT if the Ingress resource does not have an associated TLS secret.0
Attributes
- Section
3.7.6: Where cryptography is used to protect stored account data, key management processes and procedures covering all aspects of the key lifecycle are defined and implemented.
- Service
API Server
3.7.6.4Checks if the certificate associated with a Kubernetes Ingress resource is using the default SSL certificate. The rule is NON_COMPLIANT if an Ingress resource uses the default SSL certificate.0
Attributes
- Section
3.7.6: Where cryptography is used to protect stored account data, key management processes and procedures covering all aspects of the key lifecycle are defined and implemented.
- Service
API Server
3.7.6.5Checks if Kubernetes Services of type LoadBalancer have configured TLS termination using certificates from a trusted certificate management solution (e.g. cert-manager). This rule is NON_COMPLIANT if at least 1 LoadBalancer service has at least 1 listener that is configured without a TLS certificate or is configured with a certificate that is not from a trusted source.1
Attributes
- Section
3.7.6: Where cryptography is used to protect stored account data, key management processes and procedures covering all aspects of the key lifecycle are defined and implemented.
- Service
API Server
3.7.6.6Checks if Kubernetes Ingress resources utilize TLS secrets for SSL termination. To use this rule, ensure that Ingress is configured with TLS settings. This rule is only applicable to Ingress resources and does not check services that do not involve SSL termination.0
Attributes
- Section
3.7.6: Where cryptography is used to protect stored account data, key management processes and procedures covering all aspects of the key lifecycle are defined and implemented.
- Service
API Server
3.7.6.7Verifies that the Kubernetes Role-Based Access Control (RBAC) policies do not permit actions that are disallowed by the cluster's security context. The rule is NON_COMPLIANT if any disallowed actions are permitted by the Kubernetes RBAC policy.1
Attributes
- Section
3.7.6: Where cryptography is used to protect stored account data, key management processes and procedures covering all aspects of the key lifecycle are defined and implemented.
- Service
RBAC
3.7.6.8Checks if the Role-based Access Control (RBAC) policies attached to your Kubernetes users, roles, and role bindings do not allow blocked actions on all Kubernetes secrets. The rule is NON_COMPLIANT if any blocked action is allowed on all Kubernetes secrets in an RBAC policy.1
Attributes
- Section
3.7.6: Where cryptography is used to protect stored account data, key management processes and procedures covering all aspects of the key lifecycle are defined and implemented.
- Service
RBAC
3.7.6.9Checks if Kubernetes Secrets are not marked for deletion. The rule is NON_COMPLIANT if Secrets are scheduled for deletion.0
Attributes
- Section
3.7.6: Where cryptography is used to protect stored account data, key management processes and procedures covering all aspects of the key lifecycle are defined and implemented.
- Service
Core
3.7.7: Where cryptography is used to protect stored account data, key management processes and procedures covering all aspects of the key lifecycle are defined and implemented.96
3.7.7.1Checks if Kubernetes Secrets containing TLS certificates in your cluster are about to expire within the specified number of days. Certificates issued by Kubernetes can be automatically renewed with appropriate configurations, but manually imported certificates may require manual renewal. The rule is NON_COMPLIANT if your secrets (certificates) are approaching expiration.0
Attributes
- Section
3.7.7: Where cryptography is used to protect stored account data, key management processes and procedures covering all aspects of the key lifecycle are defined and implemented.
- Service
RBAC (Role-Based Access Control)
3.7.7.2Checks if Kubernetes CA (Certificate Authority) has a root CA that is disabled. The rule is NON_COMPLIANT for root CAs with status that is not DISABLED.1
Attributes
- Section
3.7.7: Where cryptography is used to protect stored account data, key management processes and procedures covering all aspects of the key lifecycle are defined and implemented.
- Service
CONTROLLERMANAGER
3.7.7.3Checks if a Kubernetes Ingress resource is configured with TLS. The rule is NON_COMPLIANT if the Ingress does not have a TLS secret associated with it for secure connections.1
Attributes
- Section
3.7.7: Where cryptography is used to protect stored account data, key management processes and procedures covering all aspects of the key lifecycle are defined and implemented.
- Service
API Server
3.7.7.4Checks if the certificate associated with a Kubernetes Ingress resource is the default SSL certificate. The rule is NON_COMPLIANT if an Ingress resource uses the default SSL certificate.0
Attributes
- Section
3.7.7: Where cryptography is used to protect stored account data, key management processes and procedures covering all aspects of the key lifecycle are defined and implemented.
- Service
API Server
3.7.7.5Checks if Kubernetes Services of type LoadBalancer have annotations that specify certificates from a certificate manager (like Cert-Manager). This rule is NON_COMPLIANT if at least 1 Service of type LoadBalancer has an annotation configured without a valid certificate reference or is configured with a certificate different from a managed certificate.1
Attributes
- Section
3.7.7: Where cryptography is used to protect stored account data, key management processes and procedures covering all aspects of the key lifecycle are defined and implemented.
- Service
CONTROLLERMANAGER
3.7.7.6Checks if Ingress resources in Kubernetes are using TLS/SSL certificates managed by Kubernetes secrets. To use this rule, an Ingress must be configured with TLS settings. This rule is only applicable to Ingress resources and does not check LoadBalancer services or NodePort services.1
Attributes
- Section
3.7.7: Where cryptography is used to protect stored account data, key management processes and procedures covering all aspects of the key lifecycle are defined and implemented.
- Service
API Server
3.7.7.7Checks if the Kubernetes RBAC (Role-Based Access Control) policies that you create do not allow blocked actions on Kubernetes objects. The rule is NON_COMPLIANT if any blocked action is allowed on Kubernetes objects by the defined RBAC policies.1
Attributes
- Section
3.7.7: Where cryptography is used to protect stored account data, key management processes and procedures covering all aspects of the key lifecycle are defined and implemented.
- Service
RBAC
3.7.7.8Checks if the Role-Based Access Control (RBAC) policies attached to your Kubernetes users, service accounts, and roles do not allow blocked actions on all Kubernetes resources. The rule is NON_COMPLIANT if any blocked action is allowed on all Kubernetes resources in a role or cluster role.1
Attributes
- Section
3.7.7: Where cryptography is used to protect stored account data, key management processes and procedures covering all aspects of the key lifecycle are defined and implemented.
- Service
API Server
3.7.7.9Checks if Kubernetes Secrets are not marked for deletion. The rule is NON_COMPLIANT if Secrets are scheduled for deletion.0
Attributes
- Section
3.7.7: Where cryptography is used to protect stored account data, key management processes and procedures covering all aspects of the key lifecycle are defined and implemented.
- Service
Core
4.2.1: PAN is protected with strong cryptography during transmission.182
4.2.1.1Checks if all Ingress resources have configured HTTP to HTTPS redirection. The rule is NON_COMPLIANT if one or more Ingress resources do not have HTTP to HTTPS redirection in place or if any Ingress resources forward traffic to an HTTP service instead of redirecting it.0
Attributes
- Section
4.2.1: PAN is protected with strong cryptography during transmission.
- Service
API Server
4.2.1.2Checks if Kubernetes Ingress resources are using deprecated SSL protocols for HTTPS communication between Ingress controllers and backend services. This rule is NON_COMPLIANT for an Ingress resource if any 'sslProtocols' includes 'SSLv3'.0
Attributes
- Section
4.2.1: PAN is protected with strong cryptography during transmission.
- Service
API Server
4.2.1.3Checks if Kubernetes Ingress resources are enforcing secure communication; the rule is NON_COMPLIANT if the Ingress resource allows 'HTTP' traffic or if it has 'RedirectToHttps' disabled for HTTP routes.0
Attributes
- Section
4.2.1: PAN is protected with strong cryptography during transmission.
- Service
API Server
4.2.1.4Checks if your Kubernetes Ingress resources enforce HTTPS. The rule is NON_COMPLIANT if the Ingress resource allows HTTP traffic without a redirect to HTTPS.0
Attributes
- Section
4.2.1: PAN is protected with strong cryptography during transmission.
- Service
API Server
4.2.1.5Checks if your Kubernetes cluster has network policies applied to ensure that traffic between pods is encrypted using TLS. The rule is NON_COMPLIANT if a pod does not have TLS encryption for network communication.0
Attributes
- Section
4.2.1: PAN is protected with strong cryptography during transmission.
- Service
Core
4.2.1.6Checks if Kubernetes database connection settings are configured with SSL. The rule is NON_COMPLIANT if the database connection does not have SSL configured.0
Attributes
- Section
4.2.1: PAN is protected with strong cryptography during transmission.
- Service
Core
4.2.1.7Checks if Kubernetes Secrets for Redis data stores are encrypted at rest. The rule is NON_COMPLIANT if encryption is not enabled.0
Attributes
- Section
4.2.1: PAN is protected with strong cryptography during transmission.
- Service
Core
4.2.1.9Check if the OpenSearch Service nodes (previously known as Elasticsearch) in Kubernetes have end-to-end encryption enabled. The rule is NON_COMPLIANT if the node-to-node encryption is not enabled.0
Attributes
- Section
4.2.1: PAN is protected with strong cryptography during transmission.
- Service
OpenSearch Service
4.2.1.10Checks if the Ingress resources use SSL certificates provided by Kubernetes Secrets or external cert-manager. To use this rule, ensure that an SSL or HTTPS listener is configured in the Ingress resource. This rule is only applicable to Ingress controllers like NGINX Ingress Controller and Traefik. This rule does not check other types of services or load balancers.0
Attributes
- Section
4.2.1: PAN is protected with strong cryptography during transmission.
- Service
API Server
4.2.1.11Checks whether your Kubernetes Ingress resources with TLS configurations are using a custom TLS policy. The rule is only applicable if there are Ingress resources configured with TLS.0
Attributes
- Section
4.2.1: PAN is protected with strong cryptography during transmission.
- Service
API Server
4.2.1.12Checks if your Kubernetes Ingress resources use a predefined TLS configuration. The rule is NON_COMPLIANT if the Ingress TLS configuration does not equal the value of the parameter 'predefinedTLSConfig'.1
Attributes
- Section
4.2.1: PAN is protected with strong cryptography during transmission.
- Service
API Server
4.2.1.13Checks if your Kubernetes Service is configured with HTTPS or TLS termination. The rule is NON_COMPLIANT if a Service does not have HTTPS or TLS configured.1
Attributes
- Section
4.2.1: PAN is protected with strong cryptography during transmission.
- Service
API Server
4.2.1.14Checks if Kubernetes clusters have Network Policies enabled. The rule is NON_COMPLIANT if a Network Policy is not applied to the namespace or the Network Policy does not satisfy the specified rule parameters.0
Attributes
- Section
4.2.1: PAN is protected with strong cryptography during transmission.
- Service
Core
4.2.1.15Checks if a Kubernetes cluster enforces encryption in transit for communications between pods using TLS. The rule is NON_COMPLIANT if plain text communication is enabled for in-cluster pod-to-pod connections.0
Attributes
- Section
4.2.1: PAN is protected with strong cryptography during transmission.
- Service
Core
4.2.1.16Checks whether connections to OpenSearch domains are using HTTPS. The rule is NON_COMPLIANT if the OpenSearch domain 'EnforceHTTPS' is not 'true' or is 'true' and 'TLSSecurityPolicy' is not included in supported 'tlsPolicies'.0
Attributes
- Section
4.2.1: PAN is protected with strong cryptography during transmission.
- Service
OpenSearch
4.2.1.17Check if Kubernetes pods have encrypted communication between them. The rule is NON_COMPLIANT if the network policies that enforce pod-to-pod encryption are not implemented.0
Attributes
- Section
4.2.1: PAN is protected with strong cryptography during transmission.
- Service
Core
4.2.1.18Checks if Kubernetes clusters require TLS/SSL encryption for communication with SQL clients. The rule is NON_COMPLIANT if any Kubernetes SQL client connection does not have TLS/SSL enabled.0
Attributes
- Section
4.2.1: PAN is protected with strong cryptography during transmission.
- Service
Core
4.2.1.19Checks if Kubernetes Ingress resources have annotations enforcing HTTPS and preventing HTTP traffic. The rule is NON_COMPLIANT if any Ingress resource allows HTTP traffic without redirection to HTTPS.0
Attributes
- Section
4.2.1: PAN is protected with strong cryptography during transmission.
- Service
API Server
4.2.1.1: PAN is protected with strong cryptography during transmission.269
4.2.1.1.1Checks if Kubernetes Secrets containing TLS certificates are marked for expiration within the specified number of days. Auto-generated certificates by a CertificateIssuer or a CertificateManagement controller are usually auto-renewed. User-managed certificates need manual renewal. The rule is NON_COMPLIANT if your secrets are about to expire.0
Attributes
- Section
4.2.1.1: PAN is protected with strong cryptography during transmission.
- Service
Core
4.2.1.1.2Checks if a Kubernetes Cluster has a Root Certificate Authority (CA) that is disabled. The rule is NON_COMPLIANT for Root CAs with a status that is not DISABLED.1
Attributes
- Section
4.2.1.1: PAN is protected with strong cryptography during transmission.
- Service
CONTROLLERMANAGER
4.2.1.1.3Checks if HTTP to HTTPS redirection is configured on all Ingress resources in Kubernetes. The rule is NON_COMPLIANT if one or more Ingress resources do not have a redirect from HTTP to HTTPS configured. The rule is also NON_COMPLIANT if one or more Ingress resources are forwarding traffic to an HTTP service instead of redirecting to HTTPS.0
Attributes
- Section
4.2.1.1: PAN is protected with strong cryptography during transmission.
- Service
API Server
4.2.1.1.4Checks if a Kubernetes Ingress resource is configured with an SSL certificate. The rule is NON_COMPLIANT if the Ingress resource does not have an associated TLS secret for SSL termination.0
Attributes
- Section
4.2.1.1: PAN is protected with strong cryptography during transmission.
- Service
API Server
4.2.1.1.5Checks if the TLS certificate associated with a Kubernetes Ingress resource is the default SSL certificate. The rule is NON_COMPLIANT if an Ingress resource uses the default SSL certificate.0
Attributes
- Section
4.2.1.1: PAN is protected with strong cryptography during transmission.
- Service
API Server
4.2.1.1.6Checks if Kubernetes Ingress is using deprecated SSL protocols for HTTPS communication between Ingress controllers and backend services. This rule is NON_COMPLIANT for an Ingress resource if any 'tls' specifications include 'SSLv3'.0
Attributes
- Section
4.2.1.1: PAN is protected with strong cryptography during transmission.
- Service
API Server
4.2.1.1.7Checks if Kubernetes Ingress resources are encrypting traffic to backend services. The rule is NON_COMPLIANT if 'backend.servicePort' is configured for non-SSL (HTTP) traffic or if 'backend.servicePort' is configured for SSL traffic and 'spec.tls' is not properly set up for secure communication with the backend services.0
Attributes
- Section
4.2.1.1: PAN is protected with strong cryptography during transmission.
- Service
API Server
4.2.1.1.8Checks if your Kubernetes Ingress resources enforce HTTPS by verifying that the nginx.ingress.kubernetes.io/ssl-redirect annotation is set to 'true'. The rule is NON_COMPLIANT if this annotation is not present or set to 'false'.0
Attributes
- Section
4.2.1.1: PAN is protected with strong cryptography during transmission.
- Service
API Server
4.2.1.1.9Checks if your Kubernetes cluster has network policies applied to ensure that traffic between pods is encrypted using TLS. The rule is NON_COMPLIANT if a pod communication does not enforce TLS encryption.0
Attributes
- Section
4.2.1.1: PAN is protected with strong cryptography during transmission.
- Service
Core
4.2.1.1.10Checks if Kubernetes database connections are configured with SSL. The rule is NON_COMPLIANT if the database does not have SSL enabled for connections.0
Attributes
- Section
4.2.1.1: PAN is protected with strong cryptography during transmission.
- Service
Core
4.2.1.1.12Checks if Kubernetes Redis pods have encryption-in-transit enabled. The rule is NON_COMPLIANT for a Redis pod if 'encryption-in-transit' is not configured or set to 'false'.0
Attributes
- Section
4.2.1.1: PAN is protected with strong cryptography during transmission.
- Service
Core
4.2.1.1.13Check if all OpenSearch (Elasticsearch) nodes in the Kubernetes cluster have end-to-end encryption enabled. The status is NON_COMPLIANT if the node-to-node encryption is not configured for the OpenSearch deployment.0
Attributes
- Section
4.2.1.1: PAN is protected with strong cryptography during transmission.
- Service
OpenSearch
4.2.1.1.14Checks if Kubernetes Services of type LoadBalancer have HTTPS configured with trusted TLS certificates, ensuring that at least 1 Service does not have a valid certificate issued by a trusted Certificate Authority or is misconfigured with a certificate that is not trusted.1
Attributes
- Section
4.2.1.1: PAN is protected with strong cryptography during transmission.
- Service
API Server
4.2.1.1.15Checks if the Ingress resources in Kubernetes use TLS certificates provided by a Certificate Management solution (like cert-manager). To apply this rule, use an Ingress resource configured with TLS settings. This rule is not applicable to Services without Ingress or other types of Load Balancers (like NodePort or ClusterIP).1
Attributes
- Section
4.2.1.1: PAN is protected with strong cryptography during transmission.
- Service
API Server
4.2.1.1.16Checks whether your Kubernetes Ingress resources are using a custom TLS configuration. The rule is only applicable if there are TLS-enabled Ingress resources.0
Attributes
- Section
4.2.1.1: PAN is protected with strong cryptography during transmission.
- Service
API Server
4.2.1.1.17Checks if your Kubernetes Ingress resources have SSL/TLS configurations that use a predefined policy. The rule is NON_COMPLIANT if the Ingress TLS settings do not match the specified 'predefinedPolicyName'.0
Attributes
- Section
4.2.1.1: PAN is protected with strong cryptography during transmission.
- Service
API Server
4.2.1.1.18Checks if your Kubernetes Service is configured with TLS termination or HTTPS endpoints. The rule is NON_COMPLIANT if a Service does not have TLS settings configured.1
Attributes
- Section
4.2.1.1: PAN is protected with strong cryptography during transmission.
- Service
API Server
4.2.1.1.19Checks if Kubernetes clusters have NetworkPolicies implemented. The rule is NON_COMPLIANT if there are no NetworkPolicies applied to the namespace or the existing NetworkPolicies do not satisfy the specified rule parameters.0
Attributes
- Section
4.2.1.1: PAN is protected with strong cryptography during transmission.
- Service
Core
4.2.1.1.20Checks if the Kubernetes Role or ClusterRole permissions do not allow blocked actions on Secrets. The rule is NON_COMPLIANT if any blocked action is allowed on Secrets by the Kubernetes Role or ClusterRole.1
Attributes
- Section
4.2.1.1: PAN is protected with strong cryptography during transmission.
- Service
RBAC
4.2.1.1.21Checks if the Role-based Access Control (RBAC) policies attached to your Kubernetes users, service accounts, and roles do not allow blocked actions on all Kubernetes resources. The rule is NON_COMPLIANT if any blocked action is allowed on all resources in an RBAC policy.1
Attributes
- Section
4.2.1.1: PAN is protected with strong cryptography during transmission.
- Service
API Server
4.2.1.1.22Checks if Kubernetes Secrets are not marked for deletion and are actively usable. The rule is NON_COMPLIANT if any Secrets are marked for deletion.1
Attributes
- Section
4.2.1.1: PAN is protected with strong cryptography during transmission.
- Service
Core
4.2.1.1.23Checks if a Kubernetes cluster enforces encryption in transit for communication between services using TLS. The rule is NON_COMPLIANT if plain text communication is enabled for service-to-service connections in the cluster.0
Attributes
- Section
4.2.1.1: PAN is protected with strong cryptography during transmission.
- Service
Core
4.2.1.1.24Checks whether connections to OpenSearch domains are using HTTPS. The rule is NON_COMPLIANT if the Kubernetes OpenSearch domain 'EnforceHTTPS' is not 'true' or is 'true' and 'TLSSecurityPolicy' is not in 'tlsPolicies'.0
Attributes
- Section
4.2.1.1: PAN is protected with strong cryptography during transmission.
- Service
OpenSearch
4.2.1.1.25Check if Kubernetes cluster nodes have encryption enabled for communication between them. The rule is NON_COMPLIANT if the encryption for communication between nodes is not enabled.1
Attributes
- Section
4.2.1.1: PAN is protected with strong cryptography during transmission.
- Service
KUBELET
4.2.1.1.26Checks if Kubernetes/Openshift clusters require TLS/SSL encryption for communication to SQL clients. The rule is NON_COMPLIANT if any PostgreSQL or MySQL database instance in the cluster does not have TLS/SSL settings enabled.0
Attributes
- Section
4.2.1.1: PAN is protected with strong cryptography during transmission.
- Service
Database Service
4.2.1.1.27Checks if Kubernetes services have policies that require requests to use HTTPS. The rule is NON_COMPLIANT if any service is configured to allow HTTP requests.1
Attributes
- Section
4.2.1.1: PAN is protected with strong cryptography during transmission.
- Service
API Server
5.3.4: Anti-malware mechanisms and processes are active, maintained, and monitored.3413
5.3.4.1Checks if Kubernetes Ingress resources have access logging enabled. The rule is NON_COMPLIANT if 'accessLog' annotations are not present in the Ingress configuration.0
Attributes
- Section
5.3.4: Anti-malware mechanisms and processes are active, maintained, and monitored.
- Service
API Server
5.3.4.2Checks if all methods in Kubernetes Ingress resources have access logging enabled by validating the configuration of the Ingress controller. The rule is NON_COMPLIANT if access logging is not enabled, or if the log level is neither ERROR nor INFO.0
Attributes
- Section
5.3.4: Anti-malware mechanisms and processes are active, maintained, and monitored.
- Service
API Server
5.3.4.3Checks if OpenTelemetry tracing is enabled on Kubernetes Ingress controllers. The rule is COMPLIANT if OpenTelemetry tracing is enabled and NON_COMPLIANT otherwise.0
Attributes
- Section
5.3.4: Anti-malware mechanisms and processes are active, maintained, and monitored.
- Service
API Server
5.3.4.4Checks if a Kubernetes API (such as an Agones or custom resource-based API) has logging enabled. The rule is NON_COMPLIANT if logging is not enabled, or 'logLevel' is neither ERROR nor ALL.1
Attributes
- Section
5.3.4: Anti-malware mechanisms and processes are active, maintained, and monitored.
- Service
API Server
5.3.4.5Checks if Services of type LoadBalancer in Kubernetes are configured with user-defined health check settings. The rule is NON_COMPLIANT if the health check settings do not match the user-defined configurations.0
Attributes
- Section
5.3.4: Anti-malware mechanisms and processes are active, maintained, and monitored.
- Service
Scheduler
5.3.4.6Checks if Kubernetes Ingress resources are configured to log access to a specified logging service. The rule is NON_COMPLIANT if an Ingress resource does not have logging configured.0
Attributes
- Section
5.3.4: Anti-malware mechanisms and processes are active, maintained, and monitored.
- Service
API Server
5.3.4.7Checks if at least one Kubernetes audit policy is logging requests to all namespaces. The rule is NON_COMPLIANT if there are no audit policies or if audit policies do not log S3-like storage access events.1
Attributes
- Section
5.3.4: Anti-malware mechanisms and processes are active, maintained, and monitored.
- Service
API Server
5.3.4.8Checks that there is at least one Kubernetes audit policy defined that follows security best practices. This rule is COMPLIANT if there is at least one audit policy that meets all of the following criteria specified for security configurations.1
Attributes
- Section
5.3.4: Anti-malware mechanisms and processes are active, maintained, and monitored.
- Service
API Server
5.3.4.10Checks if a Kubernetes Pod has at least one logging mechanism enabled. The rule is NON_COMPLIANT if all logging configurations for the Pod are set to 'DISABLED'.0
Attributes
- Section
5.3.4: Anti-malware mechanisms and processes are active, maintained, and monitored.
- Service
Core
5.3.4.11Checks if a Kubernetes logging configuration (e.g., Fluentd, Elasticsearch) has a log retention policy set to retain logs for more than 365 days or a specified retention period. The rule is NON_COMPLIANT if the retention period is less than MinRetentionTime, if specified, or else 365 days.1
Attributes
- Section
5.3.4: Anti-malware mechanisms and processes are active, maintained, and monitored.
- Service
API Server
5.3.4.12Checks if logging is enabled with a valid severity level for Kubernetes Pod events. The rule is NON_COMPLIANT if logging is not enabled or Pod logging of a Kubernetes cluster has a severity level that is not valid.0
Attributes
- Section
5.3.4: Anti-malware mechanisms and processes are active, maintained, and monitored.
- Service
Core
5.3.4.13Checks if a Kubernetes cluster has audit logging enabled. The rule is NON_COMPLIANT if a Kubernetes cluster does not have audit logging enabled.1
Attributes
- Section
5.3.4: Anti-malware mechanisms and processes are active, maintained, and monitored.
- Service
API Server
5.3.4.14Checks if the Kubernetes cluster has logging enabled for client connections to the API server. The rule is NON_COMPLIANT if 'apiserver-logging.enabled' is set to false.1
Attributes
- Section
5.3.4: Anti-malware mechanisms and processes are active, maintained, and monitored.
- Service
API Server
5.3.4.15Checks if logging configuration is set on active Kubernetes Pod specifications. This rule is NON_COMPLIANT if an active Pod does not have a log configuration defined or if the logging configuration is set to null in at least one container definition.0
Attributes
- Section
5.3.4: Anti-malware mechanisms and processes are active, maintained, and monitored.
- Service
Core
5.3.4.16Checks if a Kubernetes cluster is configured with logging enabled. The rule is NON_COMPLIANT if logging for the Kubernetes clusters is not enabled for all log types, such as audit logs, controller logs, and application logs.1
Attributes
- Section
5.3.4: Anti-malware mechanisms and processes are active, maintained, and monitored.
- Service
API Server
5.3.4.17Checks if Kubernetes clusters are configured to send logs to a centralized logging system like Elasticsearch or a logging stack such as EFK (Elasticsearch, Fluentd, Kibana). The rule is COMPLIANT if logging is enabled and set up for the pods in the Kubernetes cluster. This rule is NON_COMPLIANT if logging is not configured properly.0
Attributes
- Section
5.3.4: Anti-malware mechanisms and processes are active, maintained, and monitored.
- Service
Core
5.3.4.18Checks if Kubernetes pods are configured to send logs to a specified logging solution (e.g., Fluentd, Elasticsearch). The rule is NON_COMPLIANT if pod logging is not enabled or misconfigured.0
Attributes
- Section
5.3.4: Anti-malware mechanisms and processes are active, maintained, and monitored.
- Service
Core
5.3.4.19Checks if the Kubernetes Ingress resource has access logging enabled by examining if the specified logging annotation is set to true. The rule is NON_COMPLIANT if the access logs are not enabled or the logging destination does not match the defined S3 bucket.0
Attributes
- Section
5.3.4: Anti-malware mechanisms and processes are active, maintained, and monitored.
- Service
API Server
5.3.4.20Checks if Kubernetes clusters have audit logging enabled. The rule is NON_COMPLIANT if audit logging is not enabled for the cluster.1
Attributes
- Section
5.3.4: Anti-malware mechanisms and processes are active, maintained, and monitored.
- Service
API Server
5.3.4.21Checks if a Kubernetes cluster has audit logging enabled. The rule is NON_COMPLIANT if the cluster does not have audit logging enabled.1
Attributes
- Section
5.3.4: Anti-malware mechanisms and processes are active, maintained, and monitored.
- Service
API Server
5.3.4.23Checks if a Kubernetes cluster has logging enabled for auditing. The rule is NON_COMPLIANT if the Kubernetes cluster does not have audit logging enabled.1
Attributes
- Section
5.3.4: Anti-malware mechanisms and processes are active, maintained, and monitored.
- Service
API Server
5.3.4.24Checks if Kubernetes Network Policies have logging enabled. The rule is NON_COMPLIANT if a logging type is not configured. You can specify which logging type you want the rule to check.0
Attributes
- Section
5.3.4: Anti-malware mechanisms and processes are active, maintained, and monitored.
- Service
Core
5.3.4.25Checks if Kubernetes clusters have audit logging enabled. The rule is NON_COMPLIANT if a Kubernetes cluster does not have audit logging enabled.1
Attributes
- Section
5.3.4: Anti-malware mechanisms and processes are active, maintained, and monitored.
- Service
API Server
5.3.4.26Checks if Kubernetes clusters are configured to send logs to a logging system (e.g., Elasticsearch, Fluentd, or a similar logging service). The rule is NON_COMPLIANT if logging is not configured.0
Attributes
- Section
5.3.4: Anti-malware mechanisms and processes are active, maintained, and monitored.
- Service
Core
5.3.4.27Checks if Kubernetes clusters are configured to publish logs to a centralized logging system (e.g., Elasticsearch or Fluentd). The rule is NON_COMPLIANT if clusters do not have logging configured to publish logs appropriately.0
Attributes
- Section
5.3.4: Anti-malware mechanisms and processes are active, maintained, and monitored.
- Service
Core
5.3.4.28Checks if the logging for Kubernetes pods is enabled. The rule is NON_COMPLIANT if any pod logs are not being captured.0
Attributes
- Section
5.3.4: Anti-malware mechanisms and processes are active, maintained, and monitored.
- Service
Core
5.3.4.29Checks if Kubernetes clusters are logging audits to a specific location. The rule is NON_COMPLIANT if audit logging is not enabled for a Kubernetes cluster or if the 'logDestination' parameter is provided but the audit logging destination does not match.1
Attributes
- Section
5.3.4: Anti-malware mechanisms and processes are active, maintained, and monitored.
- Service
API Server
5.3.4.30Checks if Kubernetes clusters have the specified settings. The rule is NON_COMPLIANT if the Kubernetes cluster is not encrypted or encrypted with another key, or if the cluster does not have audit logging enabled.0
Attributes
- Section
5.3.4: Anti-malware mechanisms and processes are active, maintained, and monitored.
- Service
Core
5.3.4.31Checks if DNS query logging is enabled for your Kubernetes cluster's CoreDNS configuration. The rule is NON_COMPLIANT if DNS query logging is not enabled for CoreDNS.0
Attributes
- Section
5.3.4: Anti-malware mechanisms and processes are active, maintained, and monitored.
- Service
Core
5.3.4.32Checks if logging is enabled for your Kubernetes Pods. The rule is NON_COMPLIANT if logging is not enabled.0
Attributes
- Section
5.3.4: Anti-malware mechanisms and processes are active, maintained, and monitored.
- Service
Core
5.3.4.33Checks if a Kubernetes Pod has logging enabled. The rule is NON_COMPLIANT if a Pod does not have logging enabled or the logging configuration is not at the minimum level provided.0
Attributes
- Section
5.3.4: Anti-malware mechanisms and processes are active, maintained, and monitored.
- Service
Core
5.3.4.34Checks if Kubernetes Network Policies are implemented and enforce traffic control between pods. The rule is NON_COMPLIANT if Network Policies are not applied to at least one namespace.1
Attributes
- Section
5.3.4: Anti-malware mechanisms and processes are active, maintained, and monitored.
- Service
Core
5.3.4.35Checks if logging is enabled on Kubernetes Ingress Controllers. The rule is NON_COMPLIANT if the logging is enabled but the logging destination does not match the expected logging service configuration.0
Attributes
- Section
5.3.4: Anti-malware mechanisms and processes are active, maintained, and monitored.
- Service
Kubernetes Ingress Controller
5.3.4.36Checks if logging is enabled on Kubernetes Ingress resources. The rule is NON_COMPLIANT for an Ingress resource, if it does not have logging enabled.0
Attributes
- Section
5.3.4: Anti-malware mechanisms and processes are active, maintained, and monitored.
- Service
API Server
6.3.3: Security vulnerabilities are identified and addressed.101
6.3.3.1Validates the installation of specified applications on a Kubernetes pod, with optional minimum version requirements and platform constraints.0
Attributes
- Section
6.3.3: Security vulnerabilities are identified and addressed.
- Service
Core
6.3.3.2Checks if the compliance status of the Kubernetes cluster's node patch compliance is up-to-date or not after applying patches. The rule is compliant if the field status is 'COMPLIANT'.0
Attributes
- Section
6.3.3: Security vulnerabilities are identified and addressed.
- Service
Core
6.3.3.3Checks if Kubernetes Pods are using the latest container image version. The rule is NON_COMPLIANT if the image tag in the Pod specification is not set to 'latest', or if no specific image version is provided in the deployment manifest.0
Attributes
- Section
6.3.3: Security vulnerabilities are identified and addressed.
- Service
Core
6.3.3.4Checks if a Kubernetes cluster is running the oldest supported version. The rule is NON_COMPLIANT if the Kubernetes cluster is running the oldest supported version (equal to the parameter 'oldestVersionSupported').0
Attributes
- Section
6.3.3: Security vulnerabilities are identified and addressed.
- Service
Core
6.3.3.5Checks if a Kubernetes cluster is running a supported version. This rule is NON_COMPLIANT if the cluster is running an unsupported version (less than the parameter 'oldestVersionSupported').0
Attributes
- Section
6.3.3: Security vulnerabilities are identified and addressed.
- Service
Core
6.3.3.6Checks if Kubernetes Redis clusters have auto minor version upgrades enabled. The rule is NON_COMPLIANT for a Redis cluster if it is using the Redis engine and 'AutoMinorVersionUpgrade' is not set to 'true'.0
Attributes
- Section
6.3.3: Security vulnerabilities are identified and addressed.
- Service
Kubernetes Redis Cluster
6.3.3.7Checks if automatic updates for a Kubernetes cluster managed by Amazon EKS are enabled. The rule is COMPLIANT if the value for 'automatedUpdate' is set to true. The rule is NON_COMPLIANT if the value for 'automatedUpdate' is set to false, or if a parameter is provided and its value does not match the existing configurations.0
Attributes
- Section
6.3.3: Security vulnerabilities are identified and addressed.
- Service
Kubernetes (Amazon EKS)
6.3.3.8Checks if the Kubernetes Pod specifications for image, service account, restart policy, and resource limits match the expected values. The rule ignores Pods with the 'initContainers' field defined and Pods with a restart policy set to 'Never'. The rule is NON_COMPLIANT if the Pod specifications do not match the expected values.1
Attributes
- Section
6.3.3: Security vulnerabilities are identified and addressed.
- Service
RBAC
6.3.3.9Checks if Kubernetes cluster version updates are available but not installed. The rule is NON_COMPLIANT for a Kubernetes cluster if the latest software updates are not installed.0
Attributes
- Section
6.3.3: Security vulnerabilities are identified and addressed.
- Service
Core
6.3.3.11Checks if Kubernetes clusters have the specified maintenance settings. The rule is NON_COMPLIANT if automatic upgrades to new Kubernetes versions are disabled.0
Attributes
- Section
6.3.3: Security vulnerabilities are identified and addressed.
- Service
Core
6.4.1: Public-facing web applications are protected against attacks.140
6.4.1.1Checks if Kubernetes Ingress has security policies enforced. The rule is NON_COMPLIANT if key: ingress.policy.enabled is set to false.0
Attributes
- Section
6.4.1: Public-facing web applications are protected against attacks.
- Service
API Server
6.4.1.2Checks if a Kubernetes Ingress resource is using a specified NGINX Ingress Controller with appropriate annotations for web access control. The rule is NON_COMPLIANT if no NGINX Ingress Controller is specified or if the annotations do not match the predefined rules.0
Attributes
- Section
6.4.1: Public-facing web applications are protected against attacks.
- Service
API Server
6.4.1.3Checks if Kubernetes APIs are associated with Network Policies. The rule is NON_COMPLIANT for a Kubernetes API if it is not associated with a Network Policy.0
Attributes
- Section
6.4.1: Public-facing web applications are protected against attacks.
- Service
API Server
6.4.1.4Checks if Kubernetes Ingress resources are associated with Network Policies for traffic control. The rule is NON_COMPLIANT if an Ingress resource is not associated with a Network Policy.0
Attributes
- Section
6.4.1: Public-facing web applications are protected against attacks.
- Service
API Server
6.4.1.5Checks if the Network Policy is associated with an Ingress resource managing traffic to services or an Ingress Controller service. When a management tool creates this rule, the policy owner specifies the NetworkPolicy in the resource definition and can optionally enable remediation actions.0
Attributes
- Section
6.4.1: Public-facing web applications are protected against attacks.
- Service
API Server
6.4.1.6Verifies that the Network Policies are associated with the Ingress Controller in the correct order of priority. The priority is determined by the rank of the Network Policies in the policy parameter. When a Kubernetes Networking policy is created, its priority is assigned based on its order in the list, starting from the highest priority. The cluster administrator specifies the Network Policies rank and can optionally enable custom actions.0
Attributes
- Section
6.4.1: Public-facing web applications are protected against attacks.
- Service
Core
6.4.1.7Checks if Kubernetes Network Policies contain ingress or egress rules. The policy is NON_COMPLIANT if there are no rules defined in a Network Policy.0
Attributes
- Section
6.4.1: Public-facing web applications are protected against attacks.
- Service
API Server
6.4.1.8Checks if a Kubernetes Network Policy contains any ingress or egress rules. This rule is NON_COMPLIANT if a Network Policy does not contain any ingress or egress rules.0
Attributes
- Section
6.4.1: Public-facing web applications are protected against attacks.
- Service
Core
6.4.1.9Checks if a Kubernetes NetworkPolicy contains any ingress or egress rules. The policy is NON_COMPLIANT if there are no rules present within the NetworkPolicy.0
Attributes
- Section
6.4.1: Public-facing web applications are protected against attacks.
- Service
API Server
6.4.1.10Checks if a Kubernetes NetworkPolicy contains any ingress or egress rules. The policy is NON_COMPLIANT if no rules are defined within the NetworkPolicy.0
Attributes
- Section
6.4.1: Public-facing web applications are protected against attacks.
- Service
API Server
6.4.1.11Checks whether a Kubernetes NetworkPolicy contains any ingress or egress rules. This rule is NON_COMPLIANT if a NetworkPolicy does not contain any rules.0
Attributes
- Section
6.4.1: Public-facing web applications are protected against attacks.
- Service
API Server
6.4.1.12Checks if a Kubernetes NetworkPolicy contains any ingress or egress rules. The policy is NON_COMPLIANT if there are no rules present within the NetworkPolicy.0
Attributes
- Section
6.4.1: Public-facing web applications are protected against attacks.
- Service
API Server
6.4.1.13Checks whether a Kubernetes NetworkPolicy contains at least one ingress or egress rule. This policy is COMPLIANT if it contains at least one rule and NON_COMPLIANT otherwise.0
Attributes
- Section
6.4.1: Public-facing web applications are protected against attacks.
- Service
API Server
6.4.1.14Checks if a Kubernetes NetworkPolicy contains any ingress or egress rules. The policy is NON_COMPLIANT if there are no ingress or egress rules present within the NetworkPolicy.0
Attributes
- Section
6.4.1: Public-facing web applications are protected against attacks.
- Service
Core
6.4.2: Public-facing web applications are protected against attacks.140
6.4.2.1Checks if Kubernetes Network Policies are enabled on Ingress Controllers. The rule is NON_COMPLIANT if the key: networkPolicies.enabled is set to false.0
Attributes
- Section
6.4.2: Public-facing web applications are protected against attacks.
- Service
API Server
6.4.2.2Checks if a Kubernetes Ingress resource is using a valid NetworkPolicy or an Ingress controller with proper security configurations. The rule is NON_COMPLIANT if a NetworkPolicy is not used or if the used NetworkPolicy does not match what is recommended in the policy specifications.0
Attributes
- Section
6.4.2: Public-facing web applications are protected against attacks.
- Service
API Server
6.4.2.3Checks if Kubernetes APIs are associated with Network Policies. The rule is NON_COMPLIANT for a Kubernetes API if it is not associated with a Network Policy.0
Attributes
- Section
6.4.2: Public-facing web applications are protected against attacks.
- Service
API Server
6.4.2.4Checks if Kubernetes Ingress resources are associated with any Network Policies to ensure security. The rule is NON_COMPLIANT if an Ingress resource is not associated with any Network Policy.0
Attributes
- Section
6.4.2: Public-facing web applications are protected against attacks.
- Service
API Server
6.4.2.5Checks if the NetworkPolicy is associated with a Service or Ingress resource in Kubernetes. When a NetworkPolicy is created, the policy owner specifies the namespace and selectors that determine which pods are affected by the policy and can optionally enable actions for traffic management.0
Attributes
- Section
6.4.2: Public-facing web applications are protected against attacks.
- Service
API Server
6.4.2.6Verifies that the NetworkPolicy objects associated with a Kubernetes Ingress resource have the correct priority, based on the rank specified in the NetworkPolicy. The Kubernetes system assigns priorities in increasing order, starting from the highest priority (0) and continuing with 1, 2, and so on. The cluster administrator defines the rank in the NetworkPolicy and can optionally enable remediation actions.0
Attributes
- Section
6.4.2: Public-facing web applications are protected against attacks.
- Service
API Server
6.4.2.7Checks if Kubernetes Network Policies contain rules. The policy is NON_COMPLIANT if there are no rules in a Kubernetes Network Policy.0
Attributes
- Section
6.4.2: Public-facing web applications are protected against attacks.
- Service
Core
6.4.2.8Checks if a Kubernetes Network Policy contains any ingress or egress rules. This rule is NON_COMPLIANT if a Network Policy does not contain any ingress or egress rules.0
Attributes
- Section
6.4.2: Public-facing web applications are protected against attacks.
- Service
Core
6.4.2.9Checks if a Kubernetes NetworkPolicy contains any ingress or egress rules. The NetworkPolicy is NON_COMPLIANT if there are no rules present within the policy.0
Attributes
- Section
6.4.2: Public-facing web applications are protected against attacks.
- Service
API Server
6.4.2.10Checks if a Kubernetes NetworkPolicy contains any rules. The NetworkPolicy is NON_COMPLIANT if no rules are present within the NetworkPolicy.0
Attributes
- Section
6.4.2: Public-facing web applications are protected against attacks.
- Service
API Server
6.4.2.11Checks whether a Kubernetes NetworkPolicy contains any ingress or egress rules. This policy is NON_COMPLIANT if a NetworkPolicy does not contain any ingress or egress rules.0
Attributes
- Section
6.4.2: Public-facing web applications are protected against attacks.
- Service
API Server
6.4.2.12Checks if Kubernetes NetworkPolicies contain any rules. The policy is NON_COMPLIANT if there are no rules present within a Kubernetes NetworkPolicy.0
Attributes
- Section
6.4.2: Public-facing web applications are protected against attacks.
- Service
Core
6.4.2.13Checks whether a Kubernetes Network Policy contains at least one ingress or egress rule. This policy is COMPLIANT if it contains at least one rule and NON_COMPLIANT otherwise.0
Attributes
- Section
6.4.2: Public-facing web applications are protected against attacks.
- Service
Core
6.4.2.14Checks if a Kubernetes Network Policy contains any rules. The policy is NON_COMPLIANT if there are no rules defined within the Network Policy.0
Attributes
- Section
6.4.2: Public-facing web applications are protected against attacks.
- Service
Core
6.5.5: Changes to all system components are managed securely.20
6.5.5.1Checks if the Kubernetes Deployment for a specific application is not using the default update strategy. The rule is NON_COMPLIANT if the Deployment is using the rolling update strategy with maxUnavailable set to 0.0
Attributes
- Section
6.5.5: Changes to all system components are managed securely.
- Service
Core
6.5.5.2Checks if the first deployment stage of Kubernetes performs more than one deployment. Optionally checks if each of the subsequent remaining stages deploy to more than the specified number of deployments (deploymentLimit).0
Attributes
- Section
6.5.5: Changes to all system components are managed securely.
- Service
Core
6.5.6: Changes to all system components are managed securely.20
6.5.6.1Checks if the Kubernetes Deployment is not using the default rollout strategy. The rule is NON_COMPLIANT if the deployment strategy is set to 'Recreate'.0
Attributes
- Section
6.5.6: Changes to all system components are managed securely.
- Service
Core
6.5.6.2Checks if the first deployment stage in a Kubernetes pipeline (using tools like Argo CD or Tekton) performs more than one deployment. Optionally checks if each of the subsequent stages deploy to more than the specified number of deployments (deploymentLimit).0
Attributes
- Section
6.5.6: Changes to all system components are managed securely.
- Service
Kubernetes CI/CD Pipeline
7.2.1: Access to system components and data is appropriately defined and assigned.2921
7.2.1.1Checks if a Kubernetes cluster node is part of a specific Kubernetes Namespace. The rule is NON_COMPLIANT if the node is not part of the specified Namespace or if the Namespace does not match rule parameter NamespaceName.0
Attributes
- Section
7.2.1: Access to system components and data is appropriately defined and assigned.
- Service
Core
7.2.1.2Checks if a Kubernetes namespace has an attached Role or ClusterRole that prevents deletion of Pods. The rule is NON_COMPLIANT if the namespace does not have a Role/ClusterRole or has Roles/ClusterRoles without a suitable 'Deny' statement (like 'delete' permission for 'pods').0
Attributes
- Section
7.2.1: Access to system components and data is appropriately defined and assigned.
- Service
Core
7.2.1.3Checks if a Kubernetes Pod security context has privileged mode enabled. The rule is NON_COMPLIANT for a Pod if 'privileged' is set to 'true'.1
Attributes
- Section
7.2.1: Access to system components and data is appropriately defined and assigned.
- Service
Core
7.2.1.4Checks if custom Kubernetes CustomResourceDefinitions (CRDs) have a role-based access control (RBAC) policy attached. The rule is NON_COMPLIANT for custom CRDs without an RBAC policy attached.1
Attributes
- Section
7.2.1: Access to system components and data is appropriately defined and assigned.
- Service
RBAC
7.2.1.5Checks if a Kubernetes pod has a Service Account attached to it. The rule is NON_COMPLIANT if no Service Account is attached to the pod.1
Attributes
- Section
7.2.1: Access to system components and data is appropriately defined and assigned.
- Service
API Server
7.2.1.6Checks if the securityContext.privileged field in the Pod specification is set to 'true'. The rule is NON_COMPLIANT if the privileged field is 'true'.1
Attributes
- Section
7.2.1: Access to system components and data is appropriately defined and assigned.
- Service
Core
7.2.1.7Checks if Kubernetes Pods only have read-only access to their root filesystems. The rule is NON_COMPLIANT if the readOnlyRootFilesystem field in the Pod's securityContext is set to 'false'.1
Attributes
- Section
7.2.1: Access to system components and data is appropriately defined and assigned.
- Service
Core
7.2.1.8Checks if Kubernetes Pod specifications specify a user to run containers. The rule is NON_COMPLIANT if the 'securityContext.runAsUser' parameter is not present or set to '0'.1
Attributes
- Section
7.2.1: Access to system components and data is appropriately defined and assigned.
- Service
API Server
7.2.1.9Verifies that the Kubernetes Role and ClusterRole policies do not authorize actions that are restricted on Kubernetes Secrets. The rule is NON_COMPLIANT if any restricted action is permitted on Kubernetes Secrets by the defined Role or ClusterRole.1
Attributes
- Section
7.2.1: Access to system components and data is appropriately defined and assigned.
- Service
RBAC
7.2.1.10Checks if the Role-based Access Control (RBAC) policies attached to your Kubernetes users, roles, and groups do not allow blocked actions on all Kubernetes resources. The rule is NON_COMPLIANT if any blocked action is permitted on all Kubernetes resources in the RBAC policy.1
Attributes
- Section
7.2.1: Access to system components and data is appropriately defined and assigned.
- Service
API Server
7.2.1.11Checks if the Kubernetes Role or ClusterRole resources do not have any permissions granted through inline policies. The rule is NON_COMPLIANT if a Kubernetes user, service account, or group has any permissions granted through inline Roles or ClusterRoles.0
Attributes
- Section
7.2.1: Access to system components and data is appropriately defined and assigned.
- Service
Core
7.2.1.12Checks in each Kubernetes Role or ClusterRole resource if a RoleBinding or ClusterRoleBinding is associated with the specified Role or ClusterRole. The rule is NON_COMPLIANT if the RoleBinding or ClusterRoleBinding references the Role or ClusterRole.1
Attributes
- Section
7.2.1: Access to system components and data is appropriately defined and assigned.
- Service
RBAC
7.2.1.13Checks whether a Kubernetes Role or ClusterRole is bound to a ServiceAccount, or a RoleBinding or ClusterRoleBinding is associated with a User or Group that has one or more members.0
Attributes
- Section
7.2.1: Access to system components and data is appropriately defined and assigned.
- Service
Core
7.2.1.14Checks if Kubernetes Role or ClusterRole resources grant permissions that allow all actions on all resources. The rule is NON_COMPLIANT if any Role or ClusterRole definition includes rules with 'verbs' that list '*' for all actions over 'resourceNames' that include '*'.1
Attributes
- Section
7.2.1: Access to system components and data is appropriately defined and assigned.
- Service
RBAC
7.2.1.15Checks if Kubernetes Role-based Access Control (RBAC) rules that you create grant permissions to all actions on individual Kubernetes resources. The rule is NON_COMPLIANT if any custom Role or ClusterRole allows full access to at least 1 Kubernetes resource or namespace.1
Attributes
- Section
7.2.1: Access to system components and data is appropriately defined and assigned.
- Service
RBAC
7.2.1.16Checks if all required Kubernetes Roles or ClusterRoles specified in the list are attached to the ServiceAccount. The rule is NON_COMPLIANT if any required Role or ClusterRole is not attached to the ServiceAccount.1
Attributes
- Section
7.2.1: Access to system components and data is appropriately defined and assigned.
- Service
API Server
7.2.1.17Checks if the Kubernetes root user (or equivalent admin user) has any access keys available. The result is COMPLIANT if no access keys are found. Otherwise, it is NON_COMPLIANT.0
Attributes
- Section
7.2.1: Access to system components and data is appropriately defined and assigned.
- Service
Core
7.2.1.18Verifies if Kubernetes users (or ServiceAccounts) are associated with at least one RoleBinding or ClusterRoleBinding that grants them access to resources in a Kubernetes cluster.0
Attributes
- Section
7.2.1: Access to system components and data is appropriately defined and assigned.
- Service
Kubernetes IAM (Role-Based Access Control)
7.2.1.19Checks if none of your Kubernetes ServiceAccounts have RoleBindings or ClusterRoleBindings directly attached. ServiceAccounts must inherit permissions from Roles or ClusterRoles. The rule is NON_COMPLIANT if there is at least one RoleBinding or ClusterRoleBinding directly attached to the ServiceAccount.1
Attributes
- Section
7.2.1: Access to system components and data is appropriately defined and assigned.
- Service
API Server
7.2.1.20Checks if a Kubernetes cluster has Role-Based Access Control (RBAC) enabled. The rule is NON_COMPLIANT if a Kubernetes cluster does not have RBAC enabled.1
Attributes
- Section
7.2.1: Access to system components and data is appropriately defined and assigned.
- Service
API Server
7.2.1.21Checks if Kubernetes namespaces have Role-Based Access Control (RBAC) policies enabled. The rule is NON_COMPLIANT if RoleBindings are not present for the specified Kubernetes namespace.1
Attributes
- Section
7.2.1: Access to system components and data is appropriately defined and assigned.
- Service
API Server
7.2.1.22Checks if a Kubernetes cluster has Role-Based Access Control (RBAC) enabled. The rule is NON_COMPLIANT if a Kubernetes cluster does not have RBAC enabled.1
Attributes
- Section
7.2.1: Access to system components and data is appropriately defined and assigned.
- Service
API Server
7.2.1.23Checks if a Kubernetes database instance, such as a PostgreSQL or MySQL deployment, has Role-Based Access Control (RBAC) authentication enabled. The rule is NON_COMPLIANT if the database instance does not have RBAC authentication enabled.1
Attributes
- Section
7.2.1: Access to system components and data is appropriately defined and assigned.
- Service
API Server
7.2.1.24Checks if Kubernetes Persistent Volumes (PVs) allow user permissions through access control lists (ACLs). The rule is NON_COMPLIANT if ACLs are configured for user access in Kubernetes Persistent Volumes.1
Attributes
- Section
7.2.1: Access to system components and data is appropriately defined and assigned.
- Service
RBAC
7.2.1.25Checks if a Kubernetes Role or ClusterRole does not allow blocklisted permissions on resources in a namespace for principals from other Kubernetes namespaces. For example, the rule checks that the Role or ClusterRole does not allow any permissions related to 'pod'. The rule is NON_COMPLIANT if any blocklisted actions are allowed by the Role or ClusterRole.1
Attributes
- Section
7.2.1: Access to system components and data is appropriately defined and assigned.
- Service
RBAC
7.2.1.26Checks that the access granted by the Kubernetes pod is restricted by any of the Kubernetes principals, service accounts, network policies, or namespaces that you provide. The rule is COMPLIANT if a network policy is not present.0
Attributes
- Section
7.2.1: Access to system components and data is appropriately defined and assigned.
- Service
Core
7.2.1.27Verifies that Kubernetes PersistentVolumeClaim permissions do not allow inter-namespace access beyond the specified controls in the PersistentVolume definition.1
Attributes
- Section
7.2.1: Access to system components and data is appropriately defined and assigned.
- Service
RBAC
7.2.1.28Checks if the Pod Security Policy in a Kubernetes cluster allows privileged operations. The rule is NON_COMPLIANT if privileged operations are permitted for any pod.1
Attributes
- Section
7.2.1: Access to system components and data is appropriately defined and assigned.
- Service
Core
7.2.1.29Checks if the Security Incident Response (SIR) team can access your Kubernetes cluster. The rule is NON_COMPLIANT if Kubernetes security measures are enabled but the role for SIR access is not configured.0
Attributes
- Section
7.2.1: Access to system components and data is appropriately defined and assigned.
- Service
Core
7.2.2: Access to system components and data is appropriately defined and assigned.2922
7.2.2.1Checks if a Kubernetes cluster is part of a specific organization (e.g., using labels or annotations). The rule is NON_COMPLIANT if a Kubernetes cluster does not have the required organization label or if the organization label value does not match the expected organization ID.0
Attributes
- Section
7.2.2: Access to system components and data is appropriately defined and assigned.
- Service
Core
7.2.2.2Checks if a Kubernetes PersistentVolumeClaim (PVC) has an associated ResourceQuota that prevents deletion or modification of related PersistentVolumes (PVs). The rule is NON_COMPLIANT if the PVC does not have an associated ResourceQuota or has quotas without proper limits on 'delete' and 'update' operations related to the storage resources.1
Attributes
- Section
7.2.2: Access to system components and data is appropriately defined and assigned.
- Service
RBAC
7.2.2.3Checks if a Kubernetes Pod has privileged security context enabled. The rule is NON_COMPLIANT for a Pod if 'privileged' is set to 'true'.1
Attributes
- Section
7.2.2: Access to system components and data is appropriately defined and assigned.
- Service
Core
7.2.2.4Checks if custom Kubernetes CustomResourceDefinitions (CRDs) have an associated RBAC policy. The rule is NON_COMPLIANT for CRDs without an associated RBAC policy attached.1
Attributes
- Section
7.2.2: Access to system components and data is appropriately defined and assigned.
- Service
RBAC
7.2.2.5Checks if a Kubernetes Pod has a ServiceAccount associated with it. The rule is NON_COMPLIANT if no ServiceAccount is attached to the Pod.1
Attributes
- Section
7.2.2: Access to system components and data is appropriately defined and assigned.
- Service
API Server
7.2.2.6Checks if the securityContext in Pod definitions has privileged set to 'true'. The rule is NON_COMPLIANT if privileged is 'true'.1
Attributes
- Section
7.2.2: Access to system components and data is appropriately defined and assigned.
- Service
Core
7.2.2.7Checks if Kubernetes Pods only have read-only access to their root filesystems. The rule is NON_COMPLIANT if the readOnlyRootFilesystem field in the securityContext of the Pod specification is set to 'false'.1
Attributes
- Section
7.2.2: Access to system components and data is appropriately defined and assigned.
- Service
Core
7.2.2.8Checks if Kubernetes Pods specify a user for containers to run with. The rule is NON_COMPLIANT if the 'runAsUser' field is not present or set to '0' (root).0
Attributes
- Section
7.2.2: Access to system components and data is appropriately defined and assigned.
- Service
Core
7.2.2.9Checks if the Kubernetes Role or ClusterRole permissions do not allow actions that are denied by network policies. The rule is NON_COMPLIANT if any blocked action is allowed by the Kubernetes Role or ClusterRole.0
Attributes
- Section
7.2.2: Access to system components and data is appropriately defined and assigned.
- Service
RBAC (Role-Based Access Control)
7.2.2.10Checks if the RoleBindings and ClusterRoleBindings in Kubernetes do not allow unauthorized actions on all Secrets. The rule is NON_COMPLIANT if any unauthorized action is allowed on all Secrets by any RoleBinding or ClusterRoleBinding.1
Attributes
- Section
7.2.2: Access to system components and data is appropriately defined and assigned.
- Service
RBAC
7.2.2.11Checks if the RBAC (Role-Based Access Control) feature is properly configured. The rule is NON_COMPLIANT if a Kubernetes ServiceAccount has any RoleBindings that associate it with inline roles, as the best practice is to use ClusterRoles or pre-defined roles instead.1
Attributes
- Section
7.2.2: Access to system components and data is appropriately defined and assigned.
- Service
API Server
7.2.2.12Checks in each Kubernetes Role or ClusterRole resource, if a RoleBinding or ClusterRoleBinding containing a specific Role or ClusterRole is attached to the resource. The rule is NON_COMPLIANT if the RoleBinding or ClusterRoleBinding is attached to the resource.1
Attributes
- Section
7.2.2: Access to system components and data is appropriately defined and assigned.
- Service
RBAC
7.2.2.13Checks whether the Role or ClusterRole binding is attached to a ServiceAccount, a User group with one or more ServiceAccounts, or a Role with one or more trusted subjects.0
Attributes
- Section
7.2.2: Access to system components and data is appropriately defined and assigned.
- Service
RBAC (Role-Based Access Control)
7.2.2.14Checks if Kubernetes Role or ClusterRole policies that you create have rules that grant permissions to all verbs on all resources. The rule is NON_COMPLIANT if any custom Role or ClusterRole definition includes 'verbs': ['*'] over 'resources': ['*'].1
Attributes
- Section
7.2.2: Access to system components and data is appropriately defined and assigned.
- Service
RBAC
7.2.2.15Checks if Kubernetes Role-Based Access Control (RBAC) policies that you create grant permissions to all actions on individual Kubernetes resources. The rule is NON_COMPLIANT if any custom Role or ClusterRole allows full access to at least 1 Kubernetes resource or group of resources.1
Attributes
- Section
7.2.2: Access to system components and data is appropriately defined and assigned.
- Service
RBAC
7.2.2.16Checks if all specified Kubernetes RoleBindings are applied to the given Service Account. The rule is NON_COMPLIANT if a RoleBinding is missing for the Service Account.1
Attributes
- Section
7.2.2: Access to system components and data is appropriately defined and assigned.
- Service
API Server
7.2.2.17Checks if the Kubernetes root user (superuser) access is enabled. The rule is COMPLIANT if the root user has no access permissions (no tokens or credentials exist for the root user). Otherwise, NON_COMPLIANT.1
Attributes
- Section
7.2.2: Access to system components and data is appropriately defined and assigned.
- Service
Core
7.2.2.18Checks whether Kubernetes users are members of at least one RoleBinding or ClusterRoleBinding.0
Attributes
- Section
7.2.2: Access to system components and data is appropriately defined and assigned.
- Service
Core
7.2.2.19Checks if none of your Kubernetes users or service accounts have direct role bindings. Users and service accounts should inherit permissions from roles or cluster roles through role bindings. The rule is NON_COMPLIANT if there is at least one role binding directly attached to the user or service account.1
Attributes
- Section
7.2.2: Access to system components and data is appropriately defined and assigned.
- Service
RBAC
7.2.2.20Checks if a Kubernetes cluster has Role-Based Access Control (RBAC) enabled. The rule is NON_COMPLIANT if the Kubernetes cluster does not have RBAC enabled.1
Attributes
- Section
7.2.2: Access to system components and data is appropriately defined and assigned.
- Service
API Server
7.2.2.21Checks if Kubernetes clusters have Role-Based Access Control (RBAC) enabled. The rule is NON_COMPLIANT if RBAC is not configured for the Kubernetes cluster.1
Attributes
- Section
7.2.2: Access to system components and data is appropriately defined and assigned.
- Service
API Server
7.2.2.22Checks if a Kubernetes cluster's database (e.g., PostgreSQL, MySQL) has Role-based Access Control (RBAC) enabled for authentication. The rule is NON_COMPLIANT if the database does not have RBAC authentication enabled.1
Attributes
- Section
7.2.2: Access to system components and data is appropriately defined and assigned.
- Service
API Server
7.2.2.23Checks if a Kubernetes cluster has Role-Based Access Control (RBAC) enabled. The rule is NON_COMPLIANT if a Kubernetes cluster does not have RBAC enabled.1
Attributes
- Section
7.2.2: Access to system components and data is appropriately defined and assigned.
- Service
API Server
7.2.2.24Checks if Kubernetes Persistent Volumes allow user permissions through access control lists (ACLs). The rule is NON_COMPLIANT if ACLs are configured for user access in Kubernetes Persistent Volumes.1
Attributes
- Section
7.2.2: Access to system components and data is appropriately defined and assigned.
- Service
RBAC
7.2.2.25Checks if a Kubernetes Role or ClusterRole does not allow blocklisted permissions on resources for users from other namespaces or clusters. For example, the rule checks that the Role or ClusterRole does not allow any 'get', 'delete' actions on Pod resources. The rule is NON_COMPLIANT if any blocklisted actions are allowed by the Role or ClusterRole.0
Attributes
- Section
7.2.2: Access to system components and data is appropriately defined and assigned.
- Service
Core
7.2.2.26Checks that the access granted by the Kubernetes service is restricted to specified namespaces, service accounts, or network policies that you provide. The rule is COMPLIANT if a NetworkPolicy is not present.1
Attributes
- Section
7.2.2: Access to system components and data is appropriately defined and assigned.
- Service
Core
7.2.2.27Checks if your Kubernetes PersistentVolumeClaims (PVC) permissions do not allow other inter-namespace access except for the control namespace policy that you provide.1
Attributes
- Section
7.2.2: Access to system components and data is appropriately defined and assigned.
- Service
RBAC
7.2.2.28Checks if the Kubernetes Pod Security Policy (PSP) allows privileged access for Pods. The rule is NON_COMPLIANT if a Pod is allowed to run with elevated privileges.1
Attributes
- Section
7.2.2: Access to system components and data is appropriately defined and assigned.
- Service
Core
7.2.2.29Checks if the Kubernetes Security Response Team (KSRT) can access your Kubernetes cluster. The rule is NON_COMPLIANT if the Role-Based Access Control (RBAC) is enabled but the role for KSRT access is not configured.0
Attributes
- Section
7.2.2: Access to system components and data is appropriately defined and assigned.
- Service
Core
7.2.3: Access to system components and data is appropriately defined and assigned.97
7.2.3.1Checks if a Kubernetes Pod has privileged mode enabled. The rule is NON_COMPLIANT for a Pod if 'privileged' is set to 'true' in the security context.1
Attributes
- Section
7.2.3: Access to system components and data is appropriately defined and assigned.
- Service
Core
7.2.3.2Checks if custom Kubernetes Custom Resource Definitions (CRDs) have an admission policy attached. The rule is NON_COMPLIANT for CRDs without an admission policy attached.0
Attributes
- Section
7.2.3: Access to system components and data is appropriately defined and assigned.
- Service
Core
7.2.3.3Checks if the security context in the pod definition of a Kubernetes Deployment has 'privileged' set to 'true'. The rule is NON_COMPLIANT if 'privileged' is 'true'.1
Attributes
- Section
7.2.3: Access to system components and data is appropriately defined and assigned.
- Service
Core
7.2.3.4Checks if Kubernetes Pods specify a user for containers to run as. The rule is NON_COMPLIANT if the 'securityContext.runAsUser' parameter is not present or set to '0'.1
Attributes
- Section
7.2.3: Access to system components and data is appropriately defined and assigned.
- Service
API Server
7.2.3.5Checks if the Kubernetes Role or ClusterRole policies that you create do not allow ineligible actions on Kubernetes Secrets. The rule is NON_COMPLIANT if any ineligible action is allowed on Kubernetes Secrets by the managed Role or ClusterRole.1
Attributes
- Section
7.2.3: Access to system components and data is appropriately defined and assigned.
- Service
RBAC
7.2.3.6Checks if the Role-based Access Control (RBAC) policies attached to your Kubernetes users, roles, and role bindings do not allow blocked actions on all specified Kubernetes resources. The rule is NON_COMPLIANT if any blocked action is allowed on any Kubernetes resource in a role binding.1
Attributes
- Section
7.2.3: Access to system components and data is appropriately defined and assigned.
- Service
API Server
7.2.3.7Checks if Kubernetes Role or ClusterRole policies allow unrestricted access by having rules that permit all verbs on all resources. The rule is NON_COMPLIANT if any user-defined Role or ClusterRole includes rules with 'verbs': ['*'] over all 'resources': ['*'].1
Attributes
- Section
7.2.3: Access to system components and data is appropriately defined and assigned.
- Service
RBAC
7.2.3.8Checks if a ServiceAccount with root privileges exists. The rule is COMPLIANT if no ServiceAccount with cluster-admin role exists. Otherwise, NON_COMPLIANT.0
Attributes
- Section
7.2.3: Access to system components and data is appropriately defined and assigned.
- Service
Kubernetes ServiceAccount
7.2.3.9Checks if the Kubernetes Pod Security Policy allows privileged access for containers. The rule is NON_COMPLIANT if a Pod is running with elevated privileges.1
Attributes
- Section
7.2.3: Access to system components and data is appropriately defined and assigned.
- Service
Core
7.2.4: Access to system components and data is appropriately defined and assigned.30
7.2.4.1Checks whether Kubernetes Roles or RoleBindings have at least one associated ServiceAccount.0
Attributes
- Section
7.2.4: Access to system components and data is appropriately defined and assigned.
- Service
RBAC (Role-Based Access Control)
7.2.4.2Checks if your Kubernetes Service Accounts have tokens that have not been used within the specified number of days you provided. The rule is NON_COMPLIANT if there are inactive accounts that have not recently used their tokens.0
Attributes
- Section
7.2.4: Access to system components and data is appropriately defined and assigned.
- Service
Core
7.2.4.3Checks if Kubernetes Secrets have been accessed within a specified number of days. The rule is NON_COMPLIANT if a secret has not been accessed in 'unusedForDays' number of days. The default value is 90 days.0
Attributes
- Section
7.2.4: Access to system components and data is appropriately defined and assigned.
- Service
RBAC (Role-Based Access Control)
7.2.5: Access to system components and data is appropriately defined and assigned.2218
7.2.5.1Checks if a Kubernetes cluster is part of a specific organization. The rule is NON_COMPLIANT if a Kubernetes cluster is not part of the desired organization or the specified organization ID does not match the rule parameter OrganizationId.0
Attributes
- Section
7.2.5: Access to system components and data is appropriately defined and assigned.
- Service
Core
7.2.5.2Checks if a Kubernetes namespace has an associated network policy that restricts ingress and egress traffic, preventing unauthorized access. The rule is NON_COMPLIANT if the namespace does not have network policies or has policies without appropriate rules that deny specific traffic (e.g., HTTP, HTTPS) to sensitive services.1
Attributes
- Section
7.2.5: Access to system components and data is appropriately defined and assigned.
- Service
Core
7.2.5.3Checks if a Kubernetes pod has a ServiceAccount associated with it. The rule is NON_COMPLIANT if no ServiceAccount is attached to the pod.1
Attributes
- Section
7.2.5: Access to system components and data is appropriately defined and assigned.
- Service
API Server
7.2.5.4Checks if Kubernetes Pods only have read-only access to their root filesystems. The rule is NON_COMPLIANT if the readOnlyRootFilesystem field in the Pod Security Context is set to 'false'.1
Attributes
- Section
7.2.5: Access to system components and data is appropriately defined and assigned.
- Service
Core
7.2.5.5Checks if the Kubernetes Role-based Access Control (RBAC) policies that you create do not allow access to Kubernetes Secrets that are restricted. The rule is NON_COMPLIANT if any restricted access is allowed to Kubernetes Secrets by the RBAC policy.1
Attributes
- Section
7.2.5: Access to system components and data is appropriately defined and assigned.
- Service
RBAC
7.2.5.6Checks if the Role-Based Access Control (RBAC) policies attached to your Kubernetes service accounts and roles do not allow prohibited actions on all Kubernetes resources. The rule is NON_COMPLIANT if any prohibited action is allowed on all Kubernetes resources in an RBAC policy.1
Attributes
- Section
7.2.5: Access to system components and data is appropriately defined and assigned.
- Service
API Server
7.2.5.7Ensure that no Kubernetes ServiceAccounts have any associated inline policies, as inline policies can introduce security vulnerabilities. This rule is NON_COMPLIANT if a ServiceAccount has any role bindings that grant specific permissions directly to that account.1
Attributes
- Section
7.2.5: Access to system components and data is appropriately defined and assigned.
- Service
CONTROLLERMANAGER
7.2.5.8Checks in each Kubernetes Role or ClusterRole resource, if a RoleBinding or ClusterRoleBinding with the specified Role or ClusterRole is associated with the resource. The rule is NON_COMPLIANT if the RoleBinding or ClusterRoleBinding is linked to the Role or ClusterRole.1
Attributes
- Section
7.2.5: Access to system components and data is appropriately defined and assigned.
- Service
RBAC
7.2.5.9Checks if a RoleBinding or ClusterRoleBinding is associated with a ServiceAccount, a User, or a Group, granting specific permissions within a Kubernetes namespace or cluster.0
Attributes
- Section
7.2.5: Access to system components and data is appropriately defined and assigned.
- Service
Kubernetes RBAC (Role-Based Access Control)
7.2.5.10Checks if Kubernetes Role or ClusterRole configurations that you create have rules that grant permissions to all verbs on all resources. The rule is NON_COMPLIANT if any custom Role or ClusterRole includes rules with 'verbs': ['*'] over 'resources': ['*'].1
Attributes
- Section
7.2.5: Access to system components and data is appropriately defined and assigned.
- Service
RBAC
7.2.5.11Checks if Kubernetes Role-Based Access Control (RBAC) policies that you create grant permissions to all actions on individual Kubernetes resources. The rule is NON_COMPLIANT if any custom RBAC Role or ClusterRole allows full access to at least 1 Kubernetes resource.1
Attributes
- Section
7.2.5: Access to system components and data is appropriately defined and assigned.
- Service
RBAC
7.2.5.12Checks if all specified Kubernetes RoleBindings are correctly linked to the associated Kubernetes Role. The rule is NON_COMPLIANT if a RoleBinding does not reference the correct Role.1
Attributes
- Section
7.2.5: Access to system components and data is appropriately defined and assigned.
- Service
RBAC
7.2.5.13Checks if none of your Kubernetes Service Accounts have direct RoleBindings or ClusterRoleBindings attached. Service Accounts must inherit permissions from Roles or ClusterRoles, and the rule is NON_COMPLIANT if there is at least one RoleBinding or ClusterRoleBinding attached to the Service Account.1
Attributes
- Section
7.2.5: Access to system components and data is appropriately defined and assigned.
- Service
API Server
7.2.5.14Checks if a Kubernetes Pod has Role-Based Access Control (RBAC) enabled. The rule is NON_COMPLIANT if a Kubernetes Pod does not have RBAC enabled.1
Attributes
- Section
7.2.5: Access to system components and data is appropriately defined and assigned.
- Service
RBAC
7.2.5.15Checks if Kubernetes clusters have Role-Based Access Control (RBAC) enabled. The rule is NON_COMPLIANT if RBAC is not enabled for the Kubernetes cluster.1
Attributes
- Section
7.2.5: Access to system components and data is appropriately defined and assigned.
- Service
API Server
7.2.5.16Checks if a Kubernetes database deployment (like PostgreSQL or MySQL) has Role-Based Access Control (RBAC) authentication enabled. The rule is NON_COMPLIANT if the database deployment does not have RBAC authentication enabled.1
Attributes
- Section
7.2.5: Access to system components and data is appropriately defined and assigned.
- Service
API Server
7.2.5.17Checks if a Kubernetes Cluster has Role-based Access Control (RBAC) enabled. The rule is NON_COMPLIANT if the Kubernetes Cluster does not have RBAC enabled.1
Attributes
- Section
7.2.5: Access to system components and data is appropriately defined and assigned.
- Service
API Server
7.2.5.18Checks if Kubernetes Persistent Volume Claims (PVCs) allow user permissions through access control lists (RBAC). The rule is NON_COMPLIANT if RBAC is configured to allow unauthorized user access to Persistent Volume Claims.1
Attributes
- Section
7.2.5: Access to system components and data is appropriately defined and assigned.
- Service
RBAC
7.2.5.19Checks if a Kubernetes Role or ClusterRole does not allow blocklisted permissions related to resource actions on namespaces for subjects from other namespaces. For example, the rule checks that the Role or ClusterRole does not allow subjects from other namespaces to perform any actions like get, list, or delete on specific resources. The rule is NON_COMPLIANT if any blocklisted actions are allowed by the Role or ClusterRole.0
Attributes
- Section
7.2.5: Access to system components and data is appropriately defined and assigned.
- Service
Core
7.2.5.20Checks that the access granted by the Kubernetes ClusterRoleBinding is restricted by any of the Kubernetes principals, service accounts, namespaces, or IPs that you provide. The rule is COMPLIANT if a ClusterRoleBinding policy is not present.1
Attributes
- Section
7.2.5: Access to system components and data is appropriately defined and assigned.
- Service
RBAC
7.2.5.21Verifies that the Kubernetes Secrets do not allow unauthorized access to other namespaces and ensure that the permissions are controlled by the specified Role-Based Access Control (RBAC) policies.1
Attributes
- Section
7.2.5: Access to system components and data is appropriately defined and assigned.
- Service
RBAC
7.2.5.22Checks if the Incident Response Team can access your Kubernetes cluster. The rule is NON_COMPLIANT if the required role for the Incident Response Team is not configured, even though security features are enabled.0
Attributes
- Section
7.2.5: Access to system components and data is appropriately defined and assigned.
- Service
Core
7.2.5.1: Access to system components and data is appropriately defined and assigned.30
7.2.5.1.1Checks whether IAM groups have at least one Kubernetes user (Service Account).0
Attributes
- Section
7.2.5.1: Access to system components and data is appropriately defined and assigned.
- Service
Core
7.2.5.1.2Checks if your Kubernetes users (ServiceAccounts) have tokens that have not been used within the specified number of days you provided. The rule is NON_COMPLIANT if there are ServiceAccounts that have inactive tokens not recently used.0
Attributes
- Section
7.2.5.1: Access to system components and data is appropriately defined and assigned.
- Service
Core
7.2.5.1.3Checks if Kubernetes Secrets have been accessed within a specified number of days. The rule is NON_COMPLIANT if a Secret has not been accessed in 'unusedForDays' number of days. The default value is 90 days.0
Attributes
- Section
7.2.5.1: Access to system components and data is appropriately defined and assigned.
- Service
Core
7.2.6: Access to system components and data is appropriately defined and assigned.54
7.2.6.1Checks if Kubernetes Pods only have read-only access to their root filesystems. The rule is NON_COMPLIANT if the readOnlyRootFilesystem parameter in the pod's securityContext is set to 'false'.1
Attributes
- Section
7.2.6: Access to system components and data is appropriately defined and assigned.
- Service
Core
7.2.6.2Verifies if Kubernetes users are part of at least one RoleBinding or ClusterRoleBinding.0
Attributes
- Section
7.2.6: Access to system components and data is appropriately defined and assigned.
- Service
Core
7.2.6.3Checks if Kubernetes ClusterRoleBinding has appropriate permissions for access control. The rule is NON_COMPLIANT if ClusterRoleBinding does not restrict access to sensitive resources.1
Attributes
- Section
7.2.6: Access to system components and data is appropriately defined and assigned.
- Service
RBAC
7.2.6.4Checks if a Kubernetes Role or ClusterRole does not allow blocklisted permissions for principals from other namespaces or clusters, such as certain actions on Pods, Services, or ConfigMaps. For example, the rule checks that the Role or ClusterRole does not allow any 'get', 'delete' actions on Pods by users from different namespaces. The rule is NON_COMPLIANT if any blocklisted actions are allowed by the Role or ClusterRole.1
Attributes
- Section
7.2.6: Access to system components and data is appropriately defined and assigned.
- Service
RBAC
7.2.6.5Checks if your Kubernetes Persistent Volume claims do not allow access from other namespaces besides the control namespace that you provide.1
Attributes
- Section
7.2.6: Access to system components and data is appropriately defined and assigned.
- Service
RBAC
7.3.1: Access to system components and data is managed via an access control system(s).2218
7.3.1.1Checks if a Kubernetes cluster is part of a defined namespace. The rule is NON_COMPLIANT if a Kubernetes pod is not part of the specified namespace or if the namespace does not match the rule parameter Namespace.0
Attributes
- Section
7.3.1: Access to system components and data is managed via an access control system(s).
- Service
Core
7.3.1.2Checks if a Kubernetes PersistentVolume has an attached role-based access control (RBAC) policy that prevents deletion of PersistentVolumeClaims. The rule is NON_COMPLIANT if the PersistentVolume does not have specific RBAC policies or has policies that do not include a suitable 'Deny' rule (with permissions such as delete on PersistentVolumeClaim).1
Attributes
- Section
7.3.1: Access to system components and data is managed via an access control system(s).
- Service
RBAC
7.3.1.3Checks if a Kubernetes Pod has a Service Account attached to it. The rule is NON_COMPLIANT if no Service Account is associated with the Pod.1
Attributes
- Section
7.3.1: Access to system components and data is managed via an access control system(s).
- Service
API Server
7.3.1.4Checks if Kubernetes containers only have read-only access to their root filesystems. The rule is NON_COMPLIANT if the readOnlyRootFilesystem parameter in the pod specification is set to 'false'.1
Attributes
- Section
7.3.1: Access to system components and data is managed via an access control system(s).
- Service
Core
7.3.1.5Checks if the Kubernetes Role-Based Access Control (RBAC) policies that you create do not allow blocked actions on Kubernetes Secrets. The rule is NON_COMPLIANT if any blocked action is allowed on Kubernetes Secrets by the managed RBAC policy.1
Attributes
- Section
7.3.1: Access to system components and data is managed via an access control system(s).
- Service
RBAC
7.3.1.6Checks if the RBAC roles or ClusterRoles attached to your Kubernetes users do not allow unauthorized actions on all Kubernetes resources. The rule is NON_COMPLIANT if any unauthorized action is allowed on all Kubernetes resources in a Role or ClusterRole.1
Attributes
- Section
7.3.1: Access to system components and data is managed via an access control system(s).
- Service
RBAC
7.3.1.7Checks if the usage of PodSecurityPolicies is not in place. The rule is NON_COMPLIANT if a Kubernetes user or service account has any PodSecurityPolicy defined inline.1
Attributes
- Section
7.3.1: Access to system components and data is managed via an access control system(s).
- Service
API Server
7.3.1.8Checks in each Kubernetes Role or ClusterRole resource, if a role binding to the specified Role or ClusterRole is present for the input user or service account. The rule is NON_COMPLIANT if the role binding exists linking the user or service account to the Role or ClusterRole.1
Attributes
- Section
7.3.1: Access to system components and data is managed via an access control system(s).
- Service
RBAC
7.3.1.9Checks whether the Kubernetes Role or ClusterRole is bound to a ServiceAccount, a User, or a Group, and if it grants necessary permissions to access specific resources.0
Attributes
- Section
7.3.1: Access to system components and data is managed via an access control system(s).
- Service
RBAC (Role-Based Access Control)
7.3.1.10Checks if Kubernetes Role or ClusterRole resources grant permissions to all verbs on all resources. The rule is NON_COMPLIANT if any customer-managed Role or ClusterRole includes rules with verbs set to '*' and resources set to '*'.1
Attributes
- Section
7.3.1: Access to system components and data is managed via an access control system(s).
- Service
RBAC
7.3.1.11Checks if Kubernetes Role or ClusterRole permissions that you create grant access to all actions on individual Kubernetes resources. The rule is NON_COMPLIANT if any custom Role or ClusterRole allows full access to at least 1 Kubernetes resource.1
Attributes
- Section
7.3.1: Access to system components and data is managed via an access control system(s).
- Service
RBAC
7.3.1.12Checks if all required Kubernetes RoleBindings or ClusterRoleBindings are associated with the specified Kubernetes ServiceAccount. The rule is NON_COMPLIANT if any required binding is not associated with the ServiceAccount.1
Attributes
- Section
7.3.1: Access to system components and data is managed via an access control system(s).
- Service
API Server
7.3.1.13Checks if none of your Kubernetes Service Accounts have roles or role bindings directly attached. Service Accounts must inherit permissions from ClusterRoles or RoleBindings. The rule is NON_COMPLIANT if there is at least one Role or RoleBinding directly attached to the Service Account.1
Attributes
- Section
7.3.1: Access to system components and data is managed via an access control system(s).
- Service
API Server
7.3.1.14Checks if a Kubernetes cluster has Role-Based Access Control (RBAC) enabled. The rule is NON_COMPLIANT if the Kubernetes cluster does not have RBAC enabled.1
Attributes
- Section
7.3.1: Access to system components and data is managed via an access control system(s).
- Service
API Server
7.3.1.15Checks if Kubernetes clusters have Role-Based Access Control (RBAC) enabled. The rule is NON_COMPLIANT if RBAC features are not configured for the Kubernetes cluster.1
Attributes
- Section
7.3.1: Access to system components and data is managed via an access control system(s).
- Service
API Server
7.3.1.16Checks if a Kubernetes cluster has Role-Based Access Control (RBAC) enabled for managing permissions. The rule is NON_COMPLIANT if RBAC is not enabled.1
Attributes
- Section
7.3.1: Access to system components and data is managed via an access control system(s).
- Service
API Server
7.3.1.17Checks if a Kubernetes database pod has role-based access control (RBAC) authentication enabled. The rule is NON_COMPLIANT if the Kubernetes database pod does not have RBAC authentication enabled.1
Attributes
- Section
7.3.1: Access to system components and data is managed via an access control system(s).
- Service
API Server
7.3.1.18Checks if Kubernetes Persistent Volume Claims (PVCs) allow user permissions through access control lists (ACLs). The rule is NON_COMPLIANT if ACLs are configured for user access in Kubernetes Persistent Volume Claims.1
Attributes
- Section
7.3.1: Access to system components and data is managed via an access control system(s).
- Service
RBAC
7.3.1.19Checks if a Kubernetes Role or ClusterRole does not allow blocklisted permissions on resources within a namespace or cluster for subjects from other namespaces or clusters. For example, the rule checks that the Role or ClusterRole does not allow another namespace to perform any get, delete, or list actions on any resource within the namespace. The rule is NON_COMPLIANT if any blocklisted actions are allowed by the Role or ClusterRole.0
Attributes
- Section
7.3.1: Access to system components and data is managed via an access control system(s).
- Service
RBAC (Role-Based Access Control)
7.3.1.20Verifies that the access control policies for a Kubernetes cluster's resources are correctly configured to restrict access based on specific Kubernetes users, service accounts, or roles. The rule is COMPLIANT if there are no RoleBindings or ClusterRoleBindings present that grant access.1
Attributes
- Section
7.3.1: Access to system components and data is managed via an access control system(s).
- Service
RBAC
7.3.1.21Checks if your Kubernetes PersistentVolumeClaim policies do not allow inter-namespace permissions other than the control PersistentVolumeClaim policy that you provide.1
Attributes
- Section
7.3.1: Access to system components and data is managed via an access control system(s).
- Service
RBAC
7.3.1.22Checks if the Kubernetes Security Response Team (KST) can access your Kubernetes cluster. The rule is NON_COMPLIANT if Kubernetes Network Policy is enabled but the role for KST access is not configured.0
Attributes
- Section
7.3.1: Access to system components and data is managed via an access control system(s).
- Service
Core
7.3.2: Access to system components and data is managed via an access control system(s).2213
7.3.2.1Checks if a Kubernetes namespace is part of a specific label set. The rule is NON_COMPLIANT if the namespace does not have the expected label or if the master namespace label does not match the specified MasterLabel.0
Attributes
- Section
7.3.2: Access to system components and data is managed via an access control system(s).
- Service
Core
7.3.2.2Checks if a KubernetesNamespace has an attached Role or ClusterRole that includes a policy preventing the deletion of specific resources. The rule is NON_COMPLIANT if the KubernetesNamespace does not have roles or role bindings that include a suitable 'deny' permission (e.g., delete actions on resources such as Pods, PersistentVolumeClaims, etc.).0
Attributes
- Section
7.3.2: Access to system components and data is managed via an access control system(s).
- Service
Core
7.3.2.3Checks if a Kubernetes Pod has a RoleBinding or ClusterRoleBinding attached to it. The rule is NON_COMPLIANT if no RoleBinding or ClusterRoleBinding is attached to the Pod.0
Attributes
- Section
7.3.2: Access to system components and data is managed via an access control system(s).
- Service
Core
7.3.2.4Checks if Kubernetes containers only have read-only access to their root filesystems. The rule is NON_COMPLIANT if the securityContext.readOnlyRootFilesystem parameter in the Pod specification is set to 'false'.1
Attributes
- Section
7.3.2: Access to system components and data is managed via an access control system(s).
- Service
Core
7.3.2.5Checks if the Kubernetes Role or ClusterRole you create does not allow blocked actions on Kubernetes resources. The rule is NON_COMPLIANT if any blocked action is allowed on Kubernetes resources by the Role or ClusterRole.0
Attributes
- Section
7.3.2: Access to system components and data is managed via an access control system(s).
- Service
Core
7.3.2.6Checks if the Role-Based Access Control (RBAC) policies attached to your Kubernetes users, roles, and clusters do not allow blocked actions on all Kubernetes resources. The rule is NON_COMPLIANT if any blocked action is allowed on all Kubernetes resources in an RBAC policy.1
Attributes
- Section
7.3.2: Access to system components and data is managed via an access control system(s).
- Service
API Server
7.3.2.7Checks if the use of inline policy equivalent in Kubernetes, which would be RoleBindings and ClusterRoleBindings, is not in use. The rule is NON_COMPLIANT if a Kubernetes ServiceAccount, Role, or ClusterRole has any RoleBindings with inline policies.0
Attributes
- Section
7.3.2: Access to system components and data is managed via an access control system(s).
- Service
Role-Based Access Control (RBAC)
7.3.2.8Checks in each Kubernetes Role or ClusterRole resource, if a RoleBinding or ClusterRoleBinding that references a specific Role or ClusterRole is attached to the resource. The rule is NON_COMPLIANT if the RoleBinding or ClusterRoleBinding that references the Role or ClusterRole is found.1
Attributes
- Section
7.3.2: Access to system components and data is managed via an access control system(s).
- Service
RBAC
7.3.2.9Checks whether the Role ARN is associated with a Service Account, or a Role Binding that includes one or more Users/Groups, or a Cluster Role Binding with one or more Service Accounts.0
Attributes
- Section
7.3.2: Access to system components and data is managed via an access control system(s).
- Service
RBAC (Role-Based Access Control)
7.3.2.10Checks if Kubernetes Role and ClusterRole definitions have rules that allow permissions to all verbs on all resources. The rule is NON_COMPLIANT if any Role or ClusterRole includes a rule with verbs set to '*' and resources set to '*'.1
Attributes
- Section
7.3.2: Access to system components and data is managed via an access control system(s).
- Service
RBAC
7.3.2.11Checks if Kubernetes Role-Based Access Control (RBAC) policies that you create grant permissions to all actions on individual Kubernetes resources. The rule is NON_COMPLIANT if any custom role allows full access to at least 1 Kubernetes resource type.1
Attributes
- Section
7.3.2: Access to system components and data is managed via an access control system(s).
- Service
RBAC
7.3.2.12Checks if all specified ConfigMaps are attached to the Kubernetes Deployment. The rule is NON_COMPLIANT if a ConfigMap is not attached to the Deployment.0
Attributes
- Section
7.3.2: Access to system components and data is managed via an access control system(s).
- Service
Core
7.3.2.13Checks if none of your Kubernetes Service Accounts have roles or role bindings directly attached. Service Accounts must inherit permissions from Cluster Roles or Role Bindings. The status is NON_COMPLIANT if there is at least one Role or Role Binding that is attached directly to the Service Account.1
Attributes
- Section
7.3.2: Access to system components and data is managed via an access control system(s).
- Service
API Server
7.3.2.14Checks if a Kubernetes cluster has Role-Based Access Control (RBAC) enabled. The rule is NON_COMPLIANT if the Kubernetes cluster does not have RBAC enabled.1
Attributes
- Section
7.3.2: Access to system components and data is managed via an access control system(s).
- Service
API Server
7.3.2.15Checks if Kubernetes clusters have Role-Based Access Control (RBAC) enabled. The rule is NON_COMPLIANT if RBAC is not enabled for the Kubernetes cluster.1
Attributes
- Section
7.3.2: Access to system components and data is managed via an access control system(s).
- Service
API Server
7.3.2.16Checks if a Kubernetes cluster has Role-Based Access Control (RBAC) enabled. The rule is NON_COMPLIANT if Kubernetes RBAC is not enabled.1
Attributes
- Section
7.3.2: Access to system components and data is managed via an access control system(s).
- Service
API Server
7.3.2.17Checks if a Kubernetes Pod has RBAC (Role-Based Access Control) enabled for its ServiceAccount. The rule is NON_COMPLIANT if the Pod's ServiceAccount does not have RBAC enabled.1
Attributes
- Section
7.3.2: Access to system components and data is managed via an access control system(s).
- Service
RBAC
7.3.2.18Checks if Kubernetes PersistentVolumeClaims (PVCs) allow user permissions through Role-Based Access Control (RBAC) settings. The rule is NON_COMPLIANT if RBAC is configured to allow unauthorized user access to PVCs.1
Attributes
- Section
7.3.2: Access to system components and data is managed via an access control system(s).
- Service
RBAC
7.3.2.19Checks if a Kubernetes Role or ClusterRole does not allow blocklisted verbs (like get, delete) on resources for principals from other namespaces or external users. For example, the rule checks that a Role or ClusterRole does not allow a user to perform any verbs like get or delete on any resource in a namespace. The rule is NON_COMPLIANT if any blocklisted actions are allowed by the Role or ClusterRole.0
Attributes
- Section
7.3.2: Access to system components and data is managed via an access control system(s).
- Service
RBAC (Role-Based Access Control)
7.3.2.20Ensures that Kubernetes access control policies treat permissions as restricted, validating that no access is granted to the Kubernetes resources by any unauthorized users, service accounts, or IP ranges that are not explicitly defined. The rule is COMPLIANT if a Role or ClusterRole with no permissions is not present.1
Attributes
- Section
7.3.2: Access to system components and data is managed via an access control system(s).
- Service
RBAC
7.3.2.21Checks if your Kubernetes Persistent Volume Claims (PVC) policies do not allow other inter-namespace permissions than the control Persistent Volume (PV) policy that you provide.1
Attributes
- Section
7.3.2: Access to system components and data is managed via an access control system(s).
- Service
RBAC
7.3.2.22Checks if the Kubernetes Security Team (KST) can access your Kubernetes cluster. The rule is NON_COMPLIANT if network policies are enabled but the role for KST access is not configured.0
Attributes
- Section
7.3.2: Access to system components and data is managed via an access control system(s).
- Service
Core
7.3.3: Access to system components and data is managed via an access control system(s).2217
7.3.3.1Checks if a Kubernetes cluster is part of a specified namespace. The rule is NON_COMPLIANT if a pod is not running in the designated namespace or if the namespace does not match the specified parameter Namespace.0
Attributes
- Section
7.3.3: Access to system components and data is managed via an access control system(s).
- Service
Core
7.3.3.2Checks if a Kubernetes namespace has an associated RoleBindings or ClusterRoleBindings that prevent deletion of PersistentVolumeClaims (PVCs). The rule is NON_COMPLIANT if the namespace does not have RoleBindings/ClusterRoleBindings or those bindings do not include a suitable 'Deny' statement (statements that restrict the delete actions on PersistentVolumeClaims).1
Attributes
- Section
7.3.3: Access to system components and data is managed via an access control system(s).
- Service
RBAC
7.3.3.3Checks if a Kubernetes Pod has a Service Account attached to it. The rule is NON_COMPLIANT if no Service Account is attached to the Pod.1
Attributes
- Section
7.3.3: Access to system components and data is managed via an access control system(s).
- Service
API Server
7.3.3.4Checks if Kubernetes Pods have read-only file system access to their root filesystems. The rule is NON_COMPLIANT if the readOnlyRootFilesystem field in the Pod's securityContext is set to 'false'.1
Attributes
- Section
7.3.3: Access to system components and data is managed via an access control system(s).
- Service
Core
7.3.3.5Checks if the Kubernetes Role or ClusterRole policies that you create do not allow blocked actions on Kubernetes Secrets. The rule is NON_COMPLIANT if any blocked action is allowed on Kubernetes Secrets by the managed Role or ClusterRole policies.1
Attributes
- Section
7.3.3: Access to system components and data is managed via an access control system(s).
- Service
RBAC
7.3.3.6Checks if the RBAC (Role-Based Access Control) policies attached to your Kubernetes users, service accounts, and roles do not allow blocked actions on all Kubernetes resources. The rule is NON_COMPLIANT if any blocked action is permitted on all Kubernetes resources in an RBAC policy.1
Attributes
- Section
7.3.3: Access to system components and data is managed via an access control system(s).
- Service
API Server
7.3.3.7Checks if the Kubernetes Roles or ClusterRoles feature is not in use as inline policies. The rule is NON_COMPLIANT if a Kubernetes user or service account has any Roles or ClusterRoles defined inline that grant permissions directly without using a predefined RoleBinding or ClusterRoleBinding.1
Attributes
- Section
7.3.3: Access to system components and data is managed via an access control system(s).
- Service
RBAC
7.3.3.8Checks in each Kubernetes Role or ClusterRole, if a specific RoleBinding or ClusterRoleBinding that grants permissions is associated with the Role or ClusterRole. The rule is NON_COMPLIANT if the RoleBinding or ClusterRoleBinding is linked to the Role or ClusterRole.1
Attributes
- Section
7.3.3: Access to system components and data is managed via an access control system(s).
- Service
RBAC
7.3.3.9Checks whether the RoleBinding for a specific role is attached to a Kubernetes user, a group with one or more Kubernetes users, or a ServiceAccount with one or more trusted entities.0
Attributes
- Section
7.3.3: Access to system components and data is managed via an access control system(s).
- Service
Kubernetes RBAC (Role-Based Access Control)
7.3.3.10Checks if Kubernetes Role or ClusterRole definitions include permissions that grant access to all actions on all resources. The rule is NON_COMPLIANT if any Role or ClusterRole includes rules with 'verbs': ['*'] for 'apiGroups': ['*'] and 'resources': ['*'].1
Attributes
- Section
7.3.3: Access to system components and data is managed via an access control system(s).
- Service
RBAC
7.3.3.11Checks if Kubernetes Role or ClusterRole policies that you create grant permissions to all actions on individual Kubernetes resources. The rule is NON_COMPLIANT if any custom Role or ClusterRole allows full access to at least 1 Kubernetes resource.1
Attributes
- Section
7.3.3: Access to system components and data is managed via an access control system(s).
- Service
RBAC
7.3.3.12Checks if all specified Kubernetes Roles or ClusterRoles are granted to the ServiceAccount. The rule is NON_COMPLIANT if a Role or ClusterRole is not bound to the ServiceAccount.1
Attributes
- Section
7.3.3: Access to system components and data is managed via an access control system(s).
- Service
API Server
7.3.3.13Checks if none of your Kubernetes Service Accounts have policies (RoleBindings or ClusterRoleBindings) attached directly. Service Accounts must inherit permissions from Roles or ClusterRoles. The rule is NON_COMPLIANT if there is at least one RoleBinding or ClusterRoleBinding that is directly attached to the Service Account.1
Attributes
- Section
7.3.3: Access to system components and data is managed via an access control system(s).
- Service
API Server
7.3.3.14Checks if a Kubernetes cluster has Role-Based Access Control (RBAC) enabled. The rule is NON_COMPLIANT if a Kubernetes cluster does not have RBAC enabled.1
Attributes
- Section
7.3.3: Access to system components and data is managed via an access control system(s).
- Service
API Server
7.3.3.15Checks if Kubernetes clusters have Role-Based Access Control (RBAC) enabled. The rule is NON_COMPLIANT if RBAC is not configured for the Kubernetes cluster.1
Attributes
- Section
7.3.3: Access to system components and data is managed via an access control system(s).
- Service
API Server
7.3.3.16Checks if a Kubernetes deployment has Role-Based Access Control (RBAC) enabled for authentication. The rule is NON_COMPLIANT if the Kubernetes deployment does not have RBAC enabled.1
Attributes
- Section
7.3.3: Access to system components and data is managed via an access control system(s).
- Service
API Server
7.3.3.17Checks if a Kubernetes cluster has Role-Based Access Control (RBAC) enabled. The rule is NON_COMPLIANT if RBAC is not enabled for the Kubernetes cluster.1
Attributes
- Section
7.3.3: Access to system components and data is managed via an access control system(s).
- Service
API Server
7.3.3.18Checks if Kubernetes Persistent Volume Claims (PVCs) allow user permissions through access control settings in their underlying storage classes. The rule is NON_COMPLIANT if access control lists (ACLs) are configured for user access in Persistent Volume Claims.1
Attributes
- Section
7.3.3: Access to system components and data is managed via an access control system(s).
- Service
RBAC
7.3.3.19Checks if a Kubernetes Role or ClusterRole does not allow blocklisted permissions on resources within the namespace for subjects from other Kubernetes namespaces. For example, the rule checks that the Role or ClusterRole does not allow any 'get' or 'delete' actions on specific resources (like Pods, Secrets, etc.) from other namespaces. The rule is NON_COMPLIANT if any blocklisted actions are allowed by the Role or ClusterRole.0
Attributes
- Section
7.3.3: Access to system components and data is managed via an access control system(s).
- Service
RBAC (Role-Based Access Control)
7.3.3.20Checks that the access granted by the Kubernetes cluster is restricted by any of the Kubernetes subjects, such as users, service accounts, groups, or network policies that you provide. The rule is COMPLIANT if a Role or ClusterRole binding is not present.0
Attributes
- Section
7.3.3: Access to system components and data is managed via an access control system(s).
- Service
Core
7.3.3.21Verifies that the Kubernetes cluster role bindings do not permit users from other namespaces to access the resources defined in the specified role, ensuring that only authorized roles have the necessary permissions.1
Attributes
- Section
7.3.3: Access to system components and data is managed via an access control system(s).
- Service
RBAC
7.3.3.22Checks if the Security Response Team (SRT) can access your Kubernetes cluster. The rule is NON_COMPLIANT if the necessary permissions for SRT access are not configured in the RoleBindings for the Security context in Kubernetes.0
Attributes
- Section
7.3.3: Access to system components and data is managed via an access control system(s).
- Service
Core
8.2.1: User identification and related accounts for users and administrators are strictly managed throughout an accounts lifecycle.52
8.2.1.1Checks if running Kubernetes pods are deployed using secrets for sensitive information. The rule is NON_COMPLIANT if a running pod is using hardcoded secrets in environment variables instead of Kubernetes Secrets.1
Attributes
- Section
8.2.1: User identification and related accounts for users and administrators are strictly managed throughout an accounts lifecycle.
- Service
Core
8.2.1.2Checks whether Kubernetes namespaces have at least one associated pod.0
Attributes
- Section
8.2.1: User identification and related accounts for users and administrators are strictly managed throughout an accounts lifecycle.
- Service
Core
8.2.1.3Checks whether the Role or ClusterRole is bound to a specific User, Group, or ServiceAccount in Kubernetes.0
Attributes
- Section
8.2.1: User identification and related accounts for users and administrators are strictly managed throughout an accounts lifecycle.
- Service
RBAC (Role-Based Access Control)
8.2.1.4Checks if root user credentials are configured in Kubernetes. The rule is COMPLIANT if the root user credentials do not exist. Otherwise, NON_COMPLIANT.1
Attributes
- Section
8.2.1: User identification and related accounts for users and administrators are strictly managed throughout an accounts lifecycle.
- Service
Core
8.2.1.5Checks whether Kubernetes service accounts are members of at least one Kubernetes role or role binding.0
Attributes
- Section
8.2.1: User identification and related accounts for users and administrators are strictly managed throughout an accounts lifecycle.
- Service
RBAC (Role-Based Access Control)
8.2.2: User identification and related accounts for users and administrators are strictly managed throughout an accounts lifecycle.103
8.2.2.2Checks if running Kubernetes pods are deployed using service accounts. The rule is NON_COMPLIANT if a running pod is deployed without an associated service account.1
Attributes
- Section
8.2.2: User identification and related accounts for users and administrators are strictly managed throughout an accounts lifecycle.
- Service
API Server
8.2.2.3Checks if Kubernetes Secrets are exposed as environment variables in a Pod definition. The rule is NON_COMPLIANT if one or more environment variable names correspond to keys in the 'secretKeys' list, while ignoring environment variables sourced from other systems like Amazon S3.1
Attributes
- Section
8.2.2: User identification and related accounts for users and administrators are strictly managed throughout an accounts lifecycle.
- Service
Core
8.2.2.4Verifies if Kubernetes RBAC (Role-Based Access Control) groups have at least one associated user or service account.1
Attributes
- Section
8.2.2: User identification and related accounts for users and administrators are strictly managed throughout an accounts lifecycle.
- Service
API Server
8.2.2.5Checks whether a Kubernetes Role or ClusterRole is bound to a ServiceAccount, or to a User or Group of Users, enabling access to specific resources within a namespace or cluster.0
Attributes
- Section
8.2.2: User identification and related accounts for users and administrators are strictly managed throughout an accounts lifecycle.
- Service
RBAC (Role-Based Access Control)
8.2.2.6Checks if the root user access key is available. The rule is COMPLIANT if the user access key does not exist. Otherwise, NON_COMPLIANT.0
Attributes
- Section
8.2.2: User identification and related accounts for users and administrators are strictly managed throughout an accounts lifecycle.
- Service
IAM
8.2.2.7Verifies if Kubernetes users or service accounts are associated with at least one RoleBinding or ClusterRoleBinding.0
Attributes
- Section
8.2.2: User identification and related accounts for users and administrators are strictly managed throughout an accounts lifecycle.
- Service
RBAC (Role-Based Access Control)
8.2.2.8Checks if Kubernetes Secrets have a defined lifecycle policy for automatic rotation. If a maximum rotation frequency is specified, it compares the current rotation schedule against this maximum allowed frequency. The rule is NON_COMPLIANT if the secret does not have a rotation strategy defined, or if the rotation frequency exceeds the specified maximum.0
Attributes
- Section
8.2.2: User identification and related accounts for users and administrators are strictly managed throughout an accounts lifecycle.
- Service
RBAC (Role-Based Access Control)
8.2.2.9Checks if Kubernetes Secrets are updated successfully according to the defined rotation schedule. The system monitors the timestamp of the last update and flags the secret as NON_COMPLIANT if the scheduled rotation time passes without an update.0
Attributes
- Section
8.2.2: User identification and related accounts for users and administrators are strictly managed throughout an accounts lifecycle.
- Service
RBAC (Role-Based Access Control)
8.2.2.10Checks if Kubernetes Secrets have been updated (rotated) in the past specified number of days. The rule is NON_COMPLIANT if a secret has not been updated for more than maxDaysSinceUpdate number of days. The default value is 90 days.0
Attributes
- Section
8.2.2: User identification and related accounts for users and administrators are strictly managed throughout an accounts lifecycle.
- Service
RBAC (Role-Based Access Control)
8.2.2.11Checks if Kubernetes secrets have been accessed within a specified number of days. The rule is NON_COMPLIANT if a secret has not been accessed in 'unusedForDays' number of days. The default value is 90 days.0
Attributes
- Section
8.2.2: User identification and related accounts for users and administrators are strictly managed throughout an accounts lifecycle.
- Service
RBAC (Role-Based Access Control)
8.2.4: User identification and related accounts for users and administrators are strictly managed throughout an accounts lifecycle.51
8.2.4.1Checks if running Kubernetes pods are launched using service accounts. The rule is NON_COMPLIANT if a running pod is launched without a service account.1
Attributes
- Section
8.2.4: User identification and related accounts for users and administrators are strictly managed throughout an accounts lifecycle.
- Service
API Server
8.2.4.2Checks whether a Kubernetes Role or ClusterRole has at least one associated ServiceAccount.0
Attributes
- Section
8.2.4: User identification and related accounts for users and administrators are strictly managed throughout an accounts lifecycle.
- Service
Kubernetes Role Management
8.2.4.3Checks whether a Role in Kubernetes is attached to a User, a Group of Users, or a Service Account with one or more trusted entities.0
Attributes
- Section
8.2.4: User identification and related accounts for users and administrators are strictly managed throughout an accounts lifecycle.
- Service
RBAC (Role-Based Access Control)
8.2.4.4Checks if the Kubernetes admin user access token is available. The rule is COMPLIANT if the user access token does not exist. Otherwise, NON_COMPLIANT.0
Attributes
- Section
8.2.4: User identification and related accounts for users and administrators are strictly managed throughout an accounts lifecycle.
- Service
Core
8.2.4.5Checks whether Kubernetes users are members of at least one Kubernetes RoleBinding or ClusterRoleBinding.0
Attributes
- Section
8.2.4: User identification and related accounts for users and administrators are strictly managed throughout an accounts lifecycle.
- Service
Kubernetes Authorization
8.2.5: User identification and related accounts for users and administrators are strictly managed throughout an accounts lifecycle.53
8.2.5.1Checks if running Kubernetes Pods are launched using secrets for sensitive information such as SSH keys. The rule is NON_COMPLIANT if a running Pod is launched with sensitive information directly in the specification instead of using Kubernetes secrets.1
Attributes
- Section
8.2.5: User identification and related accounts for users and administrators are strictly managed throughout an accounts lifecycle.
- Service
Core
8.2.5.2Verifies that at least one Kubernetes user is associated with each role or group in Kubernetes RBAC (Role-Based Access Control).1
Attributes
- Section
8.2.5: User identification and related accounts for users and administrators are strictly managed throughout an accounts lifecycle.
- Service
RBAC
8.2.5.3Checks whether the Kubernetes Role or ClusterRole is bound to a ServiceAccount, or a group of users (via RoleBinding or ClusterRoleBinding) with one or more ServiceAccounts, or a PodSecurityPolicy with one or more trusted entities.0
Attributes
- Section
8.2.5: User identification and related accounts for users and administrators are strictly managed throughout an accounts lifecycle.
- Service
Core
8.2.5.4Checks if the Kubernetes root user (cluster-admin) has any access keys. The rule is COMPLIANT if no service accounts or users with cluster-admin privileges exist that possess access keys. Otherwise, NON_COMPLIANT.1
Attributes
- Section
8.2.5: User identification and related accounts for users and administrators are strictly managed throughout an accounts lifecycle.
- Service
Core
8.2.5.5Checks whether Kubernetes users are members of at least one RoleBinding or ClusterRoleBinding.0
Attributes
- Section
8.2.5: User identification and related accounts for users and administrators are strictly managed throughout an accounts lifecycle.
- Service
Core
8.2.6: User identification and related accounts for users and administrators are strictly managed throughout an accounts lifecycle.31
8.2.6.1Checks whether Kubernetes RBAC roles have at least one user or service account associated with them.1
Attributes
- Section
8.2.6: User identification and related accounts for users and administrators are strictly managed throughout an accounts lifecycle.
- Service
API Server
8.2.6.2Checks if your Kubernetes service accounts have tokens that have not been used within the specified number of days you provided. The rule is NON_COMPLIANT if there are inactive service accounts not recently used.0
Attributes
- Section
8.2.6: User identification and related accounts for users and administrators are strictly managed throughout an accounts lifecycle.
- Service
Core
8.2.6.3Checks if Kubernetes Secrets have been accessed within a specified number of days. The rule is NON_COMPLIANT if a secret has not been accessed in 'unusedForDays' number of days. The default value is 90 days.0
Attributes
- Section
8.2.6: User identification and related accounts for users and administrators are strictly managed throughout an accounts lifecycle.
- Service
Core
8.2.7: User identification and related accounts for users and administrators are strictly managed throughout an accounts lifecycle.2212
8.2.7.1Checks if a Kubernetes namespace is associated with a specific organization. The rule is NON_COMPLIANT if a namespace is not part of the defined organization or the organization master namespace does not match the specified MasterNamespaceId.0
Attributes
- Section
8.2.7: User identification and related accounts for users and administrators are strictly managed throughout an accounts lifecycle.
- Service
Core
8.2.7.2Checks if a Kubernetes namespace has a resource-based policy (such as NetworkPolicy or PodSecurityPolicy) that prevents deletion of critical Pods. The rule is NON_COMPLIANT if the namespace does not have resource-based policies or has policies without a suitable 'Deny' statement (statements that include delete actions on Pods, Services, or related resources).0
Attributes
- Section
8.2.7: User identification and related accounts for users and administrators are strictly managed throughout an accounts lifecycle.
- Service
Core
8.2.7.3Checks if a Kubernetes pod has an associated Kubernetes Service Account. The rule is NON_COMPLIANT if no Service Account is attached to the pod.1
Attributes
- Section
8.2.7: User identification and related accounts for users and administrators are strictly managed throughout an accounts lifecycle.
- Service
API Server
8.2.7.4Checks if Kubernetes containers have read-only access to their root filesystems. The rule is NON_COMPLIANT if the readOnlyRootFilesystem parameter in the container specification of a Pod or Deployment is set to 'false'.1
Attributes
- Section
8.2.7: User identification and related accounts for users and administrators are strictly managed throughout an accounts lifecycle.
- Service
Core
8.2.7.5Checks if the Kubernetes Role or ClusterRole policies that you create do not allow blocked actions on specific resources. The rule is NON_COMPLIANT if any blocked action is allowed on the specified resources by the Role or ClusterRole policies.0
Attributes
- Section
8.2.7: User identification and related accounts for users and administrators are strictly managed throughout an accounts lifecycle.
- Service
Core
8.2.7.6Checks if the role policies attached to your Kubernetes service accounts do not allow blocked actions on all Kubernetes resources. The rule is NON_COMPLIANT if any blocked action is allowed on all Kubernetes resources in a role policy.0
Attributes
- Section
8.2.7: User identification and related accounts for users and administrators are strictly managed throughout an accounts lifecycle.
- Service
Core
8.2.7.7Checks if the Role-based access control (RBAC) feature in Kubernetes is not in use. The rule is NON_COMPLIANT if any Kubernetes user or service account has any Role or ClusterRole associated with it directly.1
Attributes
- Section
8.2.7: User identification and related accounts for users and administrators are strictly managed throughout an accounts lifecycle.
- Service
API Server
8.2.7.8Checks in each Kubernetes Role or ClusterRole resource, if a RoleBinding or ClusterRoleBinding in the input parameter is associated with the Role or ClusterRole resource. The rule is NON_COMPLIANT if the RoleBinding or ClusterRoleBinding is associated with the Role or ClusterRole resource.1
Attributes
- Section
8.2.7: User identification and related accounts for users and administrators are strictly managed throughout an accounts lifecycle.
- Service
RBAC
8.2.7.9Checks whether the Role ARN is attached to a Kubernetes ServiceAccount, or a Role/ClusterRole with one or more associated ServiceAccounts, or a Pod with a service account identity.0
Attributes
- Section
8.2.7: User identification and related accounts for users and administrators are strictly managed throughout an accounts lifecycle.
- Service
Core
8.2.7.10Checks if Kubernetes Role or ClusterRole policies grant permissions to all actions on all resources. The rule is NON_COMPLIANT if any customer managed Role or ClusterRole includes rules with 'verbs': ['*'] on the 'resources': ['*'].1
Attributes
- Section
8.2.7: User identification and related accounts for users and administrators are strictly managed throughout an accounts lifecycle.
- Service
RBAC
8.2.7.11Checks if Kubernetes Role-Based Access Control (RBAC) policies that you create grant permissions to all actions on individual Kubernetes resources. The rule is NON_COMPLIANT if any Kubernetes Role or ClusterRole allows full access to at least 1 Kubernetes resource.1
Attributes
- Section
8.2.7: User identification and related accounts for users and administrators are strictly managed throughout an accounts lifecycle.
- Service
RBAC
8.2.7.12Checks if all specified Kubernetes RoleBindings are attached to the ServiceAccount. The rule is NON_COMPLIANT if a RoleBinding is not attached to the ServiceAccount.0
Attributes
- Section
8.2.7: User identification and related accounts for users and administrators are strictly managed throughout an accounts lifecycle.
- Service
Role-Based Access Control (RBAC)
8.2.7.13Checks if none of your Kubernetes users have roles or role bindings directly attached. Kubernetes users must inherit permissions from groups or cluster roles. The rule is NON_COMPLIANT if there is at least one role or role binding that is attached directly to the Kubernetes user.0
Attributes
- Section
8.2.7: User identification and related accounts for users and administrators are strictly managed throughout an accounts lifecycle.
- Service
Core
8.2.7.14Checks if a Kubernetes cluster has Role-Based Access Control (RBAC) enabled. The rule is NON_COMPLIANT if the Kubernetes cluster does not have RBAC enabled.1
Attributes
- Section
8.2.7: User identification and related accounts for users and administrators are strictly managed throughout an accounts lifecycle.
- Service
API Server
8.2.7.15Checks if Kubernetes clusters have Role-Based Access Control (RBAC) enabled. The rule is NON_COMPLIANT if the RBAC is not configured for the Kubernetes cluster.1
Attributes
- Section
8.2.7: User identification and related accounts for users and administrators are strictly managed throughout an accounts lifecycle.
- Service
API Server
8.2.7.16Checks if a Kubernetes cluster has Role-Based Access Control (RBAC) enabled for authentication. The rule is NON_COMPLIANT if the Kubernetes cluster does not have RBAC enabled.1
Attributes
- Section
8.2.7: User identification and related accounts for users and administrators are strictly managed throughout an accounts lifecycle.
- Service
API Server
8.2.7.17Checks if a Kubernetes Pod has role-based access control (RBAC) enabled. The rule is NON_COMPLIANT if a Kubernetes Pod does not have RBAC enabled.1
Attributes
- Section
8.2.7: User identification and related accounts for users and administrators are strictly managed throughout an accounts lifecycle.
- Service
RBAC
8.2.7.18Checks if Kubernetes Persistent Volumes (PVs) allow user permissions through access control policies. The rule is NON_COMPLIANT if access control policies are configured for user access in Kubernetes Persistent Volumes.1
Attributes
- Section
8.2.7: User identification and related accounts for users and administrators are strictly managed throughout an accounts lifecycle.
- Service
RBAC
8.2.7.19Checks if a Kubernetes Role or ClusterRole does not allow blocklisted permissions for principals from other namespaces or external entities on resources within the namespace. For example, the rule checks that the Role or ClusterRole does not allow any actions like 'get', 'delete', or 'list' on resources when accessed by external users. The rule is NON_COMPLIANT if any blocklisted actions are allowed by the Role or ClusterRole.0
Attributes
- Section
8.2.7: User identification and related accounts for users and administrators are strictly managed throughout an accounts lifecycle.
- Service
RBAC (Role-Based Access Control)
8.2.7.20Checks that the access granted by the Kubernetes namespace is restricted by any of the Kubernetes roles, role bindings, service accounts, users, or network policies that you provide. The rule is COMPLIANT if a network policy is not present.0
Attributes
- Section
8.2.7: User identification and related accounts for users and administrators are strictly managed throughout an accounts lifecycle.
- Service
Core
8.2.7.21Checks if your Kubernetes PersistentVolumes policies do not allow other inter-account permissions than the control PersistentVolume policy that you provide.1
Attributes
- Section
8.2.7: User identification and related accounts for users and administrators are strictly managed throughout an accounts lifecycle.
- Service
RBAC
8.2.7.22Checks if the Kubernetes Security Team (KST) can access your Kubernetes cluster. The rule is NON_COMPLIANT if Kubernetes RBAC is enabled but the role for KST access is not configured.0
Attributes
- Section
8.2.7: User identification and related accounts for users and administrators are strictly managed throughout an accounts lifecycle.
- Service
Core
8.2.8: User identification and related accounts for users and administrators are strictly managed throughout an accounts lifecycle.2415
8.2.8.1Checks if a Kubernetes cluster is part of a specific namespace or if the namespace matches the defined MasterNamespaceId. The rule is NON_COMPLIANT if a Kubernetes cluster is not part of the specified namespace or if the namespace master ID does not match the rule parameter MasterNamespaceId.0
Attributes
- Section
8.2.8: User identification and related accounts for users and administrators are strictly managed throughout an accounts lifecycle.
- Service
Core
8.2.8.2Verifies that only IMDSv2 (Instance Metadata Service version 2) is enabled for the instance. The status is NON_COMPLIANT if the launch configuration does not specify the metadata version or if both IMDSv1 and IMDSv2 are concurrently enabled.0
Attributes
- Section
8.2.8: User identification and related accounts for users and administrators are strictly managed throughout an accounts lifecycle.
- Service
EC2
8.2.8.3Checks if a Kubernetes PersistentVolumeClaim (PVC) has annotations or policies that prevent deletion of associated PersistentVolume (PV) resources. The rule is NON_COMPLIANT if the PVC does not have deletion policies or has policies without suitable 'Deny' annotations (annotations that prevent 'delete' operations on the PV).0
Attributes
- Section
8.2.8: User identification and related accounts for users and administrators are strictly managed throughout an accounts lifecycle.
- Service
Core
8.2.8.4Checks if your Kubernetes Pod is configured with the Pod Security Standards requiring the use of the 'RunAsNonRoot' security context. The rule is NON_COMPLIANT if the security context does not enforce this setting.1
Attributes
- Section
8.2.8: User identification and related accounts for users and administrators are strictly managed throughout an accounts lifecycle.
- Service
API Server
8.2.8.5Checks if a Kubernetes Pod has a ServiceAccount attached to it. The rule is NON_COMPLIANT if no ServiceAccount is attached to the Pod.1
Attributes
- Section
8.2.8: User identification and related accounts for users and administrators are strictly managed throughout an accounts lifecycle.
- Service
API Server
8.2.8.6Checks if Kubernetes Pods have a read-only root filesystem by verifying that the 'readOnlyRootFilesystem' parameter in the container spec is set to 'true'. The rule is NON_COMPLIANT if this parameter is set to 'false'.1
Attributes
- Section
8.2.8: User identification and related accounts for users and administrators are strictly managed throughout an accounts lifecycle.
- Service
Core
8.2.8.7Checks if the Kubernetes Role or ClusterRole created does not allow blocked actions on Kubernetes resources. The rule is NON_COMPLIANT if any blocked action is allowed by the Role or ClusterRole.0
Attributes
- Section
8.2.8: User identification and related accounts for users and administrators are strictly managed throughout an accounts lifecycle.
- Service
Core
8.2.8.8Checks if the RoleBindings attached to your Kubernetes ServiceAccounts do not allow access to blocked resources in all Kubernetes namespaces. The rule is NON_COMPLIANT if any blocked resource access is allowed in a RoleBinding.1
Attributes
- Section
8.2.8: User identification and related accounts for users and administrators are strictly managed throughout an accounts lifecycle.
- Service
RBAC
8.2.8.9Checks if the Pod Security Policy (PSP) feature is not in use. The rule is NON_COMPLIANT if a Kubernetes Pod has any pod specifications that allow the use of inline security policies.0
Attributes
- Section
8.2.8: User identification and related accounts for users and administrators are strictly managed throughout an accounts lifecycle.
- Service
Core
8.2.8.10Checks in each Kubernetes Role or ClusterRole resource if a RoleBinding or ClusterRoleBinding with the specified role is attached to it. The rule is NON_COMPLIANT if the RoleBinding or ClusterRoleBinding is associated with the Role or ClusterRole.1
Attributes
- Section
8.2.8: User identification and related accounts for users and administrators are strictly managed throughout an accounts lifecycle.
- Service
RBAC
8.2.8.11Checks whether a RoleBinding or ClusterRoleBinding is applied to a User, a Group with one or more Users, or a ServiceAccount with associated permissions in Kubernetes.0
Attributes
- Section
8.2.8: User identification and related accounts for users and administrators are strictly managed throughout an accounts lifecycle.
- Service
Kubernetes RBAC (Role-Based Access Control)
8.2.8.12Checks if Kubernetes Role or ClusterRole objects grant permissions to all verbs on all resources. The rule is NON_COMPLIANT if any custom Role or ClusterRole has rules that include 'verbs': ['*'] over 'resources': ['*'].1
Attributes
- Section
8.2.8: User identification and related accounts for users and administrators are strictly managed throughout an accounts lifecycle.
- Service
RBAC
8.2.8.13Checks if Kubernetes Role and ClusterRole bindings grant permissions that allow full access to all actions on individual Kubernetes resources. The rule is NON_COMPLIANT if any Role or ClusterRole allows full access to at least 1 Kubernetes resource.1
Attributes
- Section
8.2.8: User identification and related accounts for users and administrators are strictly managed throughout an accounts lifecycle.
- Service
RBAC
8.2.8.14Checks if all required Kubernetes Roles or ClusterRoles specified in the list are bound to the service account in the Kubernetes cluster. The rule is NON_COMPLIANT if a required Role or ClusterRole is not bound to the service account.1
Attributes
- Section
8.2.8: User identification and related accounts for users and administrators are strictly managed throughout an accounts lifecycle.
- Service
RBAC
8.2.8.15Checks if none of your Kubernetes Service Accounts have default RoleBindings or ClusterRoleBindings attached. Service Accounts must inherit permissions from Roles or ClusterRoles. The rule is NON_COMPLIANT if there is at least one RoleBinding or ClusterRoleBinding that is directly attached to the Service Account.1
Attributes
- Section
8.2.8: User identification and related accounts for users and administrators are strictly managed throughout an accounts lifecycle.
- Service
API Server
8.2.8.16Checks if a Kubernetes cluster has Role-Based Access Control (RBAC) enabled. The rule is NON_COMPLIANT if the Kubernetes cluster does not have RBAC enabled.1
Attributes
- Section
8.2.8: User identification and related accounts for users and administrators are strictly managed throughout an accounts lifecycle.
- Service
API Server
8.2.8.17Checks if Kubernetes clusters have Role-Based Access Control (RBAC) enabled. The rule is NON_COMPLIANT if RBAC is not enabled for the Kubernetes cluster.1
Attributes
- Section
8.2.8: User identification and related accounts for users and administrators are strictly managed throughout an accounts lifecycle.
- Service
API Server
8.2.8.18Checks if a Kubernetes cluster has Role-Based Access Control (RBAC) enabled. The rule is NON_COMPLIANT if the Kubernetes cluster does not have RBAC enabled.1
Attributes
- Section
8.2.8: User identification and related accounts for users and administrators are strictly managed throughout an accounts lifecycle.
- Service
API Server
8.2.8.19Checks if a Kubernetes cluster has Role-Based Access Control (RBAC) enabled. The rule is NON_COMPLIANT if the Kubernetes cluster does not have RBAC enabled.1
Attributes
- Section
8.2.8: User identification and related accounts for users and administrators are strictly managed throughout an accounts lifecycle.
- Service
API Server
8.2.8.20Checks if Kubernetes Persistent Volume Claims (PVCs) allow user access through access policies. The rule is NON_COMPLIANT if user access policies are configured for PVCs.1
Attributes
- Section
8.2.8: User identification and related accounts for users and administrators are strictly managed throughout an accounts lifecycle.
- Service
RBAC
8.2.8.21Checks if a Kubernetes Role or ClusterRole does not allow blocklisted permissions on resources for users from other namespaces or service accounts. For example, the rule checks that the Role/ClusterRole does not allow any 'get', 'list', or 'delete' permissions on pods for accounts that are not in the specified namespace. The rule is NON_COMPLIANT if any blocklisted actions are allowed by the Role/ClusterRole.0
Attributes
- Section
8.2.8: User identification and related accounts for users and administrators are strictly managed throughout an accounts lifecycle.
- Service
Core
8.2.8.22Checks that the access granted by the Kubernetes Role or ClusterRole is restricted by any specific users, service accounts, or network policies that you provide. The rule is COMPLIANT if a Role/ClusterRole is not present.0
Attributes
- Section
8.2.8: User identification and related accounts for users and administrators are strictly managed throughout an accounts lifecycle.
- Service
Core
8.2.8.23Checks if your Kubernetes PersistentVolumeClaims (PVC) are not allowing other inter-namespace permissions other than the control PersistentVolume (PV) policies that you provide.1
Attributes
- Section
8.2.8: User identification and related accounts for users and administrators are strictly managed throughout an accounts lifecycle.
- Service
RBAC
8.2.8.24Verifies if the Shield Response Team (SRT) has the necessary permissions to access the Kubernetes cluster. The status is NON_COMPLIANT if the Kubernetes cluster has enabled the equivalent of Shield Advanced but the role for SRT access is not configured properly.0
Attributes
- Section
8.2.8: User identification and related accounts for users and administrators are strictly managed throughout an accounts lifecycle.
- Service
Core
8.3.2: Strong authentication for users and administrators is established and managed.5126
8.3.2.1Checks if all HTTP services in Kubernetes are configured to redirect HTTP traffic to HTTPS. The rule is NON_COMPLIANT if one or more HTTP services do not have HTTP to HTTPS redirection configured or if any HTTP service forwards traffic to another HTTP service instead of redirecting.0
Attributes
- Section
8.3.2: Strong authentication for users and administrators is established and managed.
- Service
API Server
8.3.2.2Checks if all HTTP methods in the Kubernetes Ingress resources have caching enabled and caching is encrypted. The rule is NON_COMPLIANT if any method in a Kubernetes Ingress does not have caching enabled or the caching is not encrypted.0
Attributes
- Section
8.3.2: Strong authentication for users and administrators is established and managed.
- Service
API Server
8.3.2.3Checks if a Kubernetes Secret is encrypted at rest. The rule is NON_COMPLIANT if encryption of Secrets at rest is not enabled in the Kubernetes cluster.1
Attributes
- Section
8.3.2: Strong authentication for users and administrators is established and managed.
- Service
API Server
8.3.2.4Validates whether the backup storage for a Kubernetes cluster is encrypted. The status is NON_COMPLIANT if the backup storage is not encrypted, indicating a potential security risk.0
Attributes
- Section
8.3.2: Strong authentication for users and administrators is established and managed.
- Service
Kubernetes Backup
8.3.2.5Checks if Kubernetes Ingress resources are configured to use deprecated SSL protocols for HTTPS communication between Ingress controllers and backend services. This rule is NON_COMPLIANT for an Ingress resource if any 'tls' configuration includes 'SSLv3'.0
Attributes
- Section
8.3.2: Strong authentication for users and administrators is established and managed.
- Service
API Server
8.3.2.6Checks if Kubernetes Ingress resources are enforcing HTTPS for backend services. The rule is NON_COMPLIANT if 'backend.service.port' is configured with a non-secure port (e.g., 80) or if 'ingress.spec.tls' is not specified while using 'path' with a non-secure backend service.0
Attributes
- Section
8.3.2: Strong authentication for users and administrators is established and managed.
- Service
API Server
8.3.2.7Checks if your Kubernetes Ingress resources enforce HTTPS for traffic. The rule is NON_COMPLIANT if the value of the 'nginx.ingress.kubernetes.io/force-ssl-redirect' annotation is set to 'false'.0
Attributes
- Section
8.3.2: Strong authentication for users and administrators is established and managed.
- Service
API Server
8.3.2.8Checks if Kubernetes Logging (e.g., Fluentd) is configured to encrypt logs at rest using a specified encryption key or mechanism. The rule is NON_COMPLIANT if logging is not encrypted or is using an encryption method not specified in the rule parameter.0
Attributes
- Section
8.3.2: Strong authentication for users and administrators is established and managed.
- Service
API Server
8.3.2.9Checks if Kubernetes Secrets are configured to use encryption at rest. The rule is COMPLIANT if the encryption provider is defined in the kube-apiserver configuration.1
Attributes
- Section
8.3.2: Strong authentication for users and administrators is established and managed.
- Service
API Server
8.3.2.10Checks if a Kubernetes pod specification has encryption enabled for all of its secrets. The rule is NON_COMPLIANT if 'encryptionEnabled' is set to 'false' for any of the secret configurations used within the pod.0
Attributes
- Section
8.3.2: Strong authentication for users and administrators is established and managed.
- Service
Core
8.3.2.12Checks if a Kubernetes Pod configured with Persistent Volumes has encryption enabled for its storage. The rule is NON_COMPLIANT if 'encryptionDisabled' is set to 'true' in the PersistentVolumeClaim specifications.0
Attributes
- Section
8.3.2: Strong authentication for users and administrators is established and managed.
- Service
Core
8.3.2.13Checks if Kubernetes etcd clusters are encrypted. The rule is NON_COMPLIANT if an etcd cluster is not encrypted.1
Attributes
- Section
8.3.2: Strong authentication for users and administrators is established and managed.
- Service
ETCD
8.3.2.14Checks if your Kubernetes Service has the 'spec.type' set to 'LoadBalancer'. The rule is NON_COMPLIANT if a Service does not use LoadBalancer type, which is necessary for exposing the service securely over the network.0
Attributes
- Section
8.3.2: Strong authentication for users and administrators is established and managed.
- Service
Core
8.3.2.15Checks if Kubernetes Database Services (e.g., PostgreSQL, MySQL) have SSL/TLS connections configured. The rule is NON_COMPLIANT if the database service does not have SSL/TLS enabled.0
Attributes
- Section
8.3.2: Strong authentication for users and administrators is established and managed.
- Service
Kubernetes Database Services
8.3.2.16Checks if Kubernetes Secrets used for Redis data stores are configured to require TLS/SSL encryption for data in transit between Redis instances and clients. The rule is NON_COMPLIANT if TLS/SSL encryption is not enabled.0
Attributes
- Section
8.3.2: Strong authentication for users and administrators is established and managed.
- Service
Core
8.3.2.17Checks if storage encryption is enabled for your Kubernetes persistent volumes. The rule is NON_COMPLIANT if storage encryption is not enabled.0
Attributes
- Section
8.3.2: Strong authentication for users and administrators is established and managed.
- Service
Core
8.3.2.18Checks if a Kubernetes PersistentVolume is encrypted. The rule is NON_COMPLIANT if the PersistentVolume is not encrypted, or if the specified encryption key is not present in the encryption key parameters.0
Attributes
- Section
8.3.2: Strong authentication for users and administrators is established and managed.
- Service
Core
8.3.2.19Checks if the Kubernetes Secrets are encrypted at rest and checks their status. The rule is COMPLIANT if encryption is enabled or enabling.1
Attributes
- Section
8.3.2: Strong authentication for users and administrators is established and managed.
- Service
Core
8.3.2.20Checks if Kubernetes Persistent Volumes (PV) have encryption enabled by default. The rule is NON_COMPLIANT if encryption is not enabled.0
Attributes
- Section
8.3.2: Strong authentication for users and administrators is established and managed.
- Service
Core
8.3.2.21Checks if Kubernetes secrets are passed as container environment variables. The rule is NON_COMPLIANT if 1 or more environment variable keys match a key listed in the 'secretKeys' parameter (excluding environment variables from other locations such as ConfigMaps or Persistent Volumes).1
Attributes
- Section
8.3.2: Strong authentication for users and administrators is established and managed.
- Service
Core
8.3.2.22Checks if a PersistentVolume (PV) is configured to encrypt the storage using Kubernetes secrets. The rule is NON_COMPLIANT if the 'encrypted' field is set to false in the PersistentVolume spec or if the 'secretRef' field does not match the expected secret reference for encryption.0
Attributes
- Section
8.3.2: Strong authentication for users and administrators is established and managed.
- Service
PersistentVolume
8.3.2.23Checks if Kubernetes clusters are configured to have secrets encrypted using a specified encryption provider. The rule is NON_COMPLIANT if a Kubernetes cluster does not have an encryption configuration defined or if the encryption configuration does not include secrets as a resource.1
Attributes
- Section
8.3.2: Strong authentication for users and administrators is established and managed.
- Service
API Server
8.3.2.25Checks if Kubernetes secrets have encryption enabled at rest. The rule is NON_COMPLIANT for a Kubernetes secret if 'encryptionProvider' is disabled or if the KMS key ARN does not match the defined KMS configuration.1
Attributes
- Section
8.3.2: Strong authentication for users and administrators is established and managed.
- Service
API Server
8.3.2.27Checks if Kubernetes clusters have encryption at rest configuration enabled in etcd. The rule is NON_COMPLIANT if the encryption at rest configuration for etcd is not enabled.1
Attributes
- Section
8.3.2: Strong authentication for users and administrators is established and managed.
- Service
ETCD
8.3.2.28Check if the OpenSearch Service nodes are encrypted end to end. The rule is NON_COMPLIANT if the node-to-node encryption is not enabled on the domain.0
Attributes
- Section
8.3.2: Strong authentication for users and administrators is established and managed.
- Service
OpenSearch Service
8.3.2.29Checks if Kubernetes Ingress resources are configured to use TLS certificates provided by a certificate manager. To use this rule, ensure that the Ingress resource has TLS settings defined. This rule only applies to Ingress resources and does not apply to other service types like NodePort or LoadBalancer services.1
Attributes
- Section
8.3.2: Strong authentication for users and administrators is established and managed.
- Service
API Server
8.3.2.30Checks whether your Kubernetes Ingress resources are using a custom TLS secret for SSL termination. The rule is only applicable if there are Ingress resources configured with SSL/TLS termination.0
Attributes
- Section
8.3.2: Strong authentication for users and administrators is established and managed.
- Service
API Server
8.3.2.31Checks if the Kubernetes Ingress controller is using a predefined TLS configuration. The rule is NON_COMPLIANT if the Ingress resource's TLS configuration does not match the specified 'predefinedPolicyName'.0
Attributes
- Section
8.3.2: Strong authentication for users and administrators is established and managed.
- Service
API Server
8.3.2.32Checks if the Kubernetes Service is configured with HTTPS or TLS for secure communication. The rule is NON_COMPLIANT if a service is not configured with TLS or HTTPS.1
Attributes
- Section
8.3.2: Strong authentication for users and administrators is established and managed.
- Service
API Server
8.3.2.33Checks if Kubernetes clusters have RBAC (Role-Based Access Control) configured. The rule is NON_COMPLIANT if the cluster does not have RBAC enabled or if the configured roles do not satisfy the specified access control parameters.1
Attributes
- Section
8.3.2: Strong authentication for users and administrators is established and managed.
- Service
API Server
8.3.2.34Checks if attached Kubernetes Persistent Volumes (PVs) are encrypted and optionally are encrypted with a specified KMS key. The rule is NON_COMPLIANT if attached PVs are unencrypted or are encrypted with a KMS key not in the supplied parameters.0
Attributes
- Section
8.3.2: Strong authentication for users and administrators is established and managed.
- Service
Core
8.3.2.35Checks if Kubernetes secrets used in a Kinesis-like streaming application are encrypted at rest. The rule is NON_COMPLIANT for a Kubernetes secret if 'encryption' is not configured.0
Attributes
- Section
8.3.2: Strong authentication for users and administrators is established and managed.
- Service
Core
8.3.2.36Checks if a Kubernetes cluster's communication between pods is encrypted using TLS. The rule is NON_COMPLIANT if plain text communication is enabled for network traffic between pod-to-pod connections.0
Attributes
- Section
8.3.2: Strong authentication for users and administrators is established and managed.
- Service
Core
8.3.2.37Checks if storage encryption is enabled for your Kubernetes Persistent Volumes. The rule is NON_COMPLIANT if storage encryption is not enabled.0
Attributes
- Section
8.3.2: Strong authentication for users and administrators is established and managed.
- Service
Core
8.3.2.38Checks if a Kubernetes cluster has Persistent Volume Claims (PVCs) that are encrypted. The rule is NON_COMPLIANT if any PVC in the cluster does not have encryption enabled.1
Attributes
- Section
8.3.2: Strong authentication for users and administrators is established and managed.
- Service
RBAC
8.3.2.39Checks if Kubernetes clusters have encryption at rest enabled for etcd. The rule is NON_COMPLIANT if the etcd encryption is not configured properly.1
Attributes
- Section
8.3.2: Strong authentication for users and administrators is established and managed.
- Service
ETCD
8.3.2.40Checks whether connections to OpenSearch domains in Kubernetes are using HTTPS. The rule is NON_COMPLIANT if the OpenSearch cluster's 'http.ssl.enabled' is not 'true' or is 'true' and 'http.ssl.transport.type' is not set to 'TLS'.0
Attributes
- Section
8.3.2: Strong authentication for users and administrators is established and managed.
- Service
OpenSearch
8.3.2.41Check if Kubernetes Cluster nodes are encrypted end to end. The rule is NON_COMPLIANT if the etcd encryption is not enabled on the cluster.1
Attributes
- Section
8.3.2: Strong authentication for users and administrators is established and managed.
- Service
ETCD
8.3.2.42Checks if a Kubernetes Persistent Volume (PV) is encrypted at rest. The rule is NON_COMPLIANT if a Persistent Volume is not encrypted at rest.1
Attributes
- Section
8.3.2: Strong authentication for users and administrators is established and managed.
- Service
RBAC
8.3.2.43Checks if Kubernetes Persistent Volume Claims (PVCs) are using encrypted Persistent Volumes (PVs). The rule is NON_COMPLIANT if the Persistent Volumes are not encrypted.1
Attributes
- Section
8.3.2: Strong authentication for users and administrators is established and managed.
- Service
RBAC
8.3.2.44Checks if storage encryption is enabled for your Kubernetes Persistent Volume Claims (PVCs). The rule is NON_COMPLIANT if storage encryption is not enabled.1
Attributes
- Section
8.3.2: Strong authentication for users and administrators is established and managed.
- Service
RBAC
8.3.2.45Checks if Kubernetes clusters have the specified security settings. The rule is NON_COMPLIANT if the Kubernetes cluster is not encrypted or encrypted with another key, or if a cluster does not have audit logging enabled.0
Attributes
- Section
8.3.2: Strong authentication for users and administrators is established and managed.
- Service
Core
8.3.2.46Checks if Kubernetes clusters are using a specified encryption provider for secrets. The rule is COMPLIANT if encryption is enabled and the cluster is using the specified encryption provider key. The rule is NON_COMPLIANT if the cluster is not using encryption or using a different key.1
Attributes
- Section
8.3.2: Strong authentication for users and administrators is established and managed.
- Service
API Server
8.3.2.47Checks if Kubernetes clusters require TLS/SSL encryption for API server connections. The rule is NON_COMPLIANT if the API server's TLS configuration is not enabled or improperly configured.1
Attributes
- Section
8.3.2: Strong authentication for users and administrators is established and managed.
- Service
API Server
8.3.2.48Checks if your Kubernetes persistent volume (PV) is bound to a persistent volume claim (PVC) that ensures encryption at rest is enabled or if there are specific policies that deny access to unencrypted volumes. The rule is NON_COMPLIANT if your persistent volume does not have encryption enabled by default.1
Attributes
- Section
8.3.2: Strong authentication for users and administrators is established and managed.
- Service
RBAC
8.3.2.49Checks if Kubernetes services have network policies that enforce TLS for communication. The rule is NON_COMPLIANT if any service allows unencrypted HTTP traffic.1
Attributes
- Section
8.3.2: Strong authentication for users and administrators is established and managed.
- Service
API Server
8.3.2.50Checks if the persistent volumes (PVs) in Kubernetes are encrypted using a specific encryption provider. The rule is NON_COMPLIANT if the persistent volume is not encrypted.1
Attributes
- Section
8.3.2: Strong authentication for users and administrators is established and managed.
- Service
RBAC
8.3.2.51Checks if Kubernetes Secrets are used to store sensitive information for a specific deployment. The rule is NON_COMPLIANT if a Secret for storing sensitive data (e.g., passwords, API keys) is not specified in the deployment configuration.1
Attributes
- Section
8.3.2: Strong authentication for users and administrators is established and managed.
- Service
Core
8.3.2.52Checks if a Kubernetes secret is configured for a pod. The rule is NON_COMPLIANT if 'imagePullSecrets' is not specified for the pod.1
Attributes
- Section
8.3.2: Strong authentication for users and administrators is established and managed.
- Service
Core
8.3.2.53Checks if all Kubernetes secrets are encrypted using an encryption provider for Kubernetes, either a customer-managed key or the default key provided by Kubernetes. The rule is COMPLIANT if a secret is encrypted using a customer-managed key. This rule is NON_COMPLIANT if a secret is encrypted using the default key.1
Attributes
- Section
8.3.2: Strong authentication for users and administrators is established and managed.
- Service
Core
8.3.2.54Checks if Kubernetes Secrets are encrypted in transit and at rest. The rule is NON_COMPLIANT if a Secret is not encrypted. Optionally, specify the encryption configuration used for the Secrets.1
Attributes
- Section
8.3.2: Strong authentication for users and administrators is established and managed.
- Service
Core
8.3.4: Strong authentication for users and administrators is established and managed.2217
8.3.4.1Checks if a Kubernetes cluster is part of a specific organization when using a multi-tenant structure. The rule is NON_COMPLIANT if a namespace (representing an account) is not part of the defined organization or if the organization master namespace ID does not match the rule parameter MasterNamespaceId.0
Attributes
- Section
8.3.4: Strong authentication for users and administrators is established and managed.
- Service
Core
8.3.4.2Checks if a Kubernetes cluster has Role-Based Access Control (RBAC) policies that prevent the deletion of persistent volume claims. The rule is NON_COMPLIANT if the cluster does not have appropriate Role or ClusterRole bindings that include 'deny' rules for the 'delete' action on PersistentVolumeClaims.1
Attributes
- Section
8.3.4: Strong authentication for users and administrators is established and managed.
- Service
RBAC
8.3.4.3Checks if a Kubernetes Pod has a Service Account attached to it. The rule is NON_COMPLIANT if no Service Account is associated with the Pod.1
Attributes
- Section
8.3.4: Strong authentication for users and administrators is established and managed.
- Service
API Server
8.3.4.4Checks if Kubernetes Pods have read-only access to their root filesystems. The rule is NON_COMPLIANT if the readOnlyRootFilesystem parameter in the Pod's securityContext is set to 'false'.1
Attributes
- Section
8.3.4: Strong authentication for users and administrators is established and managed.
- Service
Core
8.3.4.5Checks if the Kubernetes Role-Based Access Control (RBAC) policies that you create do not allow unauthorized actions on Kubernetes secrets. The rule is NON_COMPLIANT if any unauthorized action is permitted on Kubernetes secrets by the managed RBAC policy.1
Attributes
- Section
8.3.4: Strong authentication for users and administrators is established and managed.
- Service
RBAC
8.3.4.6Checks if the RBAC (Role-Based Access Control) policies attached to your Kubernetes users, service accounts, and roles do not allow blocked actions on all Kubernetes resources. The rule is NON_COMPLIANT if any blocked action is allowed on all Kubernetes resources in an RBAC policy.1
Attributes
- Section
8.3.4: Strong authentication for users and administrators is established and managed.
- Service
API Server
8.3.4.7Checks if the Pod Security Policies feature is not in use. The rule is NON_COMPLIANT if a Kubernetes user, role, or group has any inline Pod Security Policies defined.1
Attributes
- Section
8.3.4: Strong authentication for users and administrators is established and managed.
- Service
API Server
8.3.4.8Checks in each Kubernetes Role or ClusterRole resource, if a RoleBinding or ClusterRoleBinding in the input parameter is applied to the Role or ClusterRole resource. The rule is NON_COMPLIANT if the RoleBinding or ClusterRoleBinding is applied to the Role or ClusterRole resource.1
Attributes
- Section
8.3.4: Strong authentication for users and administrators is established and managed.
- Service
RBAC
8.3.4.9Checks whether the Role ARN is attached to a Kubernetes ServiceAccount, or a RoleBinding or ClusterRoleBinding with one or more ServiceAccounts, or a Pod that assumes that ServiceAccount.0
Attributes
- Section
8.3.4: Strong authentication for users and administrators is established and managed.
- Service
Core
8.3.4.10Checks if Kubernetes Role or ClusterRole resources have rules that grant permissions to all verbs on all resources. The rule is NON_COMPLIANT if any Role or ClusterRole has a rule with 'verbs': ['*'] over 'resources': ['*'].1
Attributes
- Section
8.3.4: Strong authentication for users and administrators is established and managed.
- Service
RBAC
8.3.4.11Checks if Kubernetes Role or ClusterRole policies that you create grant permissions to all actions on individual Kubernetes resources. The rule is NON_COMPLIANT if any customer managed Role or ClusterRole allows full access to at least 1 Kubernetes resource.1
Attributes
- Section
8.3.4: Strong authentication for users and administrators is established and managed.
- Service
RBAC
8.3.4.12Checks if all specified Kubernetes RoleBindings are attached to the Kubernetes ServiceAccount. The rule is NON_COMPLIANT if a RoleBinding is not attached to the ServiceAccount.0
Attributes
- Section
8.3.4: Strong authentication for users and administrators is established and managed.
- Service
Role-Based Access Control (RBAC)
8.3.4.13Checks if none of your Kubernetes ServiceAccounts have direct RoleBindings or ClusterRoleBindings attached. ServiceAccounts must inherit permissions from Roles or ClusterRoles. The rule is NON_COMPLIANT if there is at least one RoleBinding or ClusterRoleBinding that is directly attached to the ServiceAccount.1
Attributes
- Section
8.3.4: Strong authentication for users and administrators is established and managed.
- Service
API Server
8.3.4.14Checks if a Kubernetes cluster has Role-Based Access Control (RBAC) enabled. The rule is NON_COMPLIANT if a Kubernetes cluster does not have RBAC enabled.1
Attributes
- Section
8.3.4: Strong authentication for users and administrators is established and managed.
- Service
API Server
8.3.4.15Checks if Kubernetes clusters have Role-Based Access Control (RBAC) enabled. The rule is NON_COMPLIANT if RBAC is not enabled for the Kubernetes cluster.1
Attributes
- Section
8.3.4: Strong authentication for users and administrators is established and managed.
- Service
API Server
8.3.4.16Checks if a Kubernetes pod has Role-Based Access Control (RBAC) enabled. The rule is NON_COMPLIANT if a Kubernetes pod does not have RBAC enabled.1
Attributes
- Section
8.3.4: Strong authentication for users and administrators is established and managed.
- Service
RBAC
8.3.4.17Checks if a Kubernetes Pod has Role-Based Access Control (RBAC) enabled for authentication and authorization. The rule is NON_COMPLIANT if a Pod does not have RBAC enabled.1
Attributes
- Section
8.3.4: Strong authentication for users and administrators is established and managed.
- Service
RBAC
8.3.4.18Checks if Kubernetes Persistent Volumes (PVs) allow user permissions through access control policies. The rule is NON_COMPLIANT if access control is configured for user access in Kubernetes Persistent Volumes.1
Attributes
- Section
8.3.4: Strong authentication for users and administrators is established and managed.
- Service
RBAC
8.3.4.19Checks if a Kubernetes Role or ClusterRole does not allow blocklisted permissions on resources for subjects from other namespaces. For example, the rule checks that the Role or ClusterRole does not allow another namespace to perform any 'get', 'list', or 'delete' actions on any pod resources. The rule is NON_COMPLIANT if any blocklisted actions are allowed by the Kubernetes Role or ClusterRole.0
Attributes
- Section
8.3.4: Strong authentication for users and administrators is established and managed.
- Service
Core
8.3.4.20Verifies that access to the Kubernetes PersistentVolume (PV) is restricted by any of the Kubernetes principals, service accounts, namespaces, or network policies that you define. The rule is COMPLIANT if a role or cluster role binding is not present that grants access to the PersistentVolume.1
Attributes
- Section
8.3.4: Strong authentication for users and administrators is established and managed.
- Service
RBAC
8.3.4.21Checks if your Kubernetes PersistentVolumePolicies do not allow other inter-namespace permissions than the control PersistentVolumePolicy that you provide.1
Attributes
- Section
8.3.4: Strong authentication for users and administrators is established and managed.
- Service
RBAC
8.3.4.22Checks if the Security Response Team (SRT) can access your Kubernetes cluster. The rule is NON_COMPLIANT if Kubernetes RBAC is enabled but the role for SRT access is not configured.0
Attributes
- Section
8.3.4: Strong authentication for users and administrators is established and managed.
- Service
RBAC (Role-Based Access Control)
8.3.5: Strong authentication for users and administrators is established and managed.40
8.3.5.1Checks if Kubernetes service account tokens are rotated within a specified time period. The rule is NON_COMPLIANT if tokens are not rotated within the specified time period. The default value is 90 days.0
Attributes
- Section
8.3.5: Strong authentication for users and administrators is established and managed.
- Service
Core
8.3.5.2Checks if Kubernetes secrets have automatic rotation enabled for their associated secrets. If a max rotation frequency is specified, it compares the configuration of the secret's rotation against this value. The rule is NON_COMPLIANT if the secret is not set to rotate automatically or if the defined rotation frequency exceeds the specified maximum.0
Attributes
- Section
8.3.5: Strong authentication for users and administrators is established and managed.
- Service
Core
8.3.5.3Checks if Kubernetes secrets are rotated successfully according to the defined rotation schedule. The system calculates the date the rotation should happen. The rule is NON_COMPLIANT if the date passes and the secret isn't rotated.0
Attributes
- Section
8.3.5: Strong authentication for users and administrators is established and managed.
- Service
Kubernetes Secrets Management
8.3.5.4Checks if Kubernetes Secrets have been updated in the past specified number of days. The rule is NON_COMPLIANT if a secret has not been updated for more than maxDaysSinceUpdate number of days. The default value is 90 days.0
Attributes
- Section
8.3.5: Strong authentication for users and administrators is established and managed.
- Service
Core
8.3.6: Strong authentication for users and administrators is established and managed.11
8.3.6.1Checks if the Kubernetes secrets for user authentication meet the specified requirements indicated in the parameters. The rule is NON_COMPLIANT if the secrets do not meet the specified requirements.1
Attributes
- Section
8.3.6: Strong authentication for users and administrators is established and managed.
- Service
RBAC
8.3.7: Strong authentication for users and administrators is established and managed.40
8.3.7.1Checks if active Kubernetes secrets storing sensitive access credentials are refreshed or created within a specified retention period. The rule is NON_COMPLIANT if secrets are not rotated within the specified time period. The default value is 90 days.0
Attributes
- Section
8.3.7: Strong authentication for users and administrators is established and managed.
- Service
RBAC (Role-Based Access Control)
8.3.7.2Checks if Kubernetes Secrets have automated rotation policies applied. The rule assesses whether secrets are configured for rotation and verifies if the rotation frequency aligns with an optional maximumAllowedRotationFrequency parameter. The rule is NON_COMPLIANT if a secret is not scheduled for rotation or if its rotation frequency exceeds the specified maximumAllowedRotationFrequency.0
Attributes
- Section
8.3.7: Strong authentication for users and administrators is established and managed.
- Service
RBAC (Role-Based Access Control)
8.3.7.3Checks if Kubernetes Secrets are updated successfully according to the defined update schedule. Kubernetes calculates the date the update should happen. The rule is NON_COMPLIANT if the date passes and the secret isn't updated.0
Attributes
- Section
8.3.7: Strong authentication for users and administrators is established and managed.
- Service
RBAC (Role-Based Access Control)
8.3.7.4Checks if Kubernetes Secrets have been updated in the past specified number of days. The rule is NON_COMPLIANT if a Secret has not been updated for more than maxDaysSinceUpdate number of days. The default value is 90 days.0
Attributes
- Section
8.3.7: Strong authentication for users and administrators is established and managed.
- Service
RBAC (Role-Based Access Control)
8.3.9: Strong authentication for users and administrators is established and managed.40
8.3.9.1Checks if Kubernetes service accounts have associated tokens that are rotated (changed) within the number of days specified in maxTokenAge. The rule is NON_COMPLIANT if tokens are not rotated within the specified time period. The default value is 90 days.0
Attributes
- Section
8.3.9: Strong authentication for users and administrators is established and managed.
- Service
Kubernetes Service Accounts
8.3.9.2Checks if Kubernetes Secret has a rotation policy enabled. The rule also checks an optional maxRotationFrequency parameter. If the parameter is specified, the rotation frequency of the secret is compared with the maximum allowed frequency. The rule is NON_COMPLIANT if the secret is not scheduled for rotation. The rule is also NON_COMPLIANT if the rotation frequency is higher than the specified maxRotationFrequency parameter.0
Attributes
- Section
8.3.9: Strong authentication for users and administrators is established and managed.
- Service
Core
8.3.9.3Checks if Kubernetes Secrets have been updated successfully according to a defined update schedule. The system calculates the date the update should happen. The rule is NON_COMPLIANT if the date passes and the secret isn't updated.0
Attributes
- Section
8.3.9: Strong authentication for users and administrators is established and managed.
- Service
RBAC (Role-Based Access Control)
8.3.9.4Checks if Kubernetes Secrets have been updated (rotated) in the past specified number of days. The rule is NON_COMPLIANT if a secret has not been updated for more than maxDaysSinceRotation number of days. The default value is 90 days.0
Attributes
- Section
8.3.9: Strong authentication for users and administrators is established and managed.
- Service
Core
8.3.10.1: Strong authentication for users and administrators is established and managed.40
8.3.10.1.1Checks if Kubernetes secrets used for access tokens are rotated (changed) within the number of days specified in maxTokenAge. The rule is NON_COMPLIANT if access tokens are not rotated within the specified time period. The default value is 90 days.0
Attributes
- Section
8.3.10.1: Strong authentication for users and administrators is established and managed.
- Service
Core
8.3.10.1.2Checks if a Kubernetes Secret has a defined expiration time or automated rotation mechanism. The rule also checks an optional maxAllowedRotationFrequency parameter. If specified, the rotation frequency of the Secret is compared with this maximum allowed frequency. The rule is NON_COMPLIANT if the Secret does not have any rotation scheduled or if the frequency exceeds the specified maximum allowed value.0
Attributes
- Section
8.3.10.1: Strong authentication for users and administrators is established and managed.
- Service
RBAC (Role-Based Access Control)
8.3.10.1.3Checks if Kubernetes Secrets have been updated successfully according to a defined rotation schedule. The system calculates the date the rotation should occur, and the rule is NON_COMPLIANT if the date passes and the secret hasn't been updated.0
Attributes
- Section
8.3.10.1: Strong authentication for users and administrators is established and managed.
- Service
Kubernetes Secrets Management
8.3.10.1.4Checks if Kubernetes Secrets have been updated (rotated) in the past specified number of days. The rule is NON_COMPLIANT if a secret has not been updated for more than maxDaysSinceUpdate number of days. The default value is 90 days.0
Attributes
- Section
8.3.10.1: Strong authentication for users and administrators is established and managed.
- Service
RBAC (Role-Based Access Control)
8.3.11: Strong authentication for users and administrators is established and managed.53
8.3.11.1Checks if running Kubernetes Pods are launched using Secrets for sensitive data. The rule is NON_COMPLIANT if a running Pod is launched with sensitive data hardcoded in the Pod specifications instead of being stored in Kubernetes Secrets.1
Attributes
- Section
8.3.11: Strong authentication for users and administrators is established and managed.
- Service
Core
8.3.11.2Checks whether Kubernetes groups have at least one user associated with them.0
Attributes
- Section
8.3.11: Strong authentication for users and administrators is established and managed.
- Service
Core
8.3.11.3Checks whether the Role ARN is attached to a Kubernetes ServiceAccount, or a RoleBinding with one or more ServiceAccounts, or a ClusterRole with one or more trusted entities.0
Attributes
- Section
8.3.11: Strong authentication for users and administrators is established and managed.
- Service
Core
8.3.11.4Checks if the Kubernetes cluster has a Role or ClusterRoleBinding that grants 'root' access. The rule is COMPLIANT if no such Role or ClusterRoleBinding exists. Otherwise, NON_COMPLIANT.1
Attributes
- Section
8.3.11: Strong authentication for users and administrators is established and managed.
- Service
Core
8.3.11.5Verifies if Kubernetes users have access to at least one RoleBinding or ClusterRoleBinding.1
Attributes
- Section
8.3.11: Strong authentication for users and administrators is established and managed.
- Service
RBAC
8.4.1: Multi-factor authentication (MFA) is implemented to secure access into the CDE.53
8.4.1.1Checks if Kubernetes users (specifically those with RBAC roles) have multi-factor authentication (MFA) enabled. The rule is NON_COMPLIANT if MFA is not enabled for at least one user with access to the Kubernetes cluster.0
Attributes
- Section
8.4.1: Multi-factor authentication (MFA) is implemented to secure access into the CDE.
- Service
Core
8.4.1.2Checks if Kubernetes RBAC (Role-Based Access Control) is configured to ensure that all users accessing the Kubernetes cluster via the dashboard or CLI have multi-factor authentication (MFA) enabled for their sessions. The rule is COMPLIANT if MFA is enforced for all users.1
Attributes
- Section
8.4.1: Multi-factor authentication (MFA) is implemented to secure access into the CDE.
- Service
API Server
8.4.1.3Checks if your Kubernetes cluster has multi-factor authentication (MFA) enabled for securing access to the Kubernetes API server. The rule is NON_COMPLIANT if any users can access the API server without MFA.1
Attributes
- Section
8.4.1: Multi-factor authentication (MFA) is implemented to secure access into the CDE.
- Service
API Server
8.4.1.4Checks if the Kubernetes cluster's admin user requires multi-factor authentication for access. The rule is NON_COMPLIANT if the Kubernetes admin user does not have multi-factor authentication (MFA) enabled.0
Attributes
- Section
8.4.1: Multi-factor authentication (MFA) is implemented to secure access into the CDE.
- Service
Core
8.4.1.5Checks if the equivalent of MFA Delete is enabled in the Kubernetes Persistent Volume configurations. The rule is NON_COMPLIANT if persistent volume protection mechanisms, such as Retain Reclaim Policy or Backup strategies, are not in place.1
Attributes
- Section
8.4.1: Multi-factor authentication (MFA) is implemented to secure access into the CDE.
- Service
RBAC
8.4.2: Multi-factor authentication (MFA) is implemented to secure access into the CDE.43
8.4.2.1Checks if Kubernetes users have multi-factor authentication (MFA) enabled through API server configuration and RBAC policies. The rule is NON_COMPLIANT if MFA is not enabled for any user accessing the Kubernetes cluster.1
Attributes
- Section
8.4.2: Multi-factor authentication (MFA) is implemented to secure access into the CDE.
- Service
API Server
8.4.2.2Checks if Kubernetes Role-Based Access Control (RBAC) is enforced for all users accessing the Kubernetes API server. The rule is COMPLIANT if RBAC is enabled and properly configured.1
Attributes
- Section
8.4.2: Multi-factor authentication (MFA) is implemented to secure access into the CDE.
- Service
API Server
8.4.2.3Checks if your Kubernetes cluster is configured to require multi-factor authentication (MFA) for users accessing the cluster with cluster-admin role. The rule is NON_COMPLIANT if any roles are allowed to access the cluster without MFA.0
Attributes
- Section
8.4.2: Multi-factor authentication (MFA) is implemented to secure access into the CDE.
- Service
Core
8.4.2.4Checks if the Kubernetes cluster's service account that has admin privileges requires multi-factor authentication for access. The rule is NON_COMPLIANT if the service account does not have multifactor authentication (MFA) configured.1
Attributes
- Section
8.4.2: Multi-factor authentication (MFA) is implemented to secure access into the CDE.
- Service
API Server
8.4.3: Multi-factor authentication (MFA) is implemented to secure access into the CDE.52
8.4.3.1Checks if Kubernetes users have multi-factor authentication (MFA) enabled. The rule is NON_COMPLIANT if MFA is not enabled for at least one Kubernetes user.0
Attributes
- Section
8.4.3: Multi-factor authentication (MFA) is implemented to secure access into the CDE.
- Service
Core
8.4.3.2Checks if Kubernetes Role-Based Access Control (RBAC) is enabled for all Kubernetes users that access the cluster through a service account. The rule is COMPLIANT if RBAC is enabled.1
Attributes
- Section
8.4.3: Multi-factor authentication (MFA) is implemented to secure access into the CDE.
- Service
API Server
8.4.3.3Checks if your Kubernetes cluster is configured to enforce role-based access control (RBAC) for sensitive operations. The rule is NON_COMPLIANT if any user or service account can perform actions with elevated privileges without proper RBAC policies in place.1
Attributes
- Section
8.4.3: Multi-factor authentication (MFA) is implemented to secure access into the CDE.
- Service
API Server
8.4.3.4Checks if the Kubernetes cluster administrator requires multi-factor authentication (MFA) for console access. The rule is NON_COMPLIANT if the Kubernetes admin user does not have multi-factor authentication enabled.0
Attributes
- Section
8.4.3: Multi-factor authentication (MFA) is implemented to secure access into the CDE.
- Service
Core
8.4.3.5Checks if the Object Lock feature is enabled in the Kubernetes StorageClass definition. The rule is NON_COMPLIANT if Object Lock is not enabled.0
Attributes
- Section
8.4.3: Multi-factor authentication (MFA) is implemented to secure access into the CDE.
- Service
Kubernetes Storage
8.6.3: Use of application and system accounts and associated authentication factors is strictly managed.51
8.6.3.1Checks if Kubernetes Service Accounts have their associated tokens rotated (changed) within the number of days specified in maxTokenAge. The rule is NON_COMPLIANT if tokens are not rotated within the specified time period. The default value is 90 days.0
Attributes
- Section
8.6.3: Use of application and system accounts and associated authentication factors is strictly managed.
- Service
Core
8.6.3.2Checks if the Kubernetes secrets used for storing sensitive data, such as passwords, meet the specified security requirements indicated in the parameters. The rule is NON_COMPLIANT if the secrets do not meet the specified security standards.1
Attributes
- Section
8.6.3: Use of application and system accounts and associated authentication factors is strictly managed.
- Service
RBAC
8.6.3.3Checks if a Kubernetes Secret has a defined rotation policy. The rule also verifies an optional maxRotationFrequency parameter. If this parameter is specified, the rotation frequency of the Secret is compared with the maximum allowed frequency. The rule is NON_COMPLIANT if the Secret is not scheduled for rotation. The rule is also NON_COMPLIANT if the rotation frequency exceeds the value specified in maxRotationFrequency.0
Attributes
- Section
8.6.3: Use of application and system accounts and associated authentication factors is strictly managed.
- Service
Kubernetes Secrets Management
8.6.3.4Checks if Kubernetes secrets are updated successfully according to the rotation schedule. If the scheduled update date passes and the secret isn't updated, the rule is considered NON_COMPLIANT.0
Attributes
- Section
8.6.3: Use of application and system accounts and associated authentication factors is strictly managed.
- Service
RBAC (Role-Based Access Control)
8.6.3.5Checks if Kubernetes Secrets have been updated (rotated) in the past specified number of days. The rule is NON_COMPLIANT if a secret has not been updated for more than maxDaysSinceUpdate number of days. The default value is 90 days.0
Attributes
- Section
8.6.3: Use of application and system accounts and associated authentication factors is strictly managed.
- Service
RBAC (Role-Based Access Control)
10.2.1: Audit logs are implemented to support the detection of anomalies and suspicious activity, and the forensic analysis of events.278
10.2.1.1Checks if Kubernetes Ingress resources have access logging enabled. The rule is NON_COMPLIANT if 'accessLog' annotation is not present in Ingress configuration.0
Attributes
- Section
10.2.1: Audit logs are implemented to support the detection of anomalies and suspicious activity, and the forensic analysis of events.
- Service
API Server
10.2.1.2Checks if all methods in Kubernetes Ingress resources have logging enabled. The rule is NON_COMPLIANT if logging is not enabled or if the log level is neither ERROR nor INFO.0
Attributes
- Section
10.2.1: Audit logs are implemented to support the detection of anomalies and suspicious activity, and the forensic analysis of events.
- Service
API Server
10.2.1.3Checks if OpenTelemetry tracing is enabled on Kubernetes services. The rule is COMPLIANT if OpenTelemetry tracing is enabled and NON_COMPLIANT otherwise.0
Attributes
- Section
10.2.1: Audit logs are implemented to support the detection of anomalies and suspicious activity, and the forensic analysis of events.
- Service
Core
10.2.1.4Checks if a Kubernetes API server has audit logging enabled. The rule is NON_COMPLIANT if audit logging is not enabled, or the audit policy does not include both 'metadata' and 'requestBodies' logs.1
Attributes
- Section
10.2.1: Audit logs are implemented to support the detection of anomalies and suspicious activity, and the forensic analysis of events.
- Service
API Server
10.2.1.5Checks if Kubernetes Ingress controllers are configured with appropriate desynchronization mitigation settings as per user-defined requirements. The rule is NON_COMPLIANT if the Ingress desync mitigation settings do not match user-defined configurations.0
Attributes
- Section
10.2.1: Audit logs are implemented to support the detection of anomalies and suspicious activity, and the forensic analysis of events.
- Service
API Server
10.2.1.6Checks if Kubernetes Ingress resources are configured to log access details. The rule is NON_COMPLIANT if an Ingress resource does not have logging enabled.0
Attributes
- Section
10.2.1: Audit logs are implemented to support the detection of anomalies and suspicious activity, and the forensic analysis of events.
- Service
API Server
10.2.1.7Checks if at least one Kubernetes Audit Policy is logging access events for all Pods in the cluster. The rule is NON_COMPLIANT if there are no audit records for Pod access events.1
Attributes
- Section
10.2.1: Audit logs are implemented to support the detection of anomalies and suspicious activity, and the forensic analysis of events.
- Service
API Server
10.2.1.9Checks if a Kubernetes Pod has at least one logging mechanism enabled. The rule is NON_COMPLIANT if the status of all present logging configurations (such as logging to stdout/stderr or using a sidecar for logging) is set to 'DISABLED'.0
Attributes
- Section
10.2.1: Audit logs are implemented to support the detection of anomalies and suspicious activity, and the forensic analysis of events.
- Service
Core
10.2.1.10Checks if logging is enabled with a valid severity level for Kubernetes pod events of a target application. The rule is NON_COMPLIANT if logging is not enabled or pod logging of a target application has a severity level that is not valid.0
Attributes
- Section
10.2.1: Audit logs are implemented to support the detection of anomalies and suspicious activity, and the forensic analysis of events.
- Service
Core
10.2.1.12Checks if Kubernetes cluster has logging for connections to services enabled. The rule is NON_COMPLIANT if 'service.spec.sessionAffinity' is not set to 'ClientIP'.0
Attributes
- Section
10.2.1: Audit logs are implemented to support the detection of anomalies and suspicious activity, and the forensic analysis of events.
- Service
Core
10.2.1.13Checks if the logging configuration is set on active Kubernetes Pods. This rule is NON_COMPLIANT if an active Pod does not have logging configuration defined or the value for the logging configuration is null in at least one container within the Pod.0
Attributes
- Section
10.2.1: Audit logs are implemented to support the detection of anomalies and suspicious activity, and the forensic analysis of events.
- Service
Core
10.2.1.14Checks if a Kubernetes cluster is configured with logging enabled. The rule is NON_COMPLIANT if logging for the Kubernetes cluster is not enabled for all log types such as audit logs, application logs, and system logs.1
Attributes
- Section
10.2.1: Audit logs are implemented to support the detection of anomalies and suspicious activity, and the forensic analysis of events.
- Service
API Server
10.2.1.15Checks if Kubernetes applications are configured to send logs to a logging solution like Fluentd or ELK Stack. The rule is NON_COMPLIANT if the logging configuration is not set up properly.0
Attributes
- Section
10.2.1: Audit logs are implemented to support the detection of anomalies and suspicious activity, and the forensic analysis of events.
- Service
Core
10.2.1.16Checks if the Kubernetes LoadBalancer service has logging enabled. The rule is NON_COMPLIANT if the service annotations for external-dns are not set correctly or if the S3 bucket for logs is not properly configured.0
Attributes
- Section
10.2.1: Audit logs are implemented to support the detection of anomalies and suspicious activity, and the forensic analysis of events.
- Service
Scheduler
10.2.1.17Checks if Kubernetes clusters have audit logging enabled. The rule is NON_COMPLIANT if a cluster does not have audit logging enabled.1
Attributes
- Section
10.2.1: Audit logs are implemented to support the detection of anomalies and suspicious activity, and the forensic analysis of events.
- Service
API Server
10.2.1.18Checks if a Kubernetes cluster has auditing enabled. The rule is NON_COMPLIANT if auditing is not configured properly.1
Attributes
- Section
10.2.1: Audit logs are implemented to support the detection of anomalies and suspicious activity, and the forensic analysis of events.
- Service
API Server
10.2.1.20Checks if a Kubernetes cluster has logging enabled for audit logs. The rule is NON_COMPLIANT if the Kubernetes cluster does not have logging enabled for audit logs.1
Attributes
- Section
10.2.1: Audit logs are implemented to support the detection of anomalies and suspicious activity, and the forensic analysis of events.
- Service
API Server
10.2.1.21Checks if Kubernetes Network Policies have logging enabled. The rule is NON_COMPLIANT if a logging type is not configured. You can specify which logging type you want the rule to check.0
Attributes
- Section
10.2.1: Audit logs are implemented to support the detection of anomalies and suspicious activity, and the forensic analysis of events.
- Service
Core
10.2.1.23Checks if respective logs of Kubernetes Pods are enabled. The rule is NON_COMPLIANT if any logs related to the application are not enabled.0
Attributes
- Section
10.2.1: Audit logs are implemented to support the detection of anomalies and suspicious activity, and the forensic analysis of events.
- Service
Core
10.2.1.24Checks if Kubernetes Pods are logging events to a specific logging service. The rule is NON_COMPLIANT if logging is not enabled for a Pod or if the 'logDestination' parameter is provided but the logging service does not match.0
Attributes
- Section
10.2.1: Audit logs are implemented to support the detection of anomalies and suspicious activity, and the forensic analysis of events.
- Service
Core
10.2.1.25Checks if Kubernetes clusters have the specified settings. The rule is NON_COMPLIANT if the Kubernetes cluster does not have Secrets encryption enabled or uses an insecure key, or if audit logging is not enabled for the cluster.1
Attributes
- Section
10.2.1: Audit logs are implemented to support the detection of anomalies and suspicious activity, and the forensic analysis of events.
- Service
Core
10.2.1.26Checks if DNS query logging is enabled for Kubernetes services using CoreDNS. The rule is NON_COMPLIANT if DNS query logging is not enabled for CoreDNS in your Kubernetes cluster.0
Attributes
- Section
10.2.1: Audit logs are implemented to support the detection of anomalies and suspicious activity, and the forensic analysis of events.
- Service
Core
10.2.1.27Checks if logging is enabled for your Kubernetes Pods. The rule is NON_COMPLIANT if logging is not enabled.0
Attributes
- Section
10.2.1: Audit logs are implemented to support the detection of anomalies and suspicious activity, and the forensic analysis of events.
- Service
Core
10.2.1.28Checks if Kubernetes CronJobs have logging enabled. The rule is NON_COMPLIANT if a CronJob does not have logging enabled or the logging configuration is not at the minimum level provided.0
Attributes
- Section
10.2.1: Audit logs are implemented to support the detection of anomalies and suspicious activity, and the forensic analysis of events.
- Service
Kubernetes CronJob
10.2.1.29Checks if Kubernetes Network Policies are configured and enforced for all namespaces. The rule is NON_COMPLIANT if Network Policies are not configured for at least one namespace.1
Attributes
- Section
10.2.1: Audit logs are implemented to support the detection of anomalies and suspicious activity, and the forensic analysis of events.
- Service
Core
10.2.1.30Checks if logging is enabled on Kubernetes Ingress resources. The rule is NON_COMPLIANT if the logging is enabled but the logging destination does not match the expected configuration.0
Attributes
- Section
10.2.1: Audit logs are implemented to support the detection of anomalies and suspicious activity, and the forensic analysis of events.
- Service
API Server
10.2.1.31Checks if logging is enabled for Kubernetes Ingress resources. The rule is NON_COMPLIANT for an Ingress resource if it does not have access logging enabled.0
Attributes
- Section
10.2.1: Audit logs are implemented to support the detection of anomalies and suspicious activity, and the forensic analysis of events.
- Service
API Server
10.2.1.1: Audit logs are implemented to support the detection of anomalies and suspicious activity, and the forensic analysis of events.3311
10.2.1.1.1Checks if Kubernetes Ingress resources have access logging enabled. The rule is NON_COMPLIANT if 'accessLogSettings' is not present in Ingress configuration.0
Attributes
- Section
10.2.1.1: Audit logs are implemented to support the detection of anomalies and suspicious activity, and the forensic analysis of events.
- Service
API Server
10.2.1.1.2Checks if all methods in Kubernetes Ingress resources have access logs enabled. The rule is NON_COMPLIANT if access logging is not enabled, or if the logging level is neither ERROR nor INFO.0
Attributes
- Section
10.2.1.1: Audit logs are implemented to support the detection of anomalies and suspicious activity, and the forensic analysis of events.
- Service
API Server
10.2.1.1.5Checks if Kubernetes Services are configured with the correct session affinity settings. The rule is NON_COMPLIANT if Service session affinity does not match the user-defined session affinity settings.0
Attributes
- Section
10.2.1.1: Audit logs are implemented to support the detection of anomalies and suspicious activity, and the forensic analysis of events.
- Service
Core
10.2.1.1.6Checks if Kubernetes Ingress resources are configured to log access requests to a designated logging system. The rule is NON_COMPLIANT if an Ingress resource does not have logging configured.0
Attributes
- Section
10.2.1.1: Audit logs are implemented to support the detection of anomalies and suspicious activity, and the forensic analysis of events.
- Service
API Server
10.2.1.1.7Checks if at least one Kubernetes Audit Policy is logging events for all pods. The rule is NON_COMPLIANT if there are no audit policies or if no policies record pod events.1
Attributes
- Section
10.2.1.1: Audit logs are implemented to support the detection of anomalies and suspicious activity, and the forensic analysis of events.
- Service
API Server
10.2.1.1.8Checks if Kubernetes PodDisruptionBudgets (PDBs) have a policy configured for the desired states. Optionally verifies if any policies match a specified label selector. The rule is NON_COMPLIANT if there is no policy specified for the PDB or optional parameter.0
Attributes
- Section
10.2.1.1: Audit logs are implemented to support the detection of anomalies and suspicious activity, and the forensic analysis of events.
- Service
Core
10.2.1.1.11Checks if a Kubernetes Pod has at least one logging option enabled. The rule is NON_COMPLIANT if the status of all present logging configurations is set to 'DISABLED'.0
Attributes
- Section
10.2.1.1: Audit logs are implemented to support the detection of anomalies and suspicious activity, and the forensic analysis of events.
- Service
Core
10.2.1.1.12Checks if logging is enabled with a valid severity level for Kubernetes Cluster events. The rule is NON_COMPLIANT if logging is not enabled or logging for cluster events has a severity level that is not valid.0
Attributes
- Section
10.2.1.1: Audit logs are implemented to support the detection of anomalies and suspicious activity, and the forensic analysis of events.
- Service
Core
10.2.1.1.13Checks if a Kubernetes cluster has audit logging enabled. The rule is NON_COMPLIANT if the Kubernetes cluster does not have audit logging enabled.1
Attributes
- Section
10.2.1.1: Audit logs are implemented to support the detection of anomalies and suspicious activity, and the forensic analysis of events.
- Service
API Server
10.2.1.1.14Checks if Kubernetes Cluster has audit logging enabled. The rule is NON_COMPLIANT if 'audit-log.enabled' is set to false.1
Attributes
- Section
10.2.1.1: Audit logs are implemented to support the detection of anomalies and suspicious activity, and the forensic analysis of events.
- Service
API Server
10.2.1.1.15Verifies whether the Kubernetes cluster has the necessary monitoring (such as Prometheus) enabled for its pods. The status is NON_COMPLIANT if monitoring is not properly configured.0
Attributes
- Section
10.2.1.1: Audit logs are implemented to support the detection of anomalies and suspicious activity, and the forensic analysis of events.
- Service
Core
10.2.1.1.16Checks if log configuration is set on active Kubernetes Pods. This rule is NON_COMPLIANT if any active Pod does not have a valid logging configuration defined in its container specifications or if the logging configuration is null in at least one container definition.0
Attributes
- Section
10.2.1.1: Audit logs are implemented to support the detection of anomalies and suspicious activity, and the forensic analysis of events.
- Service
Core
10.2.1.1.17Checks if a Kubernetes cluster is configured with logging enabled. The rule is NON_COMPLIANT if logging for Kubernetes clusters is not enabled for all log types such as API server logs, audit logs, and etcd logs.1
Attributes
- Section
10.2.1.1: Audit logs are implemented to support the detection of anomalies and suspicious activity, and the forensic analysis of events.
- Service
API Server
10.2.1.1.18Checks if Kubernetes Pods are configured to send logs to a logging backend (e.g., Fluentd, Elasticsearch, or similar). The rule is NON_COMPLIANT if the logging configuration is not set up correctly or disabled.0
Attributes
- Section
10.2.1.1: Audit logs are implemented to support the detection of anomalies and suspicious activity, and the forensic analysis of events.
- Service
Core
10.2.1.1.19Checks if the Kubernetes Ingress resource has access logging enabled with specified S3 bucket for logs. The rule is NON_COMPLIANT if the log configuration is not set or bucket does not match the specified S3 bucket name.0
Attributes
- Section
10.2.1.1: Audit logs are implemented to support the detection of anomalies and suspicious activity, and the forensic analysis of events.
- Service
API Server
10.2.1.1.20Checks if Kubernetes brokers have audit logging enabled. The rule is NON_COMPLIANT if a broker does not have audit logging enabled.1
Attributes
- Section
10.2.1.1: Audit logs are implemented to support the detection of anomalies and suspicious activity, and the forensic analysis of events.
- Service
API Server
10.2.1.1.21Checks if a Kubernetes pod has audit logging enabled. The rule is NON_COMPLIANT if the pod does not have audit logging enabled.1
Attributes
- Section
10.2.1.1: Audit logs are implemented to support the detection of anomalies and suspicious activity, and the forensic analysis of events.
- Service
API Server
10.2.1.1.22In Kubernetes, a similar rule could be the requirement to enable audit logging across multiple Kubernetes clusters located in different regions to ensure comprehensive tracking of user activities and resource access.0
Attributes
- Section
10.2.1.1: Audit logs are implemented to support the detection of anomalies and suspicious activity, and the forensic analysis of events.
- Service
Core
10.2.1.1.23Checks if a Kubernetes cluster has logging enabled for audit logs. The rule is NON_COMPLIANT if the Kubernetes cluster does not have audit logging enabled.1
Attributes
- Section
10.2.1.1: Audit logs are implemented to support the detection of anomalies and suspicious activity, and the forensic analysis of events.
- Service
API Server
10.2.1.1.24Checks if Kubernetes Network Policies have logging enabled for traffic flow. The rule is NON_COMPLIANT if logging is not configured for any defined policy. You can specify which logging level or type you want the rule to check.0
Attributes
- Section
10.2.1.1: Audit logs are implemented to support the detection of anomalies and suspicious activity, and the forensic analysis of events.
- Service
Core
10.2.1.1.25Checks if Kubernetes clusters have logging configured to send logs to an external logging service (e.g., Elasticsearch, Fluentd) for monitoring and auditing. The rule is NON_COMPLIANT if the clusters do not have log forwarding configured.0
Attributes
- Section
10.2.1.1: Audit logs are implemented to support the detection of anomalies and suspicious activity, and the forensic analysis of events.
- Service
Core
10.2.1.1.26Checks if the respective logs of Kubernetes clusters are enabled. The rule is NON_COMPLIANT if any log types are not enabled.0
Attributes
- Section
10.2.1.1: Audit logs are implemented to support the detection of anomalies and suspicious activity, and the forensic analysis of events.
- Service
Core
10.2.1.1.27Checks if Kubernetes clusters are logging audits to a specific logging service. The rule is NON_COMPLIANT if audit logging is not enabled for a Kubernetes cluster or if the 'logDestination' parameter is provided but the audit logging destination does not match.1
Attributes
- Section
10.2.1.1: Audit logs are implemented to support the detection of anomalies and suspicious activity, and the forensic analysis of events.
- Service
API Server
10.2.1.1.28Checks if Kubernetes clusters have the specified security settings. The rule is NON_COMPLIANT if the Kubernetes cluster is not using a configured network policy or if role-based access control (RBAC) is not properly enforced, or if audit logging is not enabled.1
Attributes
- Section
10.2.1.1: Audit logs are implemented to support the detection of anomalies and suspicious activity, and the forensic analysis of events.
- Service
API Server
10.2.1.1.29Checks if DNS query logging is enabled for your Kubernetes cluster's CoreDNS. The rule is NON_COMPLIANT if DNS query logging is not enabled for your Kubernetes cluster's CoreDNS.0
Attributes
- Section
10.2.1.1: Audit logs are implemented to support the detection of anomalies and suspicious activity, and the forensic analysis of events.
- Service
Core
10.2.1.1.30Checks if logging is enabled for your Kubernetes Pods. The rule is NON_COMPLIANT if logging is not enabled.0
Attributes
- Section
10.2.1.1: Audit logs are implemented to support the detection of anomalies and suspicious activity, and the forensic analysis of events.
- Service
Core
10.2.1.1.31Checks if Kubernetes Pod Security Standards are enforced for a namespace. The rule is NON_COMPLIANT if Pod Security Standards are not enforced.0
Attributes
- Section
10.2.1.1: Audit logs are implemented to support the detection of anomalies and suspicious activity, and the forensic analysis of events.
- Service
Core
10.2.1.1.32Checks if Kubernetes Event logging is enabled for the delivery status of events sent to a resource for the endpoints. The rule is NON_COMPLIANT if the delivery status notification for events is not enabled.0
Attributes
- Section
10.2.1.1: Audit logs are implemented to support the detection of anomalies and suspicious activity, and the forensic analysis of events.
- Service
Core
10.2.1.1.33Checks if Kubernetes Audit Logging is enabled. The rule is NON_COMPLIANT if an audit logging configuration is not present or the logging level does not meet the minimum required level.1
Attributes
- Section
10.2.1.1: Audit logs are implemented to support the detection of anomalies and suspicious activity, and the forensic analysis of events.
- Service
API Server
10.2.1.1.34Checks if Kubernetes network policies are applied and enforced for all namespaces. The rule is NON_COMPLIANT if network policies are not applied to at least one namespace.1
Attributes
- Section
10.2.1.1: Audit logs are implemented to support the detection of anomalies and suspicious activity, and the forensic analysis of events.
- Service
Core
10.2.1.1.35Checks if logging is enabled on Kubernetes Ingress resources. The rule is NON_COMPLIANT if logging is enabled but the log output destination does not match the specified configuration.0
Attributes
- Section
10.2.1.1: Audit logs are implemented to support the detection of anomalies and suspicious activity, and the forensic analysis of events.
- Service
API Server
10.2.1.1.36Checks if the monitoring metrics collection on Kubernetes Network Policies is enabled. The rule is NON_COMPLIANT if the 'monitoringMetricsEnabled' field is set to false.0
Attributes
- Section
10.2.1.1: Audit logs are implemented to support the detection of anomalies and suspicious activity, and the forensic analysis of events.
- Service
API Server
10.2.1.1.37Checks if logging is enabled on Kubernetes Ingress resources. The rule is NON_COMPLIANT for an Ingress resource if it does not have logging enabled.0
Attributes
- Section
10.2.1.1: Audit logs are implemented to support the detection of anomalies and suspicious activity, and the forensic analysis of events.
- Service
API Server
10.2.1.2: Audit logs are implemented to support the detection of anomalies and suspicious activity, and the forensic analysis of events.278
10.2.1.2.1Checks if Kubernetes Ingress resources have access logging enabled. The rule is NON_COMPLIANT if 'accessLog' annotation is not present in the Ingress configuration.0
Attributes
- Section
10.2.1.2: Audit logs are implemented to support the detection of anomalies and suspicious activity, and the forensic analysis of events.
- Service
API Server
10.2.1.2.2Checks if all methods in Kubernetes Ingress have access logging enabled. The rule is NON_COMPLIANT if access logging is not enabled, or if logging level is neither ERROR nor INFO.0
Attributes
- Section
10.2.1.2: Audit logs are implemented to support the detection of anomalies and suspicious activity, and the forensic analysis of events.
- Service
API Server
10.2.1.2.3Checks if OpenTelemetry tracing is enabled on Kubernetes API services. The rule is COMPLIANT if OpenTelemetry tracing is enabled and NON_COMPLIANT otherwise.0
Attributes
- Section
10.2.1.2: Audit logs are implemented to support the detection of anomalies and suspicious activity, and the forensic analysis of events.
- Service
API Server
10.2.1.2.4Checks if a Kubernetes API server has audit logging enabled. The rule is NON_COMPLIANT if audit logging is not enabled, or 'audit-log-path' is not set to a valid file path.1
Attributes
- Section
10.2.1.2: Audit logs are implemented to support the detection of anomalies and suspicious activity, and the forensic analysis of events.
- Service
API Server
10.2.1.2.5Checks if Kubernetes Services are configured with appropriate session affinity settings. The rule is NON_COMPLIANT if the session affinity settings do not match the user defined criteria for session persistence.0
Attributes
- Section
10.2.1.2: Audit logs are implemented to support the detection of anomalies and suspicious activity, and the forensic analysis of events.
- Service
Core
10.2.1.2.6Checks if Kubernetes Ingress resources are configured to log access to the backend services. The rule is NON_COMPLIANT if an Ingress resource does not have access logging enabled.0
Attributes
- Section
10.2.1.2: Audit logs are implemented to support the detection of anomalies and suspicious activity, and the forensic analysis of events.
- Service
API Server
10.2.1.2.7Checks if at least one Kubernetes Audit Policy is logging API requests for all pods and namespaces. The rule is NON_COMPLIANT if there are no policies or if policies do not record pod and namespace API requests.1
Attributes
- Section
10.2.1.2: Audit logs are implemented to support the detection of anomalies and suspicious activity, and the forensic analysis of events.
- Service
API Server
10.2.1.2.9Checks if a Kubernetes Pod has at least one logging mechanism enabled (such as stdout/stderr logging or integration with a logging sidecar). The rule is NON_COMPLIANT if the logging configurations are all set to 'DISABLED'.0
Attributes
- Section
10.2.1.2: Audit logs are implemented to support the detection of anomalies and suspicious activity, and the forensic analysis of events.
- Service
Core
10.2.1.2.10Checks if logging is enabled with a valid severity level for Kubernetes pod events. The rule is NON_COMPLIANT if logging is not enabled or the logging severity level for pod events is not valid.0
Attributes
- Section
10.2.1.2: Audit logs are implemented to support the detection of anomalies and suspicious activity, and the forensic analysis of events.
- Service
Core
10.2.1.2.12Checks if a Kubernetes cluster has logging enabled for its pods. The rule is NON_COMPLIANT if the pod spec 'spec.containers[].logConfig.enabled' is set to false.0
Attributes
- Section
10.2.1.2: Audit logs are implemented to support the detection of anomalies and suspicious activity, and the forensic analysis of events.
- Service
Core
10.2.1.2.13Checks if logging is configured for active Kubernetes Pods and their associated Container definitions. This rule is NON_COMPLIANT if an active Pod does not have logging configured or if the logging configuration is absent in at least one Container specification.0
Attributes
- Section
10.2.1.2: Audit logs are implemented to support the detection of anomalies and suspicious activity, and the forensic analysis of events.
- Service
Core
10.2.1.2.14Checks if a Kubernetes cluster is configured with logging enabled. The rule is NON_COMPLIANT if logging for the Kubernetes cluster is not enabled for all log types, such as container logs, audit logs, and application logs.0
Attributes
- Section
10.2.1.2: Audit logs are implemented to support the detection of anomalies and suspicious activity, and the forensic analysis of events.
- Service
Core
10.2.1.2.15Checks if Kubernetes pods are configured to send logs to a logging backend (such as Fluentd or Elasticsearch). The rule is NON_COMPLIANT if the logging configuration does not send logs appropriately.0
Attributes
- Section
10.2.1.2: Audit logs are implemented to support the detection of anomalies and suspicious activity, and the forensic analysis of events.
- Service
Core
10.2.1.2.16Checks if the Kubernetes Ingress and Service resources have access logging enabled. The rule is NON_COMPLIANT if the access logging is not configured or does not point to the specified log storage location (like a specific S3 bucket or object storage equivalent).0
Attributes
- Section
10.2.1.2: Audit logs are implemented to support the detection of anomalies and suspicious activity, and the forensic analysis of events.
- Service
API Server
10.2.1.2.17Checks if Kubernetes clusters have audit logging enabled. The rule is NON_COMPLIANT if a cluster does not have audit logging enabled.1
Attributes
- Section
10.2.1.2: Audit logs are implemented to support the detection of anomalies and suspicious activity, and the forensic analysis of events.
- Service
API Server
10.2.1.2.18Checks if a Kubernetes cluster has audit logging enabled. The rule is NON_COMPLIANT if the Kubernetes audit logging is not enabled.1
Attributes
- Section
10.2.1.2: Audit logs are implemented to support the detection of anomalies and suspicious activity, and the forensic analysis of events.
- Service
API Server
10.2.1.2.20Checks if a Kubernetes cluster has logging enabled for audit logs. The rule is NON_COMPLIANT if the Kubernetes cluster does not have logging enabled for audit logs.1
Attributes
- Section
10.2.1.2: Audit logs are implemented to support the detection of anomalies and suspicious activity, and the forensic analysis of events.
- Service
API Server
10.2.1.2.21Checks if Kubernetes Network Policies have logging enabled. The rule is NON_COMPLIANT if a logging type is not configured. You can specify which logging type you want the rule to check.0
Attributes
- Section
10.2.1.2: Audit logs are implemented to support the detection of anomalies and suspicious activity, and the forensic analysis of events.
- Service
Core
10.2.1.2.23Checks if respective logs of Kubernetes Pods are enabled. The rule is NON_COMPLIANT if any log types are not enabled.0
Attributes
- Section
10.2.1.2: Audit logs are implemented to support the detection of anomalies and suspicious activity, and the forensic analysis of events.
- Service
Core
10.2.1.2.24Checks if Kubernetes clusters are logging audit events to a specific logging service. The rule is NON_COMPLIANT if audit logging is not enabled for a Kubernetes cluster or if the 'auditLogDestination' parameter is provided but the audit logging destination does not match.1
Attributes
- Section
10.2.1.2: Audit logs are implemented to support the detection of anomalies and suspicious activity, and the forensic analysis of events.
- Service
API Server
10.2.1.2.25Checks if Kubernetes clusters have the specified settings. The rule is NON_COMPLIANT if the Kubernetes cluster is not using network policies, does not have role-based access control (RBAC) enabled, or if the cluster does not have audit logging enabled.1
Attributes
- Section
10.2.1.2: Audit logs are implemented to support the detection of anomalies and suspicious activity, and the forensic analysis of events.
- Service
API Server
10.2.1.2.26Checks if DNS query logging is enabled for your Kubernetes DNS services. The rule is NON_COMPLIANT if DNS query logging is not enabled for your Kubernetes DNS services.0
Attributes
- Section
10.2.1.2: Audit logs are implemented to support the detection of anomalies and suspicious activity, and the forensic analysis of events.
- Service
API Server
10.2.1.2.27Checks if logging is enabled for your Kubernetes clusters. The rule is NON_COMPLIANT if logging is not enabled.0
Attributes
- Section
10.2.1.2: Audit logs are implemented to support the detection of anomalies and suspicious activity, and the forensic analysis of events.
- Service
Core
10.2.1.2.28Checks if a Kubernetes pod has logging enabled. The rule is NON_COMPLIANT if a pod does not have logging enabled or the logging configuration is not at the minimum level provided.0
Attributes
- Section
10.2.1.2: Audit logs are implemented to support the detection of anomalies and suspicious activity, and the forensic analysis of events.
- Service
Core
10.2.1.2.29Checks if Kubernetes Network Policies are defined and enforced for all namespaces. The rule is NON_COMPLIANT if network policies are not defined for at least one namespace.1
Attributes
- Section
10.2.1.2: Audit logs are implemented to support the detection of anomalies and suspicious activity, and the forensic analysis of events.
- Service
Core
10.2.1.2.30Checks if logging is enabled on Kubernetes Ingress controllers. The rule is NON_COMPLIANT if logging is enabled but the logging destination does not match the expected configuration.0
Attributes
- Section
10.2.1.2: Audit logs are implemented to support the detection of anomalies and suspicious activity, and the forensic analysis of events.
- Service
API Server
10.2.1.2.31Checks if logging is enabled on Kubernetes Ingress resources. The rule is NON_COMPLIANT for an Ingress resource, if it does not have access logging enabled.0
Attributes
- Section
10.2.1.2: Audit logs are implemented to support the detection of anomalies and suspicious activity, and the forensic analysis of events.
- Service
API Server
10.2.1.3: Audit logs are implemented to support the detection of anomalies and suspicious activity, and the forensic analysis of events.288
10.2.1.3.1Checks if Kubernetes Ingress resources have access logging enabled. The rule is NON_COMPLIANT if 'accessLog' configuration is not specified in the Ingress resource.0
Attributes
- Section
10.2.1.3: Audit logs are implemented to support the detection of anomalies and suspicious activity, and the forensic analysis of events.
- Service
API Server
10.2.1.3.2Checks if all methods in Kubernetes Ingress resources have access logging enabled. The rule is NON_COMPLIANT if access logging is not enabled, or if the log level is neither ERROR nor INFO.0
Attributes
- Section
10.2.1.3: Audit logs are implemented to support the detection of anomalies and suspicious activity, and the forensic analysis of events.
- Service
API Server
10.2.1.3.3Checks if OpenTelemetry tracing is enabled on Kubernetes API services. The rule is COMPLIANT if OpenTelemetry tracing is enabled and NON_COMPLIANT otherwise.0
Attributes
- Section
10.2.1.3: Audit logs are implemented to support the detection of anomalies and suspicious activity, and the forensic analysis of events.
- Service
API Server
10.2.1.3.4Checks if a Kubernetes Service has logging enabled. The rule is NON_COMPLIANT if logging is not enabled or if the log level is set to a value other than ERROR or ALL.0
Attributes
- Section
10.2.1.3: Audit logs are implemented to support the detection of anomalies and suspicious activity, and the forensic analysis of events.
- Service
Core
10.2.1.3.5Checks if Kubernetes Services of type LoadBalancer are configured with a user-defined health check configuration. The rule is NON_COMPLIANT if the health check settings do not match the user-defined settings.0
Attributes
- Section
10.2.1.3: Audit logs are implemented to support the detection of anomalies and suspicious activity, and the forensic analysis of events.
- Service
Scheduler
10.2.1.3.6Checks if Kubernetes Ingress resources are configured to log access traffic to a specified logging service. The rule is NON_COMPLIANT if an Ingress resource does not have access logging enabled.0
Attributes
- Section
10.2.1.3: Audit logs are implemented to support the detection of anomalies and suspicious activity, and the forensic analysis of events.
- Service
API Server
10.2.1.3.7Checks if at least one Kubernetes Audit Policy is configured to log data access events for all Pods. The rule is NON_COMPLIANT if there are no policies or if no policies record data access events.1
Attributes
- Section
10.2.1.3: Audit logs are implemented to support the detection of anomalies and suspicious activity, and the forensic analysis of events.
- Service
API Server
10.2.1.3.9Checks if a Kubernetes Pod has at least one logging mechanism enabled. The rule is NON_COMPLIANT if all present logging configurations are set to 'DISABLED'.0
Attributes
- Section
10.2.1.3: Audit logs are implemented to support the detection of anomalies and suspicious activity, and the forensic analysis of events.
- Service
Core
10.2.1.3.10Checks if logging is enabled with a valid severity level for Kubernetes pod events in a target namespace. The rule is NON_COMPLIANT if logging is not enabled or pod event logging of a target namespace has a severity level that is not valid.0
Attributes
- Section
10.2.1.3: Audit logs are implemented to support the detection of anomalies and suspicious activity, and the forensic analysis of events.
- Service
Core
10.2.1.3.11Checks if a Kubernetes cluster has logging enabled via a logging agent (like Fluentd) to export logs to a monitoring service (like Elasticsearch or CloudWatch) for audit purposes. The rule is NON_COMPLIANT if the Kubernetes cluster does not have log export enabled for audit logs.1
Attributes
- Section
10.2.1.3: Audit logs are implemented to support the detection of anomalies and suspicious activity, and the forensic analysis of events.
- Service
API Server
10.2.1.3.12Checks if the Kubernetes cluster has logging enabled for its pods. The rule is NON_COMPLIANT if 'spec.containers.logging' is set to false.0
Attributes
- Section
10.2.1.3: Audit logs are implemented to support the detection of anomalies and suspicious activity, and the forensic analysis of events.
- Service
Kubelet
10.2.1.3.13Checks if log configuration is set on active Kubernetes Pods. This rule is NON_COMPLIANT if an active Pod does not have logging configuration defined in its specification or the value for the logging configuration is null in at least one container definition.0
Attributes
- Section
10.2.1.3: Audit logs are implemented to support the detection of anomalies and suspicious activity, and the forensic analysis of events.
- Service
Core
10.2.1.3.14Checks if a Kubernetes cluster is configured with logging enabled. The rule is NON_COMPLIANT if logging for Kubernetes clusters is not enabled for all log types.0
Attributes
- Section
10.2.1.3: Audit logs are implemented to support the detection of anomalies and suspicious activity, and the forensic analysis of events.
- Service
Core
10.2.1.3.15Checks if Kubernetes Pods are configured to send logs to a centralized logging solution (like Fluentd or Elasticsearch). The rule is NON_COMPLIANT if the logging configuration is not set to forward logs.0
Attributes
- Section
10.2.1.3: Audit logs are implemented to support the detection of anomalies and suspicious activity, and the forensic analysis of events.
- Service
Core
10.2.1.3.16Checks if the Kubernetes Ingress and LoadBalancer services have logging enabled. The rule is NON_COMPLIANT if the ingress.annotations indicates logging is disabled or the configured log destination is not equal to the specified logging destination.0
Attributes
- Section
10.2.1.3: Audit logs are implemented to support the detection of anomalies and suspicious activity, and the forensic analysis of events.
- Service
API Server
10.2.1.3.17Checks if Kubernetes clusters have auditing enabled. The rule is NON_COMPLIANT if audit logging is not enabled in the cluster.1
Attributes
- Section
10.2.1.3: Audit logs are implemented to support the detection of anomalies and suspicious activity, and the forensic analysis of events.
- Service
API Server
10.2.1.3.18Checks if a Kubernetes cluster has audit logging enabled. The rule is NON_COMPLIANT if audit logging is not enabled for the Kubernetes API server.1
Attributes
- Section
10.2.1.3: Audit logs are implemented to support the detection of anomalies and suspicious activity, and the forensic analysis of events.
- Service
API Server
10.2.1.3.20Checks if a Kubernetes cluster has logging enabled and if logs are being exported to an external logging service like Elasticsearch or a similar service. The rule is NON_COMPLIANT if logging is not enabled or if logs are not exported.0
Attributes
- Section
10.2.1.3: Audit logs are implemented to support the detection of anomalies and suspicious activity, and the forensic analysis of events.
- Service
Core
10.2.1.3.21Checks if Kubernetes Network Policies are configured with appropriate logging. The rule is NON_COMPLIANT if a logging mechanism is not configured for traffic flow monitoring.0
Attributes
- Section
10.2.1.3: Audit logs are implemented to support the detection of anomalies and suspicious activity, and the forensic analysis of events.
- Service
Core
10.2.1.3.23Checks if respective logs of Kubernetes are enabled. The rule is NON_COMPLIANT if any log types are not enabled, such as audit logs or container logs.1
Attributes
- Section
10.2.1.3: Audit logs are implemented to support the detection of anomalies and suspicious activity, and the forensic analysis of events.
- Service
API Server
10.2.1.3.24Checks if Kubernetes clusters have audit logging configured to send logs to a specific log aggregation service. The rule is NON_COMPLIANT if audit logging is not enabled for a Kubernetes cluster or if the 'logAggregationService' parameter is provided but the audit logging destination does not match.1
Attributes
- Section
10.2.1.3: Audit logs are implemented to support the detection of anomalies and suspicious activity, and the forensic analysis of events.
- Service
API Server
10.2.1.3.25Checks if Kubernetes clusters have the specified settings. The rule is NON_COMPLIANT if the Kubernetes cluster is not using secrets for managing sensitive information or if the cluster does not have audit logging enabled.1
Attributes
- Section
10.2.1.3: Audit logs are implemented to support the detection of anomalies and suspicious activity, and the forensic analysis of events.
- Service
RBAC
10.2.1.3.26Checks if DNS query logging is enabled for your Kubernetes cluster's CoreDNS configuration. The rule is NON_COMPLIANT if DNS query logging is not enabled for CoreDNS.0
Attributes
- Section
10.2.1.3: Audit logs are implemented to support the detection of anomalies and suspicious activity, and the forensic analysis of events.
- Service
Core
10.2.1.3.27Checks if logging is enabled for your Kubernetes Pods. The rule is NON_COMPLIANT if logging is not enabled.0
Attributes
- Section
10.2.1.3: Audit logs are implemented to support the detection of anomalies and suspicious activity, and the forensic analysis of events.
- Service
Core
10.2.1.3.28Checks if a Kubernetes Job has logging enabled. The rule is NON_COMPLIANT if a Job does not have logging enabled or the logging configuration is not at the minimum level provided.0
Attributes
- Section
10.2.1.3: Audit logs are implemented to support the detection of anomalies and suspicious activity, and the forensic analysis of events.
- Service
Core
10.2.1.3.29Checks if Kubernetes NetworkPolicy resources are defined and enforced for all namespaces. The rule is NON_COMPLIANT if NetworkPolicy is not defined for at least one namespace.1
Attributes
- Section
10.2.1.3: Audit logs are implemented to support the detection of anomalies and suspicious activity, and the forensic analysis of events.
- Service
Core
10.2.1.3.30Checks if logging is enabled on Kubernetes Ingress resources. The rule is NON_COMPLIANT if the logging is enabled but the logging destination does not match the specified value.0
Attributes
- Section
10.2.1.3: Audit logs are implemented to support the detection of anomalies and suspicious activity, and the forensic analysis of events.
- Service
API Server
10.2.1.3.31Checks if logging is enabled on Kubernetes Ingress resources. The rule is NON_COMPLIANT for an Ingress resource if it does not have access logging enabled.0
Attributes
- Section
10.2.1.3: Audit logs are implemented to support the detection of anomalies and suspicious activity, and the forensic analysis of events.
- Service
API Server
10.2.1.4: Audit logs are implemented to support the detection of anomalies and suspicious activity, and the forensic analysis of events.2710
10.2.1.4.1Checks if Kubernetes Ingress resources have access logging enabled. The rule is NON_COMPLIANT if 'accessLog' annotation is not present in the Ingress configuration.0
Attributes
- Section
10.2.1.4: Audit logs are implemented to support the detection of anomalies and suspicious activity, and the forensic analysis of events.
- Service
API Server
10.2.1.4.2Checks if all methods in Kubernetes Ingress resources have access logging enabled. The rule is NON_COMPLIANT if access logging is not enabled, or if logging level is neither ERROR nor INFO.0
Attributes
- Section
10.2.1.4: Audit logs are implemented to support the detection of anomalies and suspicious activity, and the forensic analysis of events.
- Service
API Server
10.2.1.4.3Checks if OpenTelemetry tracing is enabled on Kubernetes services that expose APIs. The rule is COMPLIANT if OpenTelemetry tracing is enabled, and NON_COMPLIANT otherwise.0
Attributes
- Section
10.2.1.4: Audit logs are implemented to support the detection of anomalies and suspicious activity, and the forensic analysis of events.
- Service
Core
10.2.1.4.4Checks if a Kubernetes API server has audit logging enabled. The rule is NON_COMPLIANT if audit logging is not enabled, or if 'auditLogPath' is not set or is set to an invalid log level.1
Attributes
- Section
10.2.1.4: Audit logs are implemented to support the detection of anomalies and suspicious activity, and the forensic analysis of events.
- Service
API Server
10.2.1.4.5Checks if Kubernetes Services of type LoadBalancer are configured with an appropriate externalTrafficPolicy. The rule is NON_COMPLIANT if the externalTrafficPolicy does not match the user-defined externalTrafficPolicy for preserving client source IP.1
Attributes
- Section
10.2.1.4: Audit logs are implemented to support the detection of anomalies and suspicious activity, and the forensic analysis of events.
- Service
API Server
10.2.1.4.6Checks if Kubernetes Ingress resources are configured to log access to a specified logging service. The rule is NON_COMPLIANT if an Ingress resource does not have logging configured.0
Attributes
- Section
10.2.1.4: Audit logs are implemented to support the detection of anomalies and suspicious activity, and the forensic analysis of events.
- Service
API Server
10.2.1.4.7Checks if at least one Kubernetes Audit Policy is configured to log request and response data for all Pods in the cluster. The rule is NON_COMPLIANT if there are no audit policies or if none of the policies record Pod data events.1
Attributes
- Section
10.2.1.4: Audit logs are implemented to support the detection of anomalies and suspicious activity, and the forensic analysis of events.
- Service
API Server
10.2.1.4.9Checks if a Kubernetes Pod's logging mechanism is properly configured. The rule is NON_COMPLIANT if all logging options (such as stdout/stderr or external logging solutions) are disabled.0
Attributes
- Section
10.2.1.4: Audit logs are implemented to support the detection of anomalies and suspicious activity, and the forensic analysis of events.
- Service
Core
10.2.1.4.10Checks if logging is enabled with a valid severity level for Kubernetes events of a target pod. The rule is NON_COMPLIANT if logging is not enabled or if pod logging has a severity level that is not valid.0
Attributes
- Section
10.2.1.4: Audit logs are implemented to support the detection of anomalies and suspicious activity, and the forensic analysis of events.
- Service
Core
10.2.1.4.11Checks if a Kubernetes cluster has the logging feature enabled for audit logs. The rule is NON_COMPLIANT if a Kubernetes cluster does not have logging enabled for audit logs.1
Attributes
- Section
10.2.1.4: Audit logs are implemented to support the detection of anomalies and suspicious activity, and the forensic analysis of events.
- Service
API Server
10.2.1.4.12Checks if Kubernetes Deployment has logging enabled for applications. The rule is NON_COMPLIANT if 'spec.template.spec.containers[0].env' does not contain a logging environment variable set to true.0
Attributes
- Section
10.2.1.4: Audit logs are implemented to support the detection of anomalies and suspicious activity, and the forensic analysis of events.
- Service
Core
10.2.1.4.13Checks if logging is configured for active Kubernetes Pods. This rule is NON_COMPLIANT if an active Pod does not have logging configured or the logging configuration is null for at least one container within the Pod.0
Attributes
- Section
10.2.1.4: Audit logs are implemented to support the detection of anomalies and suspicious activity, and the forensic analysis of events.
- Service
Core
10.2.1.4.14Checks if a Kubernetes cluster is configured with logging enabled. The rule is NON_COMPLIANT if logging for the Kubernetes cluster is not enabled for all log types, such as application logs, audit logs, and kubelet logs.1
Attributes
- Section
10.2.1.4: Audit logs are implemented to support the detection of anomalies and suspicious activity, and the forensic analysis of events.
- Service
API Server
10.2.1.4.15Checks if Kubernetes clusters are configured to send logs to a logging solution (such as Fluentd or Elasticsearch) via log aggregation. The rule is NON_COMPLIANT if the logging agent is not properly configured.0
Attributes
- Section
10.2.1.4: Audit logs are implemented to support the detection of anomalies and suspicious activity, and the forensic analysis of events.
- Service
Core
10.2.1.4.16Checks if the Kubernetes Ingress has logging enabled. The rule is NON_COMPLIANT if the access logs are not directed to the specified log location or if the logging configuration is not enabled.0
Attributes
- Section
10.2.1.4: Audit logs are implemented to support the detection of anomalies and suspicious activity, and the forensic analysis of events.
- Service
API Server
10.2.1.4.18Checks if a Kubernetes cluster has audit logging enabled. The rule is NON_COMPLIANT if the cluster does not have audit logging enabled.1
Attributes
- Section
10.2.1.4: Audit logs are implemented to support the detection of anomalies and suspicious activity, and the forensic analysis of events.
- Service
API Server
10.2.1.4.20Checks if a Kubernetes cluster has logging enabled with a centralized logging solution, such as Elasticsearch, Fluentd, and Kibana (EFK) or Loki, for audit logs. The rule is NON_COMPLIANT if logging is not enabled for audit logs in the Kubernetes cluster.1
Attributes
- Section
10.2.1.4: Audit logs are implemented to support the detection of anomalies and suspicious activity, and the forensic analysis of events.
- Service
API Server
10.2.1.4.21Checks if the Kubernetes Network Policy logs are enabled. The rule is NON_COMPLIANT if logging is not configured for the specified Network Policy types.0
Attributes
- Section
10.2.1.4: Audit logs are implemented to support the detection of anomalies and suspicious activity, and the forensic analysis of events.
- Service
Core
10.2.1.4.22Checks if Kubernetes clusters are configured to send audit logs to a logging service like Fluentd or ElasticSearch. The rule is NON_COMPLIANT if Kubernetes clusters do not have audit log publishing configured.1
Attributes
- Section
10.2.1.4: Audit logs are implemented to support the detection of anomalies and suspicious activity, and the forensic analysis of events.
- Service
API Server
10.2.1.4.23Checks if respective logs of Kubernetes are enabled. The rule is NON_COMPLIANT if any log types are not enabled.0
Attributes
- Section
10.2.1.4: Audit logs are implemented to support the detection of anomalies and suspicious activity, and the forensic analysis of events.
- Service
Core
10.2.1.4.25Checks if Kubernetes clusters have the specified security settings. The rule is NON_COMPLIANT if the Kubernetes cluster does not have encryption enabled for secrets or uses an invalid encryption key, or if the cluster does not have auditing enabled.1
Attributes
- Section
10.2.1.4: Audit logs are implemented to support the detection of anomalies and suspicious activity, and the forensic analysis of events.
- Service
RBAC
10.2.1.4.26Checks if DNS query logging is enabled for your Kubernetes cluster's CoreDNS. The rule is NON_COMPLIANT if DNS query logging is not enabled for CoreDNS in the Kubernetes cluster.0
Attributes
- Section
10.2.1.4: Audit logs are implemented to support the detection of anomalies and suspicious activity, and the forensic analysis of events.
- Service
Core
10.2.1.4.27Checks if logging is enabled for your Kubernetes pods. The rule is NON_COMPLIANT if logging is not enabled.0
Attributes
- Section
10.2.1.4: Audit logs are implemented to support the detection of anomalies and suspicious activity, and the forensic analysis of events.
- Service
Core
10.2.1.4.28Checks if Kubernetes Pods have logging enabled. The rule is NON_COMPLIANT if a Pod does not have logging enabled or the logging configuration is not at the minimum level required.0
Attributes
- Section
10.2.1.4: Audit logs are implemented to support the detection of anomalies and suspicious activity, and the forensic analysis of events.
- Service
Core
10.2.1.4.29Checks if Kubernetes network policies are enforced and configured for all namespaces. The rule is NON_COMPLIANT if network policies are not defined for at least one namespace.1
Attributes
- Section
10.2.1.4: Audit logs are implemented to support the detection of anomalies and suspicious activity, and the forensic analysis of events.
- Service
Core
10.2.1.4.30Checks if logging is enabled on Kubernetes Ingress controllers. The rule is NON_COMPLIANT if logging is enabled but the logging destination does not match the expected configuration.0
Attributes
- Section
10.2.1.4: Audit logs are implemented to support the detection of anomalies and suspicious activity, and the forensic analysis of events.
- Service
API Server
10.2.1.4.31Checks if logging is enabled on Kubernetes Ingress resources. The rule is NON_COMPLIANT for an Ingress resource if it does not have access logging enabled.0
Attributes
- Section
10.2.1.4: Audit logs are implemented to support the detection of anomalies and suspicious activity, and the forensic analysis of events.
- Service
API Server
10.2.1.5: Audit logs are implemented to support the detection of anomalies and suspicious activity, and the forensic analysis of events.2910
10.2.1.5.1Checks if Kubernetes Ingress resources have access logging enabled. The rule is NON_COMPLIANT if 'accessLogs' settings are not present in the Ingress configuration.0
Attributes
- Section
10.2.1.5: Audit logs are implemented to support the detection of anomalies and suspicious activity, and the forensic analysis of events.
- Service
API Server
10.2.1.5.2Checks if all methods in Kubernetes Ingress have access logging enabled. The rule is NON_COMPLIANT if access logging is not enabled, or if the log level is neither ERROR nor INFO.0
Attributes
- Section
10.2.1.5: Audit logs are implemented to support the detection of anomalies and suspicious activity, and the forensic analysis of events.
- Service
API Server
10.2.1.5.3Checks if OpenTelemetry tracing is enabled on Kubernetes Ingress resources. The rule is COMPLIANT if OpenTelemetry tracing is enabled and NON_COMPLIANT otherwise.0
Attributes
- Section
10.2.1.5: Audit logs are implemented to support the detection of anomalies and suspicious activity, and the forensic analysis of events.
- Service
API Server
10.2.1.5.4Checks if a Kubernetes API server has audit logging enabled. The rule is NON_COMPLIANT if audit logging is not enabled, or if 'logLevel' is neither 'Error' nor 'All'.1
Attributes
- Section
10.2.1.5: Audit logs are implemented to support the detection of anomalies and suspicious activity, and the forensic analysis of events.
- Service
API Server
10.2.1.5.5Checks if Kubernetes Services are configured with a user-defined session affinity setting. The rule is NON_COMPLIANT if the service session affinity does not match the user-defined session affinity mode.0
Attributes
- Section
10.2.1.5: Audit logs are implemented to support the detection of anomalies and suspicious activity, and the forensic analysis of events.
- Service
Core
10.2.1.5.6Checks if Kubernetes Ingress resources are configured to log requests to a specified logging service. The rule is NON_COMPLIANT if an Ingress resource does not have logging configured.0
Attributes
- Section
10.2.1.5: Audit logs are implemented to support the detection of anomalies and suspicious activity, and the forensic analysis of events.
- Service
API Server
10.2.1.5.7Checks if at least one Kubernetes audit policy is configured to log API requests for all namespaces. The rule is NON_COMPLIANT if there are no audit policies or if existing policies do not log API requests.1
Attributes
- Section
10.2.1.5: Audit logs are implemented to support the detection of anomalies and suspicious activity, and the forensic analysis of events.
- Service
API Server
10.2.1.5.9Checks if a Kubernetes Pod has at least one logging mechanism configured. The rule is NON_COMPLIANT if the status of all present logging configurations is set to 'DISABLED'.0
Attributes
- Section
10.2.1.5: Audit logs are implemented to support the detection of anomalies and suspicious activity, and the forensic analysis of events.
- Service
Core
10.2.1.5.10Checks if logging is enabled with a valid severity level for Kubernetes Pod events. The rule is NON_COMPLIANT if logging is not enabled or Pod logging has a severity level that is not valid.0
Attributes
- Section
10.2.1.5: Audit logs are implemented to support the detection of anomalies and suspicious activity, and the forensic analysis of events.
- Service
Core
10.2.1.5.11Checks if a Kubernetes cluster has logging enabled for audit logs. The rule is NON_COMPLIANT if a Kubernetes cluster does not have logging enabled for audit logs.1
Attributes
- Section
10.2.1.5: Audit logs are implemented to support the detection of anomalies and suspicious activity, and the forensic analysis of events.
- Service
API Server
10.2.1.5.12Checks if Kubernetes has client connection logging enabled for its API server. The rule is NON_COMPLIANT if the 'audit-log.enabled' setting is set to false.1
Attributes
- Section
10.2.1.5: Audit logs are implemented to support the detection of anomalies and suspicious activity, and the forensic analysis of events.
- Service
API Server
10.2.1.5.13Checks if log settings are defined in active Kubernetes Pod specifications. This rule is NON_COMPLIANT if an active Pod does not have the logging configuration defined or the value for logging is null in at least one container definition.0
Attributes
- Section
10.2.1.5: Audit logs are implemented to support the detection of anomalies and suspicious activity, and the forensic analysis of events.
- Service
Core
10.2.1.5.14Checks if a Kubernetes cluster is configured with logging enabled. The rule is NON_COMPLIANT if logging for the Kubernetes cluster is not enabled for all log types.0
Attributes
- Section
10.2.1.5: Audit logs are implemented to support the detection of anomalies and suspicious activity, and the forensic analysis of events.
- Service
Core
10.2.1.5.15Checks if Kubernetes Pods are configured to send logs to a central logging solution (e.g., Fluentd, Elasticsearch, or others). The rule is NON_COMPLIANT if the logging agent is not deployed or configured incorrectly.0
Attributes
- Section
10.2.1.5: Audit logs are implemented to support the detection of anomalies and suspicious activity, and the forensic analysis of events.
- Service
Core
10.2.1.5.16Checks if the Ingress Resource has access logging enabled. The rule is NON_COMPLIANT if the annotations for access logs are not set correctly or do not match the specified S3 bucket name.0
Attributes
- Section
10.2.1.5: Audit logs are implemented to support the detection of anomalies and suspicious activity, and the forensic analysis of events.
- Service
API Server
10.2.1.5.17Checks if Kubernetes clusters have audit logging enabled. The rule is NON_COMPLIANT if a cluster does not have audit logging enabled.1
Attributes
- Section
10.2.1.5: Audit logs are implemented to support the detection of anomalies and suspicious activity, and the forensic analysis of events.
- Service
API Server
10.2.1.5.18Checks if a Kubernetes pod has audit logging enabled. The rule is NON_COMPLIANT if the pod does not have audit logging enabled.1
Attributes
- Section
10.2.1.5: Audit logs are implemented to support the detection of anomalies and suspicious activity, and the forensic analysis of events.
- Service
API Server
10.2.1.5.20Checks if a Kubernetes cluster has logging enabled for audit logs. The rule is NON_COMPLIANT if a Kubernetes cluster does not have audit log export enabled.1
Attributes
- Section
10.2.1.5: Audit logs are implemented to support the detection of anomalies and suspicious activity, and the forensic analysis of events.
- Service
API Server
10.2.1.5.21Checks if Kubernetes Network Policies have logging enabled. The rule is NON_COMPLIANT if a logging type is not configured. You can specify which logging type you want the rule to check.0
Attributes
- Section
10.2.1.5: Audit logs are implemented to support the detection of anomalies and suspicious activity, and the forensic analysis of events.
- Service
Core
10.2.1.5.22Checks if Kubernetes clusters are configured to log audit events to a logging solution. The rule is NON_COMPLIANT if Kubernetes clusters do not have audit logging configured.1
Attributes
- Section
10.2.1.5: Audit logs are implemented to support the detection of anomalies and suspicious activity, and the forensic analysis of events.
- Service
API Server
10.2.1.5.23Checks if the respective logs of Kubernetes pods are enabled. The rule is NON_COMPLIANT if any log settings for the pods are not configured correctly.0
Attributes
- Section
10.2.1.5: Audit logs are implemented to support the detection of anomalies and suspicious activity, and the forensic analysis of events.
- Service
Core
10.2.1.5.24Checks if Kubernetes pods are logging audits to a specific logging service. The rule is NON_COMPLIANT if audit logging is not enabled for a pod or if the 'logDestination' parameter is provided but the logging destination does not match.1
Attributes
- Section
10.2.1.5: Audit logs are implemented to support the detection of anomalies and suspicious activity, and the forensic analysis of events.
- Service
API Server
10.2.1.5.25Checks if Kubernetes clusters have the specified settings. The rule is NON_COMPLIANT if the Kubernetes cluster is not encrypted or uses a different encryption key, or if the cluster does not have auditing enabled.0
Attributes
- Section
10.2.1.5: Audit logs are implemented to support the detection of anomalies and suspicious activity, and the forensic analysis of events.
- Service
Core
10.2.1.5.26Checks if DNS query logging is enabled for your Kubernetes cluster Ingress resources. The rule is NON_COMPLIANT if DNS query logging is not enabled for your Ingress resources.0
Attributes
- Section
10.2.1.5: Audit logs are implemented to support the detection of anomalies and suspicious activity, and the forensic analysis of events.
- Service
API Server
10.2.1.5.27Checks if logging is enabled for your Kubernetes cluster resources. The rule is NON_COMPLIANT if logging is not enabled.0
Attributes
- Section
10.2.1.5: Audit logs are implemented to support the detection of anomalies and suspicious activity, and the forensic analysis of events.
- Service
Core
10.2.1.5.28Checks if a Kubernetes Job has logging enabled. The rule is NON_COMPLIANT if a Job does not have logging enabled or the logging configuration is not at the minimum level provided.0
Attributes
- Section
10.2.1.5: Audit logs are implemented to support the detection of anomalies and suspicious activity, and the forensic analysis of events.
- Service
Kubelet
10.2.1.5.29Checks if Kubernetes Network Policies are configured and enforced for all namespaces. The rule is NON_COMPLIANT if network policies are not enforced for at least one namespace.1
Attributes
- Section
10.2.1.5: Audit logs are implemented to support the detection of anomalies and suspicious activity, and the forensic analysis of events.
- Service
Core
10.2.1.5.30Checks if logging is enabled on Kubernetes Ingress resources. The rule is NON_COMPLIANT if the logging is enabled but the logging destination does not match the expected value.0
Attributes
- Section
10.2.1.5: Audit logs are implemented to support the detection of anomalies and suspicious activity, and the forensic analysis of events.
- Service
API Server
10.2.1.5.31Checks if logging is enabled on the Kubernetes Ingress resource. The Ingress is considered NON_COMPLIANT if it does not have logging enabled for traffic monitoring.0
Attributes
- Section
10.2.1.5: Audit logs are implemented to support the detection of anomalies and suspicious activity, and the forensic analysis of events.
- Service
API Server
10.2.1.6: Audit logs are implemented to support the detection of anomalies and suspicious activity, and the forensic analysis of events.2813
10.2.1.6.1Checks if Kubernetes Ingress resources have access logging enabled. The rule is NON_COMPLIANT if 'access-log' annotation is not present in the Ingress configuration.0
Attributes
- Section
10.2.1.6: Audit logs are implemented to support the detection of anomalies and suspicious activity, and the forensic analysis of events.
- Service
API Server
10.2.1.6.2Checks if all methods in Kubernetes Ingress resources have access logging enabled. The rule is NON_COMPLIANT if access logging is not enabled, or if the log level is neither ERROR nor INFO.0
Attributes
- Section
10.2.1.6: Audit logs are implemented to support the detection of anomalies and suspicious activity, and the forensic analysis of events.
- Service
API Server
10.2.1.6.3Checks if OpenTelemetry tracing is enabled on Kubernetes Ingress resources. The rule is COMPLIANT if OpenTelemetry tracing is enabled and NON_COMPLIANT otherwise.0
Attributes
- Section
10.2.1.6: Audit logs are implemented to support the detection of anomalies and suspicious activity, and the forensic analysis of events.
- Service
API Server
10.2.1.6.4Checks if a Kubernetes API has logging enabled. The rule is NON_COMPLIANT if logging is not enabled, or if the log level is neither ERROR nor ALL.1
Attributes
- Section
10.2.1.6: Audit logs are implemented to support the detection of anomalies and suspicious activity, and the forensic analysis of events.
- Service
API Server
10.2.1.6.5Checks if Kubernetes Services are configured with a specific Session Affinity setting. The rule is NON_COMPLIANT if the Service's Session Affinity does not match the user defined Session Affinity setting.0
Attributes
- Section
10.2.1.6: Audit logs are implemented to support the detection of anomalies and suspicious activity, and the forensic analysis of events.
- Service
Core
10.2.1.6.6Checks if Kubernetes services have access logging configured to an external logging system. The rule is NON_COMPLIANT if a Kubernetes service does not have logging enabled.1
Attributes
- Section
10.2.1.6: Audit logs are implemented to support the detection of anomalies and suspicious activity, and the forensic analysis of events.
- Service
API Server
10.2.1.6.7Checks if at least one Kubernetes Audit Policy is configured to record 'Read' events for all PersistentVolumeClaims (PVCs). The rule is NON_COMPLIANT if there are no Audit Policies that record 'Read' events for PVCs.1
Attributes
- Section
10.2.1.6: Audit logs are implemented to support the detection of anomalies and suspicious activity, and the forensic analysis of events.
- Service
RBAC
10.2.1.6.9Checks if a Kubernetes Pod has at least one logging mechanism enabled. The rule is NON_COMPLIANT if there are no logging configurations set for the Pod.0
Attributes
- Section
10.2.1.6: Audit logs are implemented to support the detection of anomalies and suspicious activity, and the forensic analysis of events.
- Service
Core
10.2.1.6.10Checks if logging is enabled with a valid severity level for Kubernetes deployment events. The rule is NON_COMPLIANT if logging is not enabled or deployment logging has a severity level that is not valid.0
Attributes
- Section
10.2.1.6: Audit logs are implemented to support the detection of anomalies and suspicious activity, and the forensic analysis of events.
- Service
Core
10.2.1.6.11Checks if a Kubernetes cluster has logging enabled for audit logs. The rule is NON_COMPLIANT if the Kubernetes cluster does not have logging enabled for audit logs.1
Attributes
- Section
10.2.1.6: Audit logs are implemented to support the detection of anomalies and suspicious activity, and the forensic analysis of events.
- Service
API Server
10.2.1.6.12Checks if the Kubernetes Cluster has logging enabled for client connections to the API server. The rule is NON_COMPLIANT if 'apiServer.clientConnectionLogging' is set to false.1
Attributes
- Section
10.2.1.6: Audit logs are implemented to support the detection of anomalies and suspicious activity, and the forensic analysis of events.
- Service
API Server
10.2.1.6.13Checks if the logging configuration is set on active Kubernetes Pod specifications. This rule is NON_COMPLIANT if an active Pod does not have a logging configuration defined or if the value for logging is null in at least one container specification.0
Attributes
- Section
10.2.1.6: Audit logs are implemented to support the detection of anomalies and suspicious activity, and the forensic analysis of events.
- Service
Core
10.2.1.6.14Checks if a Kubernetes cluster is configured with logging enabled for all log types (e.g., audit logs, application logs). The rule is NON_COMPLIANT if logging is not enabled for all types in the cluster.1
Attributes
- Section
10.2.1.6: Audit logs are implemented to support the detection of anomalies and suspicious activity, and the forensic analysis of events.
- Service
API Server
10.2.1.6.15Checks if Kubernetes Pods are configured to send logs to a centralized logging service. The rule is NON_COMPLIANT if the value of 'log-driver' is not set to 'fluentd' or 'json-file'.0
Attributes
- Section
10.2.1.6: Audit logs are implemented to support the detection of anomalies and suspicious activity, and the forensic analysis of events.
- Service
Core
10.2.1.6.16Checks if the Kubernetes Ingress and Service resources have logging enabled. The rule is NON_COMPLIANT if the access logs are not configured to store logs in a specified logging backend, or if the logging backend does not match the required configuration.0
Attributes
- Section
10.2.1.6: Audit logs are implemented to support the detection of anomalies and suspicious activity, and the forensic analysis of events.
- Service
API Server
10.2.1.6.17Checks if Kubernetes clusters have audit logging enabled. The rule is NON_COMPLIANT if a cluster does not have audit logging enabled.1
Attributes
- Section
10.2.1.6: Audit logs are implemented to support the detection of anomalies and suspicious activity, and the forensic analysis of events.
- Service
API Server
10.2.1.6.18Checks if a Kubernetes pod has audit logging enabled. The rule is NON_COMPLIANT if the pod does not have audit logging enabled.1
Attributes
- Section
10.2.1.6: Audit logs are implemented to support the detection of anomalies and suspicious activity, and the forensic analysis of events.
- Service
API Server
10.2.1.6.20Checks if a Kubernetes database (such as PostgreSQL) cluster has logging enabled to a logging service (e.g., Fluentd, Elasticsearch) for auditing purposes. The rule is NON_COMPLIANT if the database cluster does not have logging enabled for audit logs.1
Attributes
- Section
10.2.1.6: Audit logs are implemented to support the detection of anomalies and suspicious activity, and the forensic analysis of events.
- Service
API Server
10.2.1.6.21Checks if Kubernetes NetworkPolicies have logging enabled. The rule is NON_COMPLIANT if no logging configuration is specified for the NetworkPolicy. You can specify which logging type to check for, such as audit logging or other logging mechanisms.0
Attributes
- Section
10.2.1.6: Audit logs are implemented to support the detection of anomalies and suspicious activity, and the forensic analysis of events.
- Service
Core
10.2.1.6.22Checks if Kubernetes clusters have audit logging configured to output logs to a specified location. The rule is NON_COMPLIANT if Kubernetes clusters do not have audit log publishing configured.1
Attributes
- Section
10.2.1.6: Audit logs are implemented to support the detection of anomalies and suspicious activity, and the forensic analysis of events.
- Service
API Server
10.2.1.6.24Checks if Kubernetes clusters are logging audits to a specific logging service. The rule is NON_COMPLIANT if audit logging is not enabled for a Kubernetes cluster or if a specific 'loggingDestination' parameter is provided but the audit logging destination does not match.1
Attributes
- Section
10.2.1.6: Audit logs are implemented to support the detection of anomalies and suspicious activity, and the forensic analysis of events.
- Service
API Server
10.2.1.6.25Checks if Kubernetes clusters have the specified settings. The rule is NON_COMPLIANT if the Kubernetes cluster does not have encryption enabled for secrets or if it is using an insecure storage backend, or if an audit logging mechanism is not configured.1
Attributes
- Section
10.2.1.6: Audit logs are implemented to support the detection of anomalies and suspicious activity, and the forensic analysis of events.
- Service
Core
10.2.1.6.26Checks if DNS query logging is enabled for your Kubernetes cluster's CoreDNS configuration. The rule is NON_COMPLIANT if DNS query logging is not enabled for CoreDNS.0
Attributes
- Section
10.2.1.6: Audit logs are implemented to support the detection of anomalies and suspicious activity, and the forensic analysis of events.
- Service
Core
10.2.1.6.27Checks if logging is enabled for your Kubernetes Pods. The rule is NON_COMPLIANT if logging is not enabled.0
Attributes
- Section
10.2.1.6: Audit logs are implemented to support the detection of anomalies and suspicious activity, and the forensic analysis of events.
- Service
Core
10.2.1.6.28Checks if Kubernetes Pods have logging enabled. The rule is NON_COMPLIANT if a Pod does not have logging enabled or the logging configuration is not at the minimum level specified.0
Attributes
- Section
10.2.1.6: Audit logs are implemented to support the detection of anomalies and suspicious activity, and the forensic analysis of events.
- Service
Core
10.2.1.6.29Checks if Kubernetes Network Policies are implemented and enforced for all namespaces. The rule is NON_COMPLIANT if network policies are not enforced for at least one namespace.1
Attributes
- Section
10.2.1.6: Audit logs are implemented to support the detection of anomalies and suspicious activity, and the forensic analysis of events.
- Service
Core
10.2.1.6.30Checks if logging is enabled on Kubernetes Ingress resources. The rule is NON_COMPLIANT if logging is enabled but the logging destination does not match the specified parameter value.0
Attributes
- Section
10.2.1.6: Audit logs are implemented to support the detection of anomalies and suspicious activity, and the forensic analysis of events.
- Service
API Server
10.2.1.6.31Checks if logging is enabled on Kubernetes Ingress controllers. The rule is NON_COMPLIANT for an Ingress resource if it does not have logging enabled.0
Attributes
- Section
10.2.1.6: Audit logs are implemented to support the detection of anomalies and suspicious activity, and the forensic analysis of events.
- Service
API Server
10.2.1.7: Audit logs are implemented to support the detection of anomalies and suspicious activity, and the forensic analysis of events.279
10.2.1.7.1Checks if Kubernetes Ingress resources have access logging enabled. The rule is NON_COMPLIANT if 'access-log' annotation is not present in the Ingress configuration.0
Attributes
- Section
10.2.1.7: Audit logs are implemented to support the detection of anomalies and suspicious activity, and the forensic analysis of events.
- Service
API Server
10.2.1.7.2Checks if all methods in Kubernetes Ingress resources have access logging enabled. The rule is NON_COMPLIANT if access logging is not enabled, or if the logging level is neither ERROR nor INFO.0
Attributes
- Section
10.2.1.7: Audit logs are implemented to support the detection of anomalies and suspicious activity, and the forensic analysis of events.
- Service
API Server
10.2.1.7.3Checks if OpenTelemetry tracing is enabled for Kubernetes Ingress resources. The rule is COMPLIANT if OpenTelemetry tracing is enabled and NON_COMPLIANT otherwise.0
Attributes
- Section
10.2.1.7: Audit logs are implemented to support the detection of anomalies and suspicious activity, and the forensic analysis of events.
- Service
API Server
10.2.1.7.4Checks if a Kubernetes cluster has logging enabled for its pods. The rule is NON_COMPLIANT if logging is not configured, or the log level is neither ERROR nor ALL.0
Attributes
- Section
10.2.1.7: Audit logs are implemented to support the detection of anomalies and suspicious activity, and the forensic analysis of events.
- Service
Core
10.2.1.7.5Checks if Kubernetes Services are configured with a user-defined session affinity mode. The rule is NON_COMPLIANT if the Service's session affinity mode does not match the user-defined session affinity mode.0
Attributes
- Section
10.2.1.7: Audit logs are implemented to support the detection of anomalies and suspicious activity, and the forensic analysis of events.
- Service
Core
10.2.1.7.6Checks if Kubernetes Ingress resources are configured to enable access logging to a designated storage backend. The rule is NON_COMPLIANT if an Ingress resource does not have logging configured.0
Attributes
- Section
10.2.1.7: Audit logs are implemented to support the detection of anomalies and suspicious activity, and the forensic analysis of events.
- Service
API Server
10.2.1.7.7Checks if at least one Kubernetes audit policy is configured to log all requests to all pods and services. The rule is NON_COMPLIANT if there are no audit policies or if they do not record requests to all resources.1
Attributes
- Section
10.2.1.7: Audit logs are implemented to support the detection of anomalies and suspicious activity, and the forensic analysis of events.
- Service
API Server
10.2.1.7.9Checks if a Kubernetes Pod has at least one logging configuration enabled. The rule is NON_COMPLIANT if the status of all present logging configurations is set to 'DISABLED'.0
Attributes
- Section
10.2.1.7: Audit logs are implemented to support the detection of anomalies and suspicious activity, and the forensic analysis of events.
- Service
Core
10.2.1.7.10Checks if logging is enabled with a valid severity level for Kubernetes pod events associated with a target application. The rule is NON_COMPLIANT if logging is not enabled or pod logging severity level for the target application is not valid.0
Attributes
- Section
10.2.1.7: Audit logs are implemented to support the detection of anomalies and suspicious activity, and the forensic analysis of events.
- Service
Core
10.2.1.7.12Checks if the Kubernetes Cluster has logging enabled for connections to services. The rule is NON_COMPLIANT if 'logging.configuration.enabled' is set to false.0
Attributes
- Section
10.2.1.7: Audit logs are implemented to support the detection of anomalies and suspicious activity, and the forensic analysis of events.
- Service
Core
10.2.1.7.13Checks if logConfiguration is set on active Kubernetes Pod specifications. This rule is NON_COMPLIANT if an active Pod does not have a logging configuration specified or if the logging configuration is null in at least one container definition.0
Attributes
- Section
10.2.1.7: Audit logs are implemented to support the detection of anomalies and suspicious activity, and the forensic analysis of events.
- Service
Core
10.2.1.7.14Checks if a Kubernetes cluster is configured with logging enabled. The rule is NON_COMPLIANT if logging for the Kubernetes cluster is not enabled for all log types, including audit logs, application logs, and any other relevant log types.1
Attributes
- Section
10.2.1.7: Audit logs are implemented to support the detection of anomalies and suspicious activity, and the forensic analysis of events.
- Service
API Server
10.2.1.7.15Checks if Kubernetes clusters are configured to send logs to a centralized logging service like Elasticsearch or a monitoring tool like Prometheus. The rule is NON_COMPLIANT if logging is not properly configured or if logs are not being collected.1
Attributes
- Section
10.2.1.7: Audit logs are implemented to support the detection of anomalies and suspicious activity, and the forensic analysis of events.
- Service
API Server
10.2.1.7.16Checks if the Kubernetes Ingress resources have access logging enabled. The rule is NON_COMPLIANT if the access logging is not configured or if the configured logging destination does not match the specified S3 bucket name.0
Attributes
- Section
10.2.1.7: Audit logs are implemented to support the detection of anomalies and suspicious activity, and the forensic analysis of events.
- Service
API Server
10.2.1.7.17Checks if Kubernetes clusters have audit logging enabled. The rule is NON_COMPLIANT if a cluster does not have audit logging enabled.1
Attributes
- Section
10.2.1.7: Audit logs are implemented to support the detection of anomalies and suspicious activity, and the forensic analysis of events.
- Service
API Server
10.2.1.7.18Checks if a Kubernetes cluster has audit logging enabled. The rule is NON_COMPLIANT if the cluster does not have audit logging enabled.1
Attributes
- Section
10.2.1.7: Audit logs are implemented to support the detection of anomalies and suspicious activity, and the forensic analysis of events.
- Service
API Server
10.2.1.7.20Checks if a Kubernetes cluster has audit logging enabled. The rule is NON_COMPLIANT if the Kubernetes cluster does not have audit logging enabled.1
Attributes
- Section
10.2.1.7: Audit logs are implemented to support the detection of anomalies and suspicious activity, and the forensic analysis of events.
- Service
API Server
10.2.1.7.21Checks if Kubernetes Network Policies have logging enabled. The rule is NON_COMPLIANT if a logging type is not configured. You can specify which logging type you want the rule to check.0
Attributes
- Section
10.2.1.7: Audit logs are implemented to support the detection of anomalies and suspicious activity, and the forensic analysis of events.
- Service
API Server
10.2.1.7.23Checks if the respective logs of Kubernetes pods are enabled. The rule is NON_COMPLIANT if any log types are not enabled.0
Attributes
- Section
10.2.1.7: Audit logs are implemented to support the detection of anomalies and suspicious activity, and the forensic analysis of events.
- Service
Core
10.2.1.7.24Checks if Kubernetes clusters are auditing logs to a specific logging service. The rule is NON_COMPLIANT if audit logging is not enabled for a Kubernetes cluster or if the 'logDestination' parameter is provided but the audit logging destination does not match.1
Attributes
- Section
10.2.1.7: Audit logs are implemented to support the detection of anomalies and suspicious activity, and the forensic analysis of events.
- Service
API Server
10.2.1.7.25Checks if Kubernetes clusters have the specified settings. The rule is NON_COMPLIANT if the Kubernetes cluster is not using Role-Based Access Control (RBAC) or if a cluster does not have audit logging enabled.1
Attributes
- Section
10.2.1.7: Audit logs are implemented to support the detection of anomalies and suspicious activity, and the forensic analysis of events.
- Service
API Server
10.2.1.7.26Checks if DNS logging is enabled for your Kubernetes cluster's CoreDNS or kube-dns configuration. The rule is NON_COMPLIANT if DNS query logging is not enabled for the DNS service in the cluster.0
Attributes
- Section
10.2.1.7: Audit logs are implemented to support the detection of anomalies and suspicious activity, and the forensic analysis of events.
- Service
API Server
10.2.1.7.27Checks if logging is enabled for your Kubernetes Pods. The rule is NON_COMPLIANT if logging is not enabled.0
Attributes
- Section
10.2.1.7: Audit logs are implemented to support the detection of anomalies and suspicious activity, and the forensic analysis of events.
- Service
Core
10.2.1.7.28Checks if Kubernetes workloads have logging enabled. The rule is NON_COMPLIANT if a workload does not have logging enabled or the logging configuration does not meet the minimum specified requirements.0
Attributes
- Section
10.2.1.7: Audit logs are implemented to support the detection of anomalies and suspicious activity, and the forensic analysis of events.
- Service
Core
10.2.1.7.29Checks if Kubernetes Network Policies are configured and applied for all namespaces. The rule is NON_COMPLIANT if network policies are not applied in at least one namespace.1
Attributes
- Section
10.2.1.7: Audit logs are implemented to support the detection of anomalies and suspicious activity, and the forensic analysis of events.
- Service
Core
10.2.1.7.30Checks if logging is enabled on Kubernetes Network Policies. The rule is NON_COMPLIANT if logging is enabled but the logging destination does not match the expected values.0
Attributes
- Section
10.2.1.7: Audit logs are implemented to support the detection of anomalies and suspicious activity, and the forensic analysis of events.
- Service
API Server
10.2.1.7.31Checks if logging is enabled on Kubernetes Ingress resources. The rule is NON_COMPLIANT for an Ingress resource if it does not have logging enabled.0
Attributes
- Section
10.2.1.7: Audit logs are implemented to support the detection of anomalies and suspicious activity, and the forensic analysis of events.
- Service
API Server
10.2.2: Audit logs are implemented to support the detection of anomalies and suspicious activity, and the forensic analysis of events.2811
10.2.2.1Checks if Kubernetes Ingress resources have access logging enabled. The rule is NON_COMPLIANT if access logging annotations are not present in the Ingress resource configuration.0
Attributes
- Section
10.2.2: Audit logs are implemented to support the detection of anomalies and suspicious activity, and the forensic analysis of events.
- Service
API Server
10.2.2.2Checks if all methods in Kubernetes Ingress have access logging enabled. The rule is NON_COMPLIANT if access logging is not enabled or if the log level is neither ERROR nor INFO.0
Attributes
- Section
10.2.2: Audit logs are implemented to support the detection of anomalies and suspicious activity, and the forensic analysis of events.
- Service
API Server
10.2.2.3Checks if OpenTelemetry tracing is enabled for Kubernetes services. The rule is COMPLIANT if OpenTelemetry tracing is enabled and NON_COMPLIANT otherwise.0
Attributes
- Section
10.2.2: Audit logs are implemented to support the detection of anomalies and suspicious activity, and the forensic analysis of events.
- Service
Core
10.2.2.4Checks if a Kubernetes API server has audit logging enabled. The rule is NON_COMPLIANT if audit logging is not configured or 'audit-log-path' does not have a valid path set.1
Attributes
- Section
10.2.2: Audit logs are implemented to support the detection of anomalies and suspicious activity, and the forensic analysis of events.
- Service
API Server
10.2.2.5Checks if Kubernetes Services are configured with appropriate LoadBalancer settings. The rule is NON_COMPLIANT if the Service's LoadBalancer settings do not match the user-defined configurations for handling desynchronization scenarios.0
Attributes
- Section
10.2.2: Audit logs are implemented to support the detection of anomalies and suspicious activity, and the forensic analysis of events.
- Service
Core
10.2.2.6Checks if Kubernetes Ingress resources are configured to enable access logging. The rule is NON_COMPLIANT if an Ingress resource does not have access logging configured.0
Attributes
- Section
10.2.2: Audit logs are implemented to support the detection of anomalies and suspicious activity, and the forensic analysis of events.
- Service
Core
10.2.2.7Checks if at least one Kubernetes Audit Policy is configured to log access to all Pods in the cluster. The rule is NON_COMPLIANT if there are no audit policies or if no policies log Pod access events.1
Attributes
- Section
10.2.2: Audit logs are implemented to support the detection of anomalies and suspicious activity, and the forensic analysis of events.
- Service
API Server
10.2.2.9Checks if a Kubernetes Pod has at least one logging option enabled. The rule is NON_COMPLIANT if the status of all present logging configurations is set to 'DISABLED'.0
Attributes
- Section
10.2.2: Audit logs are implemented to support the detection of anomalies and suspicious activity, and the forensic analysis of events.
- Service
Core
10.2.2.10Checks if logging is enabled with a valid severity level for a Kubernetes Deployment's application logs. The rule is NON_COMPLIANT if logging is not enabled or application logging has a severity level that is not valid.0
Attributes
- Section
10.2.2: Audit logs are implemented to support the detection of anomalies and suspicious activity, and the forensic analysis of events.
- Service
Core
10.2.2.11Checks if a Kubernetes cluster has logging enabled for audit logs. The rule is NON_COMPLIANT if the Kubernetes cluster does not have audit logging enabled.1
Attributes
- Section
10.2.2: Audit logs are implemented to support the detection of anomalies and suspicious activity, and the forensic analysis of events.
- Service
API Server
10.2.2.12Checks if Kubernetes API server has audit logging enabled. The rule is NON_COMPLIANT if 'audit-log-path' is set to an empty value or audit logging is not configured.1
Attributes
- Section
10.2.2: Audit logs are implemented to support the detection of anomalies and suspicious activity, and the forensic analysis of events.
- Service
API Server
10.2.2.13Checks if logging is configured for active Kubernetes Pods. This rule is NON_COMPLIANT if an active Pod does not have logging configured, or the value for logging is null in at least one container definition.0
Attributes
- Section
10.2.2: Audit logs are implemented to support the detection of anomalies and suspicious activity, and the forensic analysis of events.
- Service
Core
10.2.2.14Checks if a Kubernetes cluster has logging enabled for all log types, such as audit logs, application logs, and cluster logs. The rule is NON_COMPLIANT if logging for the Kubernetes cluster is not enabled for all log types.1
Attributes
- Section
10.2.2: Audit logs are implemented to support the detection of anomalies and suspicious activity, and the forensic analysis of events.
- Service
API Server
10.2.2.15Checks if Kubernetes Pods are configured to send logs to a centralized logging system (e.g., Fluentd or Elasticsearch). The rule is NON_COMPLIANT if the logging driver or configuration is not set to forward logs.0
Attributes
- Section
10.2.2: Audit logs are implemented to support the detection of anomalies and suspicious activity, and the forensic analysis of events.
- Service
Core
10.2.2.16Checks if the Kubernetes Ingress resources have access logging enabled. The rule is NON_COMPLIANT if the access logging is not configured correctly or pointing to the specified S3 bucket for log storage.0
Attributes
- Section
10.2.2: Audit logs are implemented to support the detection of anomalies and suspicious activity, and the forensic analysis of events.
- Service
API Server
10.2.2.17Checks if Kubernetes brokers (such as those created with Strimzi or similar tools) have logging enabled for auditing (e.g., using Fluentd, Elasticsearch, and Kibana). The rule is NON_COMPLIANT if a broker does not have audit logging enabled.0
Attributes
- Section
10.2.2: Audit logs are implemented to support the detection of anomalies and suspicious activity, and the forensic analysis of events.
- Service
Core
10.2.2.18Checks if a Kubernetes pod has audit logging enabled. The rule is NON_COMPLIANT if the pod does not have audit logging enabled.1
Attributes
- Section
10.2.2: Audit logs are implemented to support the detection of anomalies and suspicious activity, and the forensic analysis of events.
- Service
API Server
10.2.2.20Checks if a Kubernetes cluster has logging enabled for audit logs. The rule is NON_COMPLIANT if a Kubernetes cluster does not have logging enabled for audit logs.1
Attributes
- Section
10.2.2: Audit logs are implemented to support the detection of anomalies and suspicious activity, and the forensic analysis of events.
- Service
API Server
10.2.2.21Checks if Kubernetes Network Policies have logging enabled. The rule is NON_COMPLIANT if a logging type is not configured for traffic policies. You can specify which logging type you want the rule to check.0
Attributes
- Section
10.2.2: Audit logs are implemented to support the detection of anomalies and suspicious activity, and the forensic analysis of events.
- Service
API Server
10.2.2.23Checks if the respective logs of the Kubernetes cluster (such as auditing, application logs, or container logs) are enabled. The rule is NON_COMPLIANT if any logging mechanisms are not enabled.1
Attributes
- Section
10.2.2: Audit logs are implemented to support the detection of anomalies and suspicious activity, and the forensic analysis of events.
- Service
API Server
10.2.2.24Checks if Kubernetes clusters are logging audits to a specific logging service. The rule is NON_COMPLIANT if audit logging is not enabled for a Kubernetes cluster or if the 'logDestination' parameter is provided but the audit logging destination does not match.1
Attributes
- Section
10.2.2: Audit logs are implemented to support the detection of anomalies and suspicious activity, and the forensic analysis of events.
- Service
API Server
10.2.2.25Checks if Kubernetes clusters have the specified settings. The rule is NON_COMPLIANT if the Kubernetes cluster does not have encryption for etcd enabled, or if the cluster does not have audit logging enabled.1
Attributes
- Section
10.2.2: Audit logs are implemented to support the detection of anomalies and suspicious activity, and the forensic analysis of events.
- Service
ETCD
10.2.2.26Checks if DNS query logging is enabled for your Kubernetes cluster's CoreDNS configurations. The rule is NON_COMPLIANT if DNS query logging is not enabled for the CoreDNS service associated with the cluster's ingress traffic management.0
Attributes
- Section
10.2.2: Audit logs are implemented to support the detection of anomalies and suspicious activity, and the forensic analysis of events.
- Service
Core
10.2.2.27Checks if logging is enabled for your Kubernetes clusters. The rule is NON_COMPLIANT if logging is not enabled.0
Attributes
- Section
10.2.2: Audit logs are implemented to support the detection of anomalies and suspicious activity, and the forensic analysis of events.
- Service
Core
10.2.2.28Checks if a Kubernetes Pod has logging enabled. The rule is NON_COMPLIANT if a Pod does not have logging enabled or the logging configuration is not at the minimum level provided.0
Attributes
- Section
10.2.2: Audit logs are implemented to support the detection of anomalies and suspicious activity, and the forensic analysis of events.
- Service
Core
10.2.2.29Checks if Kubernetes Network Policies are configured and enforced for all namespaces. The rule is NON_COMPLIANT if Network Policies are not enabled for at least one namespace.1
Attributes
- Section
10.2.2: Audit logs are implemented to support the detection of anomalies and suspicious activity, and the forensic analysis of events.
- Service
Core
10.2.2.30Checks if logging is enabled on Kubernetes Ingress resources. The rule is NON_COMPLIANT if logging is enabled but the logging destination does not match the specified configuration.0
Attributes
- Section
10.2.2: Audit logs are implemented to support the detection of anomalies and suspicious activity, and the forensic analysis of events.
- Service
API Server
10.2.2.31Checks if logging is enabled on Kubernetes Ingress resources. The rule is NON_COMPLIANT for an Ingress resource, if it does not have logging enabled.0
Attributes
- Section
10.2.2: Audit logs are implemented to support the detection of anomalies and suspicious activity, and the forensic analysis of events.
- Service
API Server
10.3.1: Audit logs are protected from destruction and unauthorized modifications.2812
10.3.1.1Checks if Kubernetes Ingress resources have access logging enabled. The rule is NON_COMPLIANT if access logging configuration is not defined in the Ingress resource annotations.0
Attributes
- Section
10.3.1: Audit logs are protected from destruction and unauthorized modifications.
- Service
API Server
10.3.1.2Checks if all methods in Kubernetes Ingress resources have access logging enabled. The rule is NON_COMPLIANT if logging is not enabled, or if log level is neither ERROR nor INFO.0
Attributes
- Section
10.3.1: Audit logs are protected from destruction and unauthorized modifications.
- Service
API Server
10.3.1.3Checks if OpenTelemetry tracing is enabled on Kubernetes Ingress controllers. The rule is COMPLIANT if OpenTelemetry tracing is enabled and NON_COMPLIANT otherwise.0
Attributes
- Section
10.3.1: Audit logs are protected from destruction and unauthorized modifications.
- Service
API Server
10.3.1.4Checks if a Kubernetes API server has audit logging enabled. The rule is NON_COMPLIANT if audit logging is not enabled, or 'audit.log.level' is neither 'ERROR' nor 'ALL'.1
Attributes
- Section
10.3.1: Audit logs are protected from destruction and unauthorized modifications.
- Service
API Server
10.3.1.5Checks if Kubernetes Services that use LoadBalancer type are configured with a user-defined externalTrafficPolicy. The rule is NON_COMPLIANT if the externalTrafficPolicy does not match the user-defined externalTrafficPolicy.1
Attributes
- Section
10.3.1: Audit logs are protected from destruction and unauthorized modifications.
- Service
API Server
10.3.1.6Checks if Kubernetes Ingress resources are configured to enable access logging to a specified logging service (e.g., Fluentd or a centralized logging system). The rule is NON_COMPLIANT if an Ingress resource does not have logging configured.0
Attributes
- Section
10.3.1: Audit logs are protected from destruction and unauthorized modifications.
- Service
API Server
10.3.1.7Checks if at least one Kubernetes Audit Policy is enforcing the logging of access events for all pods in the cluster. The rule is NON_COMPLIANT if there are no audit logs or if the audit policies do not record access events for pods.1
Attributes
- Section
10.3.1: Audit logs are protected from destruction and unauthorized modifications.
- Service
API Server
10.3.1.8The Kubernetes equivalent of enabling CloudTrail would be to ensure that logging and monitoring services are set up for tracking user activity and changes within the cluster. This typically involves using tools like Fluentd, Elasticsearch, Kibana (the EFK stack), or Kubernetes' built-in audit logging.0
Attributes
- Section
10.3.1: Audit logs are protected from destruction and unauthorized modifications.
- Service
Core
10.3.1.9Checks if a Kubernetes Pod has at least one logging option enabled. The rule is NON_COMPLIANT if the status of all present log configurations is set to 'DISABLED'.0
Attributes
- Section
10.3.1: Audit logs are protected from destruction and unauthorized modifications.
- Service
Core
10.3.1.10Checks if logging is enabled with a valid severity level for Kubernetes pod events. The rule is NON_COMPLIANT if logging is not enabled or pod event logging has a severity level that is not valid.0
Attributes
- Section
10.3.1: Audit logs are protected from destruction and unauthorized modifications.
- Service
Core
10.3.1.12Checks if the Kubernetes cluster has client connection logging enabled in the Ingress controller. The status is NON_COMPLIANT if 'clientLogging.enabled' is set to false.0
Attributes
- Section
10.3.1: Audit logs are protected from destruction and unauthorized modifications.
- Service
API Server
10.3.1.13Checks if logging is configured for active Kubernetes Pods. This rule is NON_COMPLIANT if an active Pod does not have a logging configuration set or the logging configuration is null in at least one container specification.0
Attributes
- Section
10.3.1: Audit logs are protected from destruction and unauthorized modifications.
- Service
Core
10.3.1.14Checks if a Kubernetes cluster is configured with logging enabled. The rule is NON_COMPLIANT if logging for the Kubernetes cluster is not enabled for all log types, such as audit logs, application logs, and container logs.1
Attributes
- Section
10.3.1: Audit logs are protected from destruction and unauthorized modifications.
- Service
API Server
10.3.1.15Checks if Kubernetes pods are configured to send logs to a centralized logging system (like Fluentd, ELK stack, or any other log management solution). The rule is NON_COMPLIANT if the logging configuration does not forward logs to the configured logging system.0
Attributes
- Section
10.3.1: Audit logs are protected from destruction and unauthorized modifications.
- Service
Core
10.3.1.16Checks if the Kubernetes Service of type LoadBalancer has logging enabled. The rule is NON_COMPLIANT if the service does not have an annotation for logging enabled or the designated logging namespace does not match the expected value.0
Attributes
- Section
10.3.1: Audit logs are protected from destruction and unauthorized modifications.
- Service
Core
10.3.1.17Checks if Kubernetes Pods have auditing enabled. The rule is NON_COMPLIANT if a Pod does not have auditing enabled.1
Attributes
- Section
10.3.1: Audit logs are protected from destruction and unauthorized modifications.
- Service
API Server
10.3.1.18Checks if a Kubernetes cluster has audit logging enabled. The rule is NON_COMPLIANT if the audit logging is not enabled.1
Attributes
- Section
10.3.1: Audit logs are protected from destruction and unauthorized modifications.
- Service
API Server
10.3.1.20Checks if a Kubernetes cluster has logging enabled for audit logs. The rule is NON_COMPLIANT if the Kubernetes cluster does not have audit logging enabled.1
Attributes
- Section
10.3.1: Audit logs are protected from destruction and unauthorized modifications.
- Service
API Server
10.3.1.21Checks if Kubernetes Network Policies have logging enabled. The rule is NON_COMPLIANT if logging is not configured for the Network Policies. You can specify which logging type you want the rule to check.0
Attributes
- Section
10.3.1: Audit logs are protected from destruction and unauthorized modifications.
- Service
API Server
10.3.1.22Checks if Kubernetes clusters are configured to log audit events to a specified logging solution. The rule is NON_COMPLIANT if Kubernetes clusters do not have audit logging configured.1
Attributes
- Section
10.3.1: Audit logs are protected from destruction and unauthorized modifications.
- Service
API Server
10.3.1.23Checks if the necessary logging is enabled for the Kubernetes cluster and its components. The rule is NON_COMPLIANT if any required log types, such as audit logs or application logs, are not enabled.1
Attributes
- Section
10.3.1: Audit logs are protected from destruction and unauthorized modifications.
- Service
API Server
10.3.1.24Checks if Kubernetes clusters are logging audits to a specific logging service. The rule is NON_COMPLIANT if audit logging is not enabled for a Kubernetes cluster or if the specified logging destination does not match the expected service.1
Attributes
- Section
10.3.1: Audit logs are protected from destruction and unauthorized modifications.
- Service
API Server
10.3.1.25Checks if Kubernetes clusters have the specified security settings. The rule is NON_COMPLIANT if the Kubernetes cluster is not using encryption for secrets or configurations, or if audit logging is not enabled for the cluster.1
Attributes
- Section
10.3.1: Audit logs are protected from destruction and unauthorized modifications.
- Service
RBAC
10.3.1.26Checks if CoreDNS logging is enabled for your Kubernetes cluster. The rule is NON_COMPLIANT if CoreDNS logging is not enabled for your Kubernetes cluster.0
Attributes
- Section
10.3.1: Audit logs are protected from destruction and unauthorized modifications.
- Service
Core
10.3.1.27Checks if logging is enabled for your Kubernetes pods. The rule is NON_COMPLIANT if logging is not enabled.0
Attributes
- Section
10.3.1: Audit logs are protected from destruction and unauthorized modifications.
- Service
Core
10.3.1.29Checks if Kubernetes Network Policies are defined and enforced for all namespaces. The rule is NON_COMPLIANT if network policies are not configured for at least one namespace.1
Attributes
- Section
10.3.1: Audit logs are protected from destruction and unauthorized modifications.
- Service
Core
10.3.1.30Checks if logging is enabled on Kubernetes Ingress resources. The rule is NON_COMPLIANT if logging is enabled but the logging destination does not match the expected destination parameter.0
Attributes
- Section
10.3.1: Audit logs are protected from destruction and unauthorized modifications.
- Service
API Server
10.3.1.31Checks if logging is enabled on Kubernetes Ingress resources. The rule is NON_COMPLIANT for an Ingress resource, if it does not have logging enabled.0
Attributes
- Section
10.3.1: Audit logs are protected from destruction and unauthorized modifications.
- Service
Core
10.3.2: Audit logs are protected from destruction and unauthorized modifications.2620
10.3.2.1Checks if a Kubernetes namespace has an associated Network Policy that prevents pod egress. The rule is NON_COMPLIANT if the namespace does not have network policies or has policies that do not include appropriate deny rules for egress traffic (rules that restrict access to external services).0
Attributes
- Section
10.3.2: Audit logs are protected from destruction and unauthorized modifications.
- Service
Core
10.3.2.2Checks that there is at least one Kubernetes Audit Policy defined with security best practices. This rule is COMPLIANT if there is at least one audit policy that meets all of the following:1
Attributes
- Section
10.3.2: Audit logs are protected from destruction and unauthorized modifications.
- Service
API Server
10.3.2.3Checks if Kubernetes secrets are encrypted at rest using a specified encryption provider configuration. The rule is NON_COMPLIANT if a secret is not encrypted or is encrypted with a key not specified in the rule parameters.1
Attributes
- Section
10.3.2: Audit logs are protected from destruction and unauthorized modifications.
- Service
API Server
10.3.2.4Checks if Kubernetes Secrets are configured to use encryption at rest. The rule is COMPLIANT if the encryption configuration is defined in the Kubernetes cluster.1
Attributes
- Section
10.3.2: Audit logs are protected from destruction and unauthorized modifications.
- Service
API Server
10.3.2.5Checks if Kubernetes audit logging is enabled and configured properly. It is recommended that audit logging is enabled for all clusters to ensure logs are validated for compliance. The rule is NON_COMPLIANT if audit logging is not enabled or misconfigured.1
Attributes
- Section
10.3.2: Audit logs are protected from destruction and unauthorized modifications.
- Service
API Server
10.3.2.6Checks if Kubernetes Services are exposed publicly. The rule is NON_COMPLIANT if the service type is set to LoadBalancer or if the service has an External IP.1
Attributes
- Section
10.3.2: Audit logs are protected from destruction and unauthorized modifications.
- Service
API Server
10.3.2.7Checks if Kubernetes PersistentVolume (PV) snapshots are public. The rule is NON_COMPLIANT if any Kubernetes PersistentVolume snapshots are public.1
Attributes
- Section
10.3.2: Audit logs are protected from destruction and unauthorized modifications.
- Service
RBAC
10.3.2.8Checks if Kubernetes Persistent Volumes (PVs) are not publicly accessible. The rule is NON_COMPLIANT if one or more Persistent Volumes have the accessModes field set to 'ReadWriteMany' allowing multiple pods (potentially from different namespaces) to access the volume, making it publicly accessible.1
Attributes
- Section
10.3.2: Audit logs are protected from destruction and unauthorized modifications.
- Service
RBAC
10.3.2.9Checks if Kubernetes Pods have read-only access to their root filesystems. The rule is NON_COMPLIANT if the readOnlyRootFilesystem field in the Pod's security context is set to 'false'.1
Attributes
- Section
10.3.2: Audit logs are protected from destruction and unauthorized modifications.
- Service
Core
10.3.2.10Checks if Kubernetes Persistent Volumes (PVs) are configured to enforce a specific mount path. The rule is NON_COMPLIANT if the value of 'mountPath' is set to '/' (default root directory).1
Attributes
- Section
10.3.2: Audit logs are protected from destruction and unauthorized modifications.
- Service
RBAC
10.3.2.11Checks if Kubernetes persistent volume claims (PVC) access modes are configured to enforce a user identity. The rule is NON_COMPLIANT if access modes do not enforce the required security context or if parameters provided in the PVC do not match the expected configuration.1
Attributes
- Section
10.3.2: Audit logs are protected from destruction and unauthorized modifications.
- Service
RBAC
10.3.2.12Checks if a Kubernetes cluster has public access settings correctly configured for its services. The rule is NON_COMPLIANT if 'AllowExternalAccess' is set to true and there are services exposed to the public via LoadBalancer or NodePort types, except for port 22.1
Attributes
- Section
10.3.2: Audit logs are protected from destruction and unauthorized modifications.
- Service
API Server
10.3.2.13Checks if the Kubernetes Service policy attached to the Service resource prohibits public access. If the Service policy allows public access, it is NON_COMPLIANT.0
Attributes
- Section
10.3.2: Audit logs are protected from destruction and unauthorized modifications.
- Service
Core
10.3.2.14Checks if a Kubernetes persistent volume is publicly accessible. The rule is NON_COMPLIANT if any existing or new persistent volume is exposed to the public.1
Attributes
- Section
10.3.2: Audit logs are protected from destruction and unauthorized modifications.
- Service
RBAC
10.3.2.15Checks if the Kubernetes database service (e.g., PostgreSQL, MySQL) instances are not exposed to the external network. The rule is NON_COMPLIANT if the service type is 'LoadBalancer' or if there's an ingress route allowing external traffic.0
Attributes
- Section
10.3.2: Audit logs are protected from destruction and unauthorized modifications.
- Service
Core
10.3.2.16Checks if Kubernetes Persistent Volume (PV) claims are publicly accessible. The rule is NON_COMPLIANT if any existing and new Persistent Volumes are configured inappropriately, allowing public access.1
Attributes
- Section
10.3.2: Audit logs are protected from destruction and unauthorized modifications.
- Service
RBAC
10.3.2.17Checks if Kubernetes clusters are not publicly accessible. The rule is NON_COMPLIANT if the cluster's LoadBalancer service has an external IP configured, allowing public access.1
Attributes
- Section
10.3.2: Audit logs are protected from destruction and unauthorized modifications.
- Service
API Server
10.3.2.18Checks if Kubernetes services have network policies that restrict public access. The rule is NON_COMPLIANT if network policies are not enforced for services that are exposed to the public.1
Attributes
- Section
10.3.2: Audit logs are protected from destruction and unauthorized modifications.
- Service
Core
10.3.2.19Checks if the required network policies are configured to restrict public access to Kubernetes services. The rule is only NON_COMPLIANT when the network policy settings do not align with the expected configuration.1
Attributes
- Section
10.3.2: Audit logs are protected from destruction and unauthorized modifications.
- Service
Core
10.3.2.20Checks if the required Network Policies for public access are configured at the namespace level. The rule is NON_COMPLIANT if the Network Policies do not match one or more settings from parameters (or default).0
Attributes
- Section
10.3.2: Audit logs are protected from destruction and unauthorized modifications.
- Service
Core
10.3.2.21Checks if Kubernetes services are publicly accessible. The rule is NON_COMPLIANT if a service is not listed in the excludedPublicServices parameter and service type is 'LoadBalancer' or has a public IP.1
Attributes
- Section
10.3.2: Audit logs are protected from destruction and unauthorized modifications.
- Service
API Server
10.3.2.22Checks if two-factor authentication (2FA) is enabled for Kubernetes secrets management. The rule is NON_COMPLIANT if 2FA is not enabled.0
Attributes
- Section
10.3.2: Audit logs are protected from destruction and unauthorized modifications.
- Service
Core
10.3.2.23Checks if your Kubernetes storage classes do not allow public access. The rule checks the security context, role-based access control (RBAC) settings, and the PersistentVolumeClaims (PVCs) configurations.1
Attributes
- Section
10.3.2: Audit logs are protected from destruction and unauthorized modifications.
- Service
RBAC
10.3.2.24Checks if your Kubernetes Persistent Volume Claims (PVCs) do not allow public write access. The rule evaluates the Access Modes settings, the Persistent Volume (PV) policies, and any associated Role-Based Access Control (RBAC) configurations.1
Attributes
- Section
10.3.2: Audit logs are protected from destruction and unauthorized modifications.
- Service
RBAC
10.3.2.25Checks if direct internet access is disabled for a Kubernetes Pod. The rule is NON_COMPLIANT if a Pod is configured with Internet access through a NetworkPolicy that allows external traffic.0
Attributes
- Section
10.3.2: Audit logs are protected from destruction and unauthorized modifications.
- Service
Core
10.3.2.26Checks if Kubernetes ConfigMaps owned by the namespace are accessible publicly. The rule is NON_COMPLIANT if ConfigMaps with the owner 'Self' are exposed to external traffic.1
Attributes
- Section
10.3.2: Audit logs are protected from destruction and unauthorized modifications.
- Service
Core
10.3.3: Audit logs are protected from destruction and unauthorized modifications.2111
10.3.3.1Checks if Kubernetes database instances (such as PostgreSQL or MySQL running on Kubernetes) are protected by a backup plan. The rule is NON_COMPLIANT if the database instance is not protected by a backup plan.0
Attributes
- Section
10.3.3: Audit logs are protected from destruction and unauthorized modifications.
- Service
Core
10.3.3.2Verifies that a Kubernetes backup policy contains a backup schedule that meets the necessary interval and retention settings. The policy is marked NON_COMPLIANT if backup jobs are not executed at least as frequently as defined in the schedule or if backup artifacts are deleted before the defined retention duration.0
Attributes
- Section
10.3.3: Audit logs are protected from destruction and unauthorized modifications.
- Service
Kubernetes Backup Operator
10.3.3.3In Kubernetes, this checks if a backup retention policy for persistent volumes is set to retain backups for at least the specified duration. The policy is classified as NON_COMPLIANT if the configured retention duration is shorter than the required period.0
Attributes
- Section
10.3.3: Audit logs are protected from destruction and unauthorized modifications.
- Service
Kubernetes Persistent Volume Management
10.3.3.4Checks that there is at least one Kubernetes audit log configuration defined with security best practices. This rule is COMPLIANT if there is at least one configuration that meets all of the following criteria: audit logs are enabled, retention policies are set, and sensitive request logging is implemented.1
Attributes
- Section
10.3.3: Audit logs are protected from destruction and unauthorized modifications.
- Service
API Server
10.3.3.5Checks if Kubernetes Persistent Volume Claims (PVCs) are using encrypted storage classes with specific encryption keys. The rule is NON_COMPLIANT if a PVC is not using an encrypted storage class or is using an encryption key not specified in the rule parameter.1
Attributes
- Section
10.3.3: Audit logs are protected from destruction and unauthorized modifications.
- Service
RBAC
10.3.3.6Checks if Kubernetes Secrets are created with encryption at rest enabled. The rule is COMPLIANT if the 'encryption' key is defined in the Kubernetes configuration.1
Attributes
- Section
10.3.3: Audit logs are protected from destruction and unauthorized modifications.
- Service
API Server
10.3.3.7Checks if Kubernetes Audit Logging is configured to generate logs with proper validation. Kubernetes recommends that log validation must be enabled for auditing to ensure integrity and reliability of the logs. The rule is NON_COMPLIANT if audit logging validation is not enabled.1
Attributes
- Section
10.3.3: Audit logs are protected from destruction and unauthorized modifications.
- Service
API Server
10.3.3.9Checks whether a Kubernetes Persistent Volume (PV) is included in a Backup Storage Class. The rule is NON_COMPLIANT if Persistent Volumes are not present in any Backup Storage Class.0
Attributes
- Section
10.3.3: Audit logs are protected from destruction and unauthorized modifications.
- Service
Core
10.3.3.10Checks if point-in-time recovery (PITR) is enabled for Kubernetes etcd clusters. The rule is NON_COMPLIANT if PITR is not enabled for etcd clusters.0
Attributes
- Section
10.3.3: Audit logs are protected from destruction and unauthorized modifications.
- Service
etcd
10.3.3.11Checks if Kubernetes Persistent Volumes are protected by a backup plan. The rule is NON_COMPLIANT if the Persistent Volume is not covered by a backup plan.1
Attributes
- Section
10.3.3: Audit logs are protected from destruction and unauthorized modifications.
- Service
RBAC
10.3.3.12Check if Kubernetes Persistent Volumes (PVs) are included in backup plans. The rule is NON_COMPLIANT if Persistent Volumes are not included in backup plans.0
Attributes
- Section
10.3.3: Audit logs are protected from destruction and unauthorized modifications.
- Service
Core
10.3.3.13Checks if Kubernetes Persistent Volumes (PVs) are protected by a backup plan. The rule is NON_COMPLIANT if the Persistent Volume is not covered by a backup plan.1
Attributes
- Section
10.3.3: Audit logs are protected from destruction and unauthorized modifications.
- Service
RBAC
10.3.3.14Checks if Kubernetes Pods are protected by a backup plan. The rule is NON_COMPLIANT if the Kubernetes Pod is not covered by a backup plan.0
Attributes
- Section
10.3.3: Audit logs are protected from destruction and unauthorized modifications.
- Service
Core
10.3.3.15Checks if Persistent Volume Claims (PVCs) that are backed by Persistent Volumes (PVs) are included in backup plans for Kubernetes clusters. The rule is NON_COMPLIANT if PVCs backed by PVs are not included in the backup plans.1
Attributes
- Section
10.3.3: Audit logs are protected from destruction and unauthorized modifications.
- Service
RBAC
10.3.3.16Checks if Kubernetes Persistent Volumes (PVs) are protected by a backup policy. The rule is NON_COMPLIANT if the PV is not covered by a backup policy.0
Attributes
- Section
10.3.3: Audit logs are protected from destruction and unauthorized modifications.
- Service
Core
10.3.3.17Check if the Kubernetes Redis Deployment has automatic backups turned on. The rule is NON_COMPLIANT if the backup retention period for the Redis Deployment is less than the specified backup retention limit. For example: If the parameter is 15 days, then the rule is non-compliant if the backup retention period is between 0-15 days.0
Attributes
- Section
10.3.3: Audit logs are protected from destruction and unauthorized modifications.
- Service
Redis Deployment
10.3.3.18Checks if Kubernetes Persistent Volumes are protected by a backup plan. The rule is NON_COMPLIANT if the Persistent Volume is not covered by a backup plan.1
Attributes
- Section
10.3.3: Audit logs are protected from destruction and unauthorized modifications.
- Service
RBAC
10.3.3.21Checks if Kubernetes persistent volumes are protected by a backup plan. The rule is NON_COMPLIANT if the persistent volume is not covered by a backup plan.0
Attributes
- Section
10.3.3: Audit logs are protected from destruction and unauthorized modifications.
- Service
Core
10.3.3.22Checks that Kubernetes persistent volume claims (PVCs) are configured with appropriate storage requests that are not less than the minimum required size and not greater than the maximum allowed size. The rule is NON_COMPLIANT if the size of the PVC is less than MinStorageSize or greater than MaxStorageSize.1
Attributes
- Section
10.3.3: Audit logs are protected from destruction and unauthorized modifications.
- Service
RBAC
10.3.3.23Checks if Kubernetes Services are publicly accessible. The rule is NON_COMPLIANT if a Service is not listed in the excludedPublicServices parameter and its type is LoadBalancer or NodePort.1
Attributes
- Section
10.3.3: Audit logs are protected from destruction and unauthorized modifications.
- Service
API Server
10.3.3.24Checks if Kubernetes persistent volume claims (PVCs) are protected by a backup solution. The rule is NON_COMPLIANT if the persistent volume claims are not covered by a backup plan.1
Attributes
- Section
10.3.3: Audit logs are protected from destruction and unauthorized modifications.
- Service
RBAC
10.3.4: Audit logs are protected from destruction and unauthorized modifications.97
10.3.4.1Checks if a Kubernetes Ingress resource backed by a Service of type 'ClusterIP' has appropriate annotations for secure TLS configuration. The rule is NON_COMPLIANT if the Ingress resource is configured to route traffic to a 'ClusterIP' Service and does not have the required TLS annotations, or the Service is not of type 'ClusterIP'.1
Attributes
- Section
10.3.4: Audit logs are protected from destruction and unauthorized modifications.
- Service
API Server
10.3.4.2Checks if a Kubernetes Ingress resource has annotation for access control enabled. The rule is NON_COMPLIANT for Ingress resources that don't have access control enabled for services.0
Attributes
- Section
10.3.4: Audit logs are protected from destruction and unauthorized modifications.
- Service
API Server
10.3.4.3Checks that there is at least one Kubernetes Auditing configuration defined with security best practices. This rule is COMPLIANT if there is at least one audit policy that meets all of the following criteria: properly configured for logging, retains logs for an appropriate timeframe, and includes all critical API requests.1
Attributes
- Section
10.3.4: Audit logs are protected from destruction and unauthorized modifications.
- Service
API Server
10.3.4.4Verifies if Kubernetes Secrets are encrypted with a specified KMS provider or a custom key. The check is NON_COMPLIANT if a Secret is not encrypted with any KMS provider or is encrypted with a key not defined in the policy.1
Attributes
- Section
10.3.4: Audit logs are protected from destruction and unauthorized modifications.
- Service
Core
10.3.4.5Checks if Kubernetes secrets are configured to use encryption at rest. The rule is COMPLIANT if the encryption configuration specifies a valid encryption provider with secrets encryption enabled.1
Attributes
- Section
10.3.4: Audit logs are protected from destruction and unauthorized modifications.
- Service
API Server
10.3.4.6Checks if Kubernetes Audit Logs are configured to include a signature for log integrity. It is recommended that the audit log validation feature must be enabled across all namespaces. The rule is NON_COMPLIANT if the validation is not enabled.1
Attributes
- Section
10.3.4: Audit logs are protected from destruction and unauthorized modifications.
- Service
API Server
10.3.4.7Checks if the Kubernetes PersistentVolume has a retention policy enabled. The rule is NON_COMPLIANT if the retention policy is not enabled.0
Attributes
- Section
10.3.4: Audit logs are protected from destruction and unauthorized modifications.
- Service
Core
10.3.4.8Checks if Kubernetes persistent volumes (PVs) are improperly exposed. The rule is NON_COMPLIANT if a PV is not listed in the excludedPersistentVolumes parameter and its access mode allows public access.1
Attributes
- Section
10.3.4: Audit logs are protected from destruction and unauthorized modifications.
- Service
RBAC
10.3.4.9Checks if versioning is enabled for your Kubernetes Persistent Volume Claims (PVCs). Optionally, the rule checks if data protection features like volume snapshots are enabled for your PVCs.1
Attributes
- Section
10.3.4: Audit logs are protected from destruction and unauthorized modifications.
- Service
RBAC
10.4.1: Audit logs are reviewed to identify anomalies or suspicious activity.52
10.4.1.1Checks if OpenTelemetry tracing is enabled on Kubernetes Ingress Controllers. The rule is COMPLIANT if OpenTelemetry tracing is enabled and NON_COMPLIANT otherwise.0
Attributes
- Section
10.4.1: Audit logs are reviewed to identify anomalies or suspicious activity.
- Service
Kubernetes Ingress Controllers
10.4.1.3Checks if detailed monitoring is enabled for Kubernetes Pods. The rule is NON_COMPLIANT if detailed monitoring is not enabled.0
Attributes
- Section
10.4.1: Audit logs are reviewed to identify anomalies or suspicious activity.
- Service
Core
10.4.1.4Checks if a Kubernetes cluster has the PodSecurityPolicy enabled. The rule is NON_COMPLIANT if PodSecurityPolicies are not enabled.1
Attributes
- Section
10.4.1: Audit logs are reviewed to identify anomalies or suspicious activity.
- Service
API Server
10.4.1.5Checks if Kubernetes events logging is enabled for the delivery status of notification messages sent to endpoints. The rule is NON_COMPLIANT if the delivery status notification for messages is not enabled.0
Attributes
- Section
10.4.1: Audit logs are reviewed to identify anomalies or suspicious activity.
- Service
Core
10.4.1.6Checks if Kubernetes auditing is enabled on the cluster. The status is NON_COMPLIANT if the 'audit.log' is not configured or the logging level is set to off.1
Attributes
- Section
10.4.1: Audit logs are reviewed to identify anomalies or suspicious activity.
- Service
API Server
10.4.1.1: Audit logs are reviewed to identify anomalies or suspicious activity.62
10.4.1.1.1Checks if OpenTelemetry tracing is enabled on Kubernetes Ingress controllers. The rule is COMPLIANT if OpenTelemetry tracing is enabled and NON_COMPLIANT otherwise.0
Attributes
- Section
10.4.1.1: Audit logs are reviewed to identify anomalies or suspicious activity.
- Service
API Server
10.4.1.1.3Checks if Kubernetes Audit Logs are configured to be sent to a logging service. The audit policy is considered NON_COMPLIANT if the output configuration for audit logs does not include a specified logging endpoint.1
Attributes
- Section
10.4.1.1: Audit logs are reviewed to identify anomalies or suspicious activity.
- Service
API Server
10.4.1.1.4Checks if detailed monitoring is enabled for Kubernetes Pods. The rule is NON_COMPLIANT if detailed monitoring is not enabled, indicating that metrics for resource usage and performance are not being collected aggressively.0
Attributes
- Section
10.4.1.1: Audit logs are reviewed to identify anomalies or suspicious activity.
- Service
Core
10.4.1.1.5Checks if the Kubernetes Pod Security Policies are enabled for a Kubernetes cluster. The rule is NON_COMPLIANT if Pod Security Policies are not enabled.1
Attributes
- Section
10.4.1.1: Audit logs are reviewed to identify anomalies or suspicious activity.
- Service
API Server
10.4.1.1.6Checks if Kubernetes Event Exporter is configured to log delivery status of events sent to a specific namespace or resource. The rule is NON_COMPLIANT if the delivery status logging for events is not enabled.0
Attributes
- Section
10.4.1.1: Audit logs are reviewed to identify anomalies or suspicious activity.
- Service
Core
10.4.1.1.7Checks if metrics collection for Kubernetes Ingress resources is enabled. The rule is NON_COMPLIANT if the 'metrics.enabled' field is set to false in the Ingress controller configuration.0
Attributes
- Section
10.4.1.1: Audit logs are reviewed to identify anomalies or suspicious activity.
- Service
API Server
10.4.2: Audit logs are reviewed to identify anomalies or suspicious activity.61
10.4.2.1Checks if OpenTelemetry tracing is enabled for Kubernetes Ingress controllers. The rule is COMPLIANT if OpenTelemetry tracing is enabled and NON_COMPLIANT otherwise.0
Attributes
- Section
10.4.2: Audit logs are reviewed to identify anomalies or suspicious activity.
- Service
API Server
10.4.2.2Checks if Kubernetes events have a specified action for the Warning, Normal, or Critical state. Optionally checks if any actions match a specific resource name. The status is NON_COMPLIANT if there is no action specified for the event or optional parameter.0
Attributes
- Section
10.4.2: Audit logs are reviewed to identify anomalies or suspicious activity.
- Service
Kubernetes Events
10.4.2.4Checks if the Kubernetes cluster has the appropriate monitoring set up using tools like Prometheus or Grafana. The rule is NON_COMPLIANT if monitoring is not enabled for the pods or nodes.0
Attributes
- Section
10.4.2: Audit logs are reviewed to identify anomalies or suspicious activity.
- Service
Core
10.4.2.5Checks if Kubernetes Pod Security Policies are enabled in a cluster. The rule is NON_COMPLIANT if Pod Security Policies are not enabled.1
Attributes
- Section
10.4.2: Audit logs are reviewed to identify anomalies or suspicious activity.
- Service
API Server
10.4.2.6Checks if Kubernetes Event logging is enabled for the delivery status of notification messages sent to a service. The rule is NON_COMPLIANT if the delivery status notification for messages is not enabled.0
Attributes
- Section
10.4.2: Audit logs are reviewed to identify anomalies or suspicious activity.
- Service
Core
10.4.2.7Checks if Kubernetes resource monitoring metrics collection is enabled for a specific deployment or pod. The resource is considered NON_COMPLIANT if the 'spec.monitoring.enabled' field is set to false.0
Attributes
- Section
10.4.2: Audit logs are reviewed to identify anomalies or suspicious activity.
- Service
Core
10.4.3: Audit logs are reviewed to identify anomalies or suspicious activity.10
10.4.3.1Checks if Kubernetes alerts (such as those from Prometheus Alertmanager) have an action configured for firing, pending, or resolved states. Optionally checks if any actions match a specific handler or notification channel. The rule is NON_COMPLIANT if there is no action specified for the alert or the optional parameter.0
Attributes
- Section
10.4.3: Audit logs are reviewed to identify anomalies or suspicious activity.
- Service
Core
10.5.1: Audit log history is retained and available for analysis.133
10.5.1.1Verifies whether a CronJob resource in Kubernetes is configured with a schedule that meets the specified frequency for job execution and that any associated Job resources retain their completion history according to the defined retention policy. The status is marked as NON_COMPLIANT if job executions do not occur at the required intervals or if the retention period for successful job completions is not met.0
Attributes
- Section
10.5.1: Audit log history is retained and available for analysis.
- Service
CronJob
10.5.1.2Validates that the retention policy for recovery points in Kubernetes meets the specified duration requirements. If a recovery point's retention configuration is shorter than the mandated time frame, it is deemed NON_COMPLIANT.0
Attributes
- Section
10.5.1: Audit log history is retained and available for analysis.
- Service
Kubernetes Backup and Restore Service
10.5.1.3Checks that there is at least one Kubernetes Audit Policy defined with security best practices. This rule is COMPLIANT if there is at least one Audit Policy that meets all of the following security standards.1
Attributes
- Section
10.5.1: Audit log history is retained and available for analysis.
- Service
API Server
10.5.1.4Checks if a Kubernetes Log retention policy is set to retain logs for more than 365 days or a specified retention period. The rule is NON_COMPLIANT if the retention period is less than MinRetentionTime, if specified, or else 365 days.1
Attributes
- Section
10.5.1: Audit log history is retained and available for analysis.
- Service
API Server
10.5.1.5Checks if a Kubernetes Persistent Volume Claim (PVC) retention period is set to a specific number of days. The rule is NON_COMPLIANT if the retention period is less than the value specified by the parameter.0
Attributes
- Section
10.5.1: Audit log history is retained and available for analysis.
- Service
Core
10.5.1.6Checks if point-in-time recovery (PITR) is enabled for Kubernetes persistent volume claims (PVCs). The rule is NON_COMPLIANT if PITR is not enabled for PVCs.0
Attributes
- Section
10.5.1: Audit log history is retained and available for analysis.
- Service
Core
10.5.1.7Checks if Persistent Volumes (PVs) are bound to Persistent Volume Claims (PVCs), and optionally checks if the PVCs have a 'reclaimPolicy' set to 'Delete' when the associated Pods are terminated.0
Attributes
- Section
10.5.1: Audit log history is retained and available for analysis.
- Service
Core
10.5.1.8Checks if a private Kubernetes Container Registry (e.g., Google Container Registry, Docker Registry) has at least one lifecycle policy configured. The rule is NON_COMPLIANT if no lifecycle policy is configured for the private registry.0
Attributes
- Section
10.5.1: Audit log history is retained and available for analysis.
- Service
Core
10.5.1.9Checks if Kubernetes clusters are configured to send logs to a centralized logging service (e.g., Fluentd, ELK stack). The rule is COMPLIANT if logging is enabled for the pods in the cluster. This rule is NON_COMPLIANT if logging is not configured.0
Attributes
- Section
10.5.1: Audit log history is retained and available for analysis.
- Service
Core
10.5.1.10Checks if Kubernetes clusters have audit logging enabled. The rule is NON_COMPLIANT if a Kubernetes cluster does not have audit logging enabled.1
Attributes
- Section
10.5.1: Audit log history is retained and available for analysis.
- Service
API Server
10.5.1.11Checks if Kubernetes clusters are configured to send logs to a logging solution (like Elasticsearch or a centralized logging system). The rule is NON_COMPLIANT if logging is not configured.0
Attributes
- Section
10.5.1: Audit log history is retained and available for analysis.
- Service
Core
10.5.1.12Checks if a Kubernetes PersistentVolume (PV) has a reclaim policy set to 'Delete' or 'Retain'. The PersistentVolume is CONFLICTING if there are no reclaim policy settings or the policy does not match the specified criteria.0
Attributes
- Section
10.5.1: Audit log history is retained and available for analysis.
- Service
Core
10.5.1.13Checks if Kubernetes Persistent Volume Claims (PVCs) have lifecycle policies configured to automatically manage the lifecycle of storage resources. The rule is NON_COMPLIANT if the lifecycle policy is not enabled.0
Attributes
- Section
10.5.1: Audit log history is retained and available for analysis.
- Service
Core
10.6.3: Time-synchronization mechanisms support consistent time settings across all systems.3915
10.6.3.1Checks if Kubernetes Ingress resources have access logging enabled. The rule is NON_COMPLIANT if 'accessLog' is not present in the Ingress configuration.0
Attributes
- Section
10.6.3: Time-synchronization mechanisms support consistent time settings across all systems.
- Service
API Server
10.6.3.2Checks if all methods in Kubernetes Ingress resources have access logging enabled. The rule is NON_COMPLIANT if access logging is not enabled, or if the logging level is neither ERROR nor INFO.0
Attributes
- Section
10.6.3: Time-synchronization mechanisms support consistent time settings across all systems.
- Service
API Server
10.6.3.3Checks if OpenTelemetry tracing is enabled on Kubernetes Ingress resources. The rule is COMPLIANT if tracing is enabled and NON_COMPLIANT otherwise.0
Attributes
- Section
10.6.3: Time-synchronization mechanisms support consistent time settings across all systems.
- Service
API Server
10.6.3.4Checks if a Kubernetes API server has audit logging enabled. The rule is NON_COMPLIANT if audit logging is not enabled, or if 'logLevel' is neither ERROR nor ALL.1
Attributes
- Section
10.6.3: Time-synchronization mechanisms support consistent time settings across all systems.
- Service
API Server
10.6.3.5Checks if Kubernetes Services are configured with an appropriate session affinity mode. The rule is NON_COMPLIANT if the service's session affinity does not match the user-defined session affinity settings.0
Attributes
- Section
10.6.3: Time-synchronization mechanisms support consistent time settings across all systems.
- Service
Core
10.6.3.6Checks if Kubernetes Ingress resources are configured to log HTTP traffic to a specified logging service. The rule is NON_COMPLIANT if an Ingress resource does not have logging configured.0
Attributes
- Section
10.6.3: Time-synchronization mechanisms support consistent time settings across all systems.
- Service
API Server
10.6.3.7Checks if at least one Kubernetes Audit Policy is configured to log events for all API calls related to Pods. The rule is NON_COMPLIANT if there are no audit policies or if no policies record Pod events.1
Attributes
- Section
10.6.3: Time-synchronization mechanisms support consistent time settings across all systems.
- Service
API Server
10.6.3.8Checks if Kubernetes events have a corresponding alert configured in Prometheus for critical states. Optionally checks if any alerts match a specific label selector. The rule is NON_COMPLIANT if there is no alert specified for the event or optional parameter.0
Attributes
- Section
10.6.3: Time-synchronization mechanisms support consistent time settings across all systems.
- Service
Core
10.6.3.11Checks if a Kubernetes Pod has at least one logging mechanism (e.g., Fluentd, Logstash) enabled. The rule is NON_COMPLIANT if all logging configurations are set to 'DISABLED'.0
Attributes
- Section
10.6.3: Time-synchronization mechanisms support consistent time settings across all systems.
- Service
Core
10.6.3.12Checks if logging is enabled with a valid severity level for Kubernetes Pod events. The rule is NON_COMPLIANT if logging is not enabled or Pod logging has a severity level that is not valid.0
Attributes
- Section
10.6.3: Time-synchronization mechanisms support consistent time settings across all systems.
- Service
Core
10.6.3.13Checks if a Kubernetes cluster has audit logging enabled for its API server. The rule is NON_COMPLIANT if audit logging is not enabled for the API server in the Kubernetes cluster.1
Attributes
- Section
10.6.3: Time-synchronization mechanisms support consistent time settings across all systems.
- Service
API Server
10.6.3.14Checks if Kubernetes has logging enabled for its client connections to ensure compliance. The rule is NON_COMPLIANT if the 'logging.enabled' setting is set to false in the Kubernetes API Server configuration.1
Attributes
- Section
10.6.3: Time-synchronization mechanisms support consistent time settings across all systems.
- Service
API Server
10.6.3.15Checks if detailed monitoring is enabled for Pods in Kubernetes. The rule is NON_COMPLIANT if detailed monitoring (e.g., custom metrics or logging) is not set up for the Pods.0
Attributes
- Section
10.6.3: Time-synchronization mechanisms support consistent time settings across all systems.
- Service
Core
10.6.3.16Checks if Kubernetes Pods have read-only access to their root filesystems. The rule is NON_COMPLIANT if the readOnlyRootFilesystem parameter in the Pod security context is set to 'false'.1
Attributes
- Section
10.6.3: Time-synchronization mechanisms support consistent time settings across all systems.
- Service
Core
10.6.3.17Checks if logging is configured for active Kubernetes Pods. This rule is NON_COMPLIANT if an active Pod does not have the logging configuration (such as a sidecar for logging or specific logging annotations) defined or the value for logging is null in at least one container in the Pod specification.0
Attributes
- Section
10.6.3: Time-synchronization mechanisms support consistent time settings across all systems.
- Service
Core
10.6.3.18Checks if a Kubernetes cluster has logging enabled via a logging solution like Fluentd or Elasticsearch. The rule is NON_COMPLIANT if logging is not enabled for all log types (e.g., application logs, system logs, audit logs).0
Attributes
- Section
10.6.3: Time-synchronization mechanisms support consistent time settings across all systems.
- Service
Core
10.6.3.19Checks if Kubernetes clusters are configured to send logs to a centralized logging solution (like Elasticsearch or fluentd). The rule is NON_COMPLIANT if the value of 'logOptions' is not configured properly or set to false.0
Attributes
- Section
10.6.3: Time-synchronization mechanisms support consistent time settings across all systems.
- Service
Core
10.6.3.20Checks if the Kubernetes Ingress resources have access logging enabled. The rule is NON_COMPLIANT if the ingress annotations for 'nginx.ingress.kubernetes.io/access-log' are not set to true or the 'nginx.ingress.kubernetes.io/access-log-bucket' annotation does not match the specified S3 bucket name.0
Attributes
- Section
10.6.3: Time-synchronization mechanisms support consistent time settings across all systems.
- Service
API Server
10.6.3.21Verifies if Kubernetes users (or service accounts) are associated with at least one Role or ClusterRole binding.0
Attributes
- Section
10.6.3: Time-synchronization mechanisms support consistent time settings across all systems.
- Service
Role-Based Access Control (RBAC)
10.6.3.22Checks if Kubernetes clusters have auditing enabled. The rule is NON_COMPLIANT if auditing is not enabled for a cluster.1
Attributes
- Section
10.6.3: Time-synchronization mechanisms support consistent time settings across all systems.
- Service
API Server
10.6.3.23Checks if a Kubernetes cluster has auditing enabled and configured properly. The rule is NON_COMPLIANT if auditing is not enabled or configured as required.1
Attributes
- Section
10.6.3: Time-synchronization mechanisms support consistent time settings across all systems.
- Service
API Server
10.6.3.25Checks if a Kubernetes cluster has logging enabled for audit logs. The rule is NON_COMPLIANT if an audit log is not enabled for the Kubernetes cluster.1
Attributes
- Section
10.6.3: Time-synchronization mechanisms support consistent time settings across all systems.
- Service
API Server
10.6.3.26Checks if Kubernetes Network Policies have logging enabled. The rule is NON_COMPLIANT if a logging type is not configured. You can specify which logging type you want the rule to check.0
Attributes
- Section
10.6.3: Time-synchronization mechanisms support consistent time settings across all systems.
- Service
Core
10.6.3.27Checks if Kubernetes clusters have Role-Based Access Control (RBAC) enabled. The rule is NON_COMPLIANT if RBAC is not configured for the Kubernetes cluster.1
Attributes
- Section
10.6.3: Time-synchronization mechanisms support consistent time settings across all systems.
- Service
API Server
10.6.3.28Checks if Kubernetes pods have logging enabled to send logs to a centralized logging system, such as Elasticsearch or Fluentd. The rule is NON_COMPLIANT if pods do not have proper logging configurations to push logs to the centralized logging system.0
Attributes
- Section
10.6.3: Time-synchronization mechanisms support consistent time settings across all systems.
- Service
Core
10.6.3.29Checks if respective logs of Kubernetes clusters are enabled. The rule is NON_COMPLIANT if any log types such as audit logs or application logs are not enabled.1
Attributes
- Section
10.6.3: Time-synchronization mechanisms support consistent time settings across all systems.
- Service
API Server
10.6.3.30Checks if Kubernetes clusters are configured to log audits to a specific log destination. The rule is NON_COMPLIANT if audit logging is not enabled for a Kubernetes cluster or if the 'logDestination' parameter is provided but the audit logging destination does not match.1
Attributes
- Section
10.6.3: Time-synchronization mechanisms support consistent time settings across all systems.
- Service
API Server
10.6.3.31Checks if Kubernetes clusters have the specified security settings. The rule is NON_COMPLIANT if the Kubernetes cluster is not using encryption for secrets, or if a cluster does not have audit logging enabled.1
Attributes
- Section
10.6.3: Time-synchronization mechanisms support consistent time settings across all systems.
- Service
RBAC
10.6.3.32Checks if DNS query logging is enabled for your Kubernetes cluster's CoreDNS configuration. The rule is NON_COMPLIANT if DNS query logging is not enabled for CoreDNS.0
Attributes
- Section
10.6.3: Time-synchronization mechanisms support consistent time settings across all systems.
- Service
Core
10.6.3.33Checks if a Kubernetes Role or ClusterRole does not allow blocklisted verbs (e.g., 'get', 'delete') on resources within a namespace for principals from other namespaces. For example, the rule checks that the Role or ClusterRole does not allow any actions like 'get pods' or 'delete deployments' on resources within any namespace. The rule is NON_COMPLIANT if any blocklisted actions are allowed by the Role or ClusterRole.0
Attributes
- Section
10.6.3: Time-synchronization mechanisms support consistent time settings across all systems.
- Service
Core
10.6.3.34Checks if logging is enabled for your Kubernetes pods. The rule is NON_COMPLIANT if logging is not enabled.0
Attributes
- Section
10.6.3: Time-synchronization mechanisms support consistent time settings across all systems.
- Service
Core
10.6.3.35Verifies that the Kubernetes ClusterRole and RoleBinding do not grant permissions to access resources across different namespaces unless explicitly specified by the control policies you define.1
Attributes
- Section
10.6.3: Time-synchronization mechanisms support consistent time settings across all systems.
- Service
RBAC
10.6.3.36Checks if a specific Kubernetes cluster has the PodSecurity admission controller enabled. The rule is NON_COMPLIANT if the PodSecurity admission controller is not enabled.1
Attributes
- Section
10.6.3: Time-synchronization mechanisms support consistent time settings across all systems.
- Service
API Server
10.6.3.37Checks if Kubernetes Event Logging is enabled for the delivery status of event notifications sent to a namespace. The rule is NON_COMPLIANT if the event logging for notifications is not enabled.0
Attributes
- Section
10.6.3: Time-synchronization mechanisms support consistent time settings across all systems.
- Service
Core
10.6.3.38Checks if Kubernetes Pod has logging enabled. The rule is NON_COMPLIANT if a Pod does not have logging configured or the logging level is below the minimum required settings.0
Attributes
- Section
10.6.3: Time-synchronization mechanisms support consistent time settings across all systems.
- Service
Core
10.6.3.39Checks if Kubernetes Network Policies are applied and enforced for all namespaces. The rule is NON_COMPLIANT if network policies are not configured for at least one namespace.1
Attributes
- Section
10.6.3: Time-synchronization mechanisms support consistent time settings across all systems.
- Service
Core
10.6.3.40Checks if logging is enabled on Kubernetes Network Policies. The rule is NON_COMPLIANT if logging is enabled but the logging destination does not match the specified value.0
Attributes
- Section
10.6.3: Time-synchronization mechanisms support consistent time settings across all systems.
- Service
API Server
10.6.3.41Checks if Kubernetes Network Policy metrics collection on a specific Network Policy is enabled. The policy is NON_COMPLIANT if the 'spec.policyTypes' field does not include 'Ingress' or 'Egress'.0
Attributes
- Section
10.6.3: Time-synchronization mechanisms support consistent time settings across all systems.
- Service
Core
10.6.3.42Checks if logging is enabled on Kubernetes Network Policies. The rule is NON_COMPLIANT for a Network Policy if it does not have logging enabled.0
Attributes
- Section
10.6.3: Time-synchronization mechanisms support consistent time settings across all systems.
- Service
Core
10.7.1: Failures of critical security control systems are detected, reported, and responded to promptly.71
10.7.1.1Checks if OpenTelemetry tracing is enabled on Kubernetes REST APIs. The rule is COMPLIANT if OpenTelemetry tracing is enabled and NON_COMPLIANT otherwise.0
Attributes
- Section
10.7.1: Failures of critical security control systems are detected, reported, and responded to promptly.
- Service
API Server
10.7.1.2Checks if your Kubernetes deployments send event notifications to a designated service, such as an external monitoring tool or messaging system (e.g., Slack, PagerDuty). Optionally checks if specified external services are used. The rule is NON_COMPLIANT if Kubernetes deployments do not send notifications.0
Attributes
- Section
10.7.1: Failures of critical security control systems are detected, reported, and responded to promptly.
- Service
Core
10.7.1.3Checks if Kubernetes PodDisruptionBudgets have a specified action for the conditions when 'disruptionAllowed' is not adhered to, i.e., when disruptions are allowed or not allowed. Optionally checks if any actions match a specific label or annotation. The rule is NON_COMPLIANT if there is no action specified for the PodDisruptionBudget or the optional parameter.0
Attributes
- Section
10.7.1: Failures of critical security control systems are detected, reported, and responded to promptly.
- Service
Core
10.7.1.5Checks if detailed monitoring is enabled for Kubernetes Pods. The rule is NON_COMPLIANT if detailed monitoring (such as Prometheus metrics) is not enabled.0
Attributes
- Section
10.7.1: Failures of critical security control systems are detected, reported, and responded to promptly.
- Service
Core
10.7.1.6Checks if Kubernetes Pod Security Policy is enabled for a Kubernetes cluster. The rule is NON_COMPLIANT if Pod Security Policy is not enabled.1
Attributes
- Section
10.7.1: Failures of critical security control systems are detected, reported, and responded to promptly.
- Service
API Server
10.7.1.7Checks if Kubernetes Event Logging is enabled for the delivery status of notification messages sent to a topic for the endpoints. The rule is NON_COMPLIANT if the delivery status notification for messages is not enabled.0
Attributes
- Section
10.7.1: Failures of critical security control systems are detected, reported, and responded to promptly.
- Service
Kubernetes Event API
10.7.1.8Checks if Kubernetes logging for security metrics collection on a specific Pod or Deployment is enabled. The rule is NON_COMPLIANT if the 'logging.enabled' field is set to false.0
Attributes
- Section
10.7.1: Failures of critical security control systems are detected, reported, and responded to promptly.
- Service
Core
10.7.2: Failures of critical security control systems are detected, reported, and responded to promptly.61
10.7.2.1Checks if OpenTelemetry tracing is enabled on Kubernetes services. The rule is COMPLIANT if tracing is enabled and NON_COMPLIANT otherwise.0
Attributes
- Section
10.7.2: Failures of critical security control systems are detected, reported, and responded to promptly.
- Service
Core
10.7.2.3Checks if Kubernetes custom resource alerts (e.g., Prometheus Alertmanager alerts) have an action configured for firing (ALARM), pending (INSUFFICIENT_DATA), or resolved (OK) states. Optionally checks if any actions match a specified Kubernetes resource (like a Service or Deployment). The rule is NON_COMPLIANT if there is no action specified for the alert or optional parameter.0
Attributes
- Section
10.7.2: Failures of critical security control systems are detected, reported, and responded to promptly.
- Service
Core
10.7.2.5Checks if Prometheus monitoring is enabled for Kubernetes pods. The rule is NON_COMPLIANT if Prometheus monitoring is not enabled.0
Attributes
- Section
10.7.2: Failures of critical security control systems are detected, reported, and responded to promptly.
- Service
Core
10.7.2.6Checks if the Kubernetes Security Context is configured for a Pod. The rule is NON_COMPLIANT if the Security Context is not defined, which could lead to security vulnerabilities.1
Attributes
- Section
10.7.2: Failures of critical security control systems are detected, reported, and responded to promptly.
- Service
API Server
10.7.2.7Checks if Kubernetes Event Logging is enabled for the delivery status of events sent to a namespace or pod. The rule is NON_COMPLIANT if the event logging for messages is not enabled.0
Attributes
- Section
10.7.2: Failures of critical security control systems are detected, reported, and responded to promptly.
- Service
Core
10.7.2.8Checks if the Kubernetes security metrics collection is enabled for Network Policies. The rule is NON_COMPLIANT if the 'spec.metrics.enabled' field is set to false.0
Attributes
- Section
10.7.2: Failures of critical security control systems are detected, reported, and responded to promptly.
- Service
API Server
11.3.1.1: External and internal vulnerabilities are regularly identified, prioritized, and addressed.10
11.3.1.1.2Checks if the compliance status of the Kubernetes node's patch compliance is UP_TO_DATE or OUTDATED after the patch installation on the node. The rule is compliant if the field status is UP_TO_DATE.0
Attributes
- Section
11.3.1.1: External and internal vulnerabilities are regularly identified, prioritized, and addressed.
- Service
Core
11.3.1: External and internal vulnerabilities are regularly identified, prioritized, and addressed.20
11.3.1.2Checks if the compliance status of the Kubernetes deployment is 'COMPLIANT' or 'NON_COMPLIANT' after the update to the application. The rule is compliant if the status field in the deployment returns 'COMPLIANT'.0
Attributes
- Section
11.3.1: External and internal vulnerabilities are regularly identified, prioritized, and addressed.
- Service
Core
11.3.1.3Checks if a private Kubernetes container registry (e.g., Azure Container Registry, Google Container Registry) has image scanning enabled. The rule is NON_COMPLIANT if the container registry's scan frequency is not set to scan on push or continuous scan.0
Attributes
- Section
11.3.1: External and internal vulnerabilities are regularly identified, prioritized, and addressed.
- Service
Core
11.3.1.2: External and internal vulnerabilities are regularly identified, prioritized, and addressed.10
11.3.1.2.1Checks if a private Kubernetes container registry has image scanning enabled. The rule is NON_COMPLIANT if the container images in the registry are not scanned regularly for vulnerabilities or are not scanned upon image push. For detailed information on enabling image scanning, refer to the Kubernetes container security best practices documentation.0
Attributes
- Section
11.3.1.2: External and internal vulnerabilities are regularly identified, prioritized, and addressed.
- Service
Core
11.3.1.3: External and internal vulnerabilities are regularly identified, prioritized, and addressed.30
11.3.1.3.1Verifies that all specified Kubernetes applications (pods or deployments) are present in the cluster, with the option to check for minimum acceptable versions and to target specific node/platform types.0
Attributes
- Section
11.3.1.3: External and internal vulnerabilities are regularly identified, prioritized, and addressed.
- Service
Core
11.3.1.3.2Checks if the compliance status of a Kubernetes pod's deployment is READY or NOT_READY after updates or changes to the pod. The rule is compliant if the condition status is READY.0
Attributes
- Section
11.3.1.3: External and internal vulnerabilities are regularly identified, prioritized, and addressed.
- Service
Core
11.3.1.3.3Checks if a private Kubernetes container registry has image scanning enabled. The rule is NON_COMPLIANT if the private container registry's scan policy is not set to scan on push or continuous scan.0
Attributes
- Section
11.3.1.3: External and internal vulnerabilities are regularly identified, prioritized, and addressed.
- Service
Core
11.5.1: Network intrusions and unexpected file changes are detected and responded to.22
11.5.1.1Checks whether a Kubernetes Service has Network Policies or Ingress controllers configured for protection against DDoS attacks. It also checks if they have specific authorization rules defined for the Ingress resources.1
Attributes
- Section
11.5.1: Network intrusions and unexpected file changes are detected and responded to.
- Service
API Server
11.5.1.2Checks if Kubernetes Pod Security Policies are enabled in your Kubernetes cluster. If you provide a cluster for centralization, the rule evaluates the Pod Security Policies in the centralized cluster. The rule is COMPLIANT when Pod Security Policies are enabled.1
Attributes
- Section
11.5.1: Network intrusions and unexpected file changes are detected and responded to.
- Service
API Server
11.5.1.1: Network intrusions and unexpected file changes are detected and responded to.22
11.5.1.1.1Checks whether a Kubernetes LoadBalancer Service or Ingress resource has any associated protection mechanisms, such as network policies for security, and if they have specified Ingress rules associated for additional security configurations.1
Attributes
- Section
11.5.1.1: Network intrusions and unexpected file changes are detected and responded to.
- Service
Core
11.5.1.1.2Checks if Kubernetes Pod Security Policies are enabled in your Kubernetes cluster. If you provide a central management cluster, the policy evaluates the Pod Security results in the centralized context. The policy is COMPLIANT when Pod Security Policies are enabled.1
Attributes
- Section
11.5.1.1: Network intrusions and unexpected file changes are detected and responded to.
- Service
API Server
11.5.2: Network intrusions and unexpected file changes are detected and responded to.61
11.5.2.1Checks if your Kubernetes resources (like Pods, Deployments, etc.) send event notifications to a designated Pub/Sub topic. Optionally checks if specified Pub/Sub topics are utilized. The rule is NON_COMPLIANT if Kubernetes resources do not send notifications.0
Attributes
- Section
11.5.2: Network intrusions and unexpected file changes are detected and responded to.
- Service
Core
11.5.2.2Verifies if Kubernetes liveness probes or readiness probes have valid actions configured for different states. It checks if any actions are set to change the pod's status based on these probes. The rule is NON_COMPLIANT if no actions are specified for the probes.0
Attributes
- Section
11.5.2: Network intrusions and unexpected file changes are detected and responded to.
- Service
Core
11.5.2.3Verifies if Kubernetes alerts configured in Prometheus with the specified metric name meet the defined conditions.0
Attributes
- Section
11.5.2: Network intrusions and unexpected file changes are detected and responded to.
- Service
Core
11.5.2.4Checks if Kubernetes audit logs are configured to send logs to a log management system like Elasticsearch or a logging solution such as Fluentd or another log aggregator. The audit logging is NON_COMPLIANT if the output destination is not specified or if the audit log file is not configured.1
Attributes
- Section
11.5.2: Network intrusions and unexpected file changes are detected and responded to.
- Service
API Server
11.5.2.5Checks if Kubernetes Event Notifications for a specific resource (e.g., Pod or Service) are enabled. The rule is NON_COMPLIANT if Event Notifications are not set on the resource, or if the event type or notification endpoint do not match the expected event types and notification URL.0
Attributes
- Section
11.5.2: Network intrusions and unexpected file changes are detected and responded to.
- Service
Core
11.5.2.6Checks if Kubernetes Events Logging is enabled for the notifications of events related to pods and services. The rule is NON_COMPLIANT if event notification logging for Kubernetes objects is not enabled.0
Attributes
- Section
11.5.2: Network intrusions and unexpected file changes are detected and responded to.
- Service
Kubernetes Events
11.6.1: Unauthorized changes on payment pages are detected and responded to.51
11.6.1.2Checks if Kubernetes Horizontal Pod Autoscaler (HPA) has correctly configured scaling actions for different metrics. Optionally checks if any scaling actions match a specific deployment or resource. The rule is NON_COMPLIANT if there are no scaling actions defined for the HPA or optional parameters.0
Attributes
- Section
11.6.1: Unauthorized changes on payment pages are detected and responded to.
- Service
Core
11.6.1.3Verifies if Kubernetes alerts with the specified metric name have the defined configuration settings.0
Attributes
- Section
11.6.1: Unauthorized changes on payment pages are detected and responded to.
- Service
Kubernetes Alerts
11.6.1.4Checks if Kubernetes Audit Logs are configured to send logs to a specified logging service. The audit logging is NON_COMPLIANT if the logging configuration does not point to an active logging backend such as Elasticsearch or a central logging service.1
Attributes
- Section
11.6.1: Unauthorized changes on payment pages are detected and responded to.
- Service
API Server
11.6.1.5Checks if Kubernetes Event Notifications are enabled for a specific resource. The rule is NON_COMPLIANT if Event Notifications are not set on a resource, or if the event type or destination do not match the specified eventTypes and destination parameters.0
Attributes
- Section
11.6.1: Unauthorized changes on payment pages are detected and responded to.
- Service
Kubernetes Events
11.6.1.6Checks if Kubernetes Event Logging is enabled for the delivery status of events sent to a specified namespace. The rule is NON_COMPLIANT if the event logging for notifications is not enabled.0
Attributes
- Section
11.6.1: Unauthorized changes on payment pages are detected and responded to.
- Service
Core
12.4.2.1: PCI DSS compliance is managed.11
12.4.2.1.1Checks if a Kubernetes cluster shares resources (like ConfigMaps or Secrets) to multiple namespaces when integration is enabled with Kubernetes RBAC. The rule is NON_COMPLIANT if the resource is scoped to a single namespace instead of being cluster-wide.1
Attributes
- Section
12.4.2.1: PCI DSS compliance is managed.
- Service
RBAC
12.10.5: Suspected and confirmed security incidents that could impact the CDE are responded to immediately.51
12.10.5.2Checks if Kubernetes PodDisruptionBudgets (PDBs) have a set number of allowed disruptions configured. Optionally checks if any disruptions match a specific label selector. The rule is NON_COMPLIANT if there are no disruptions allowed in the PDB or optional parameter.0
Attributes
- Section
12.10.5: Suspected and confirmed security incidents that could impact the CDE are responded to immediately.
- Service
Core
12.10.5.3Checks whether Kubernetes Horizontal Pod Autoscaler (HPA) has the specified settings for scaling pods based on custom metrics.0
Attributes
- Section
12.10.5: Suspected and confirmed security incidents that could impact the CDE are responded to immediately.
- Service
Kubernetes HPA
12.10.5.4Checks if Kubernetes audit logging is configured to send logs to a specified logging backend. The audit policy is NON_COMPLIANT if the audit backend configuration is not set or if the logging destination is empty.1
Attributes
- Section
12.10.5: Suspected and confirmed security incidents that could impact the CDE are responded to immediately.
- Service
API Server
12.10.5.5Checks if Kubernetes events are enabled for a specific resource. The rule is NON_COMPLIANT if events are not set for the resource, or if the event type or destination do not match the eventTypes and destination parameters.0
Attributes
- Section
12.10.5: Suspected and confirmed security incidents that could impact the CDE are responded to immediately.
- Service
Core
12.10.5.6Checks if Kubernetes Event Logging is enabled for notifications sent to the endpoints. The rule is NON_COMPLIANT if delivery status logging for events is not enabled.0
Attributes
- Section
12.10.5: Suspected and confirmed security incidents that could impact the CDE are responded to immediately.
- Service
Kubernetes Event Logging
A1.1.2: Multi-tenant service providers protect and separate all customer environments and data.2112
A1.1.2.1Checks if a Kubernetes Namespace has network policies that prevent deletion of resources. The rule is NON_COMPLIANT if the Namespace does not have network policies or has policies without a suitable 'Deny' statement (statements preventing delete operations for resources like Pods, Deployments, and Services).0
Attributes
- Section
A1.1.2: Multi-tenant service providers protect and separate all customer environments and data.
- Service
Kubernetes Namespace
A1.1.2.2Checks if Kubernetes nodes are publicly accessible. The rule is NON_COMPLIANT if the node's external IP is set and reachable from the internet.0
Attributes
- Section
A1.1.2: Multi-tenant service providers protect and separate all customer environments and data.
- Service
Core
A1.1.2.3Checks if Kubernetes persistent volume snapshots are public. The rule is NON_COMPLIANT if any Kubernetes persistent volume snapshots are public.0
Attributes
- Section
A1.1.2: Multi-tenant service providers protect and separate all customer environments and data.
- Service
Core
A1.1.2.4Checks if Kubernetes Persistent Volumes (PVs) are not publicly accessible. The rule is NON_COMPLIANT if one or more Persistent Volumes have their access modes set to ReadWriteMany with a public IP, indicating they are accessible from outside the cluster.1
Attributes
- Section
A1.1.2: Multi-tenant service providers protect and separate all customer environments and data.
- Service
RBAC
A1.1.2.5Checks if Kubernetes containers only have read-only access to their root filesystems. The rule is NON_COMPLIANT if the readOnlyRootFilesystem field in the container specification is set to 'false'.1
Attributes
- Section
A1.1.2: Multi-tenant service providers protect and separate all customer environments and data.
- Service
Core
A1.1.2.6Checks if Kubernetes Persistent Volume (PV) is configured to enforce a specific mount path and not the root directory. The rule is NON_COMPLIANT if the mount path is set to '/' (default root directory of the volume).1
Attributes
- Section
A1.1.2: Multi-tenant service providers protect and separate all customer environments and data.
- Service
RBAC
A1.1.2.7Checks if Kubernetes Persistent Volumes (PVs) and Persistent Volume Claims (PVCs) are configured with appropriate access modes and security contexts to enforce user identity. The rule is NON_COMPLIANT if 'securityContext.runAsUser' is not defined or if the access mode does not match the expected user identity configuration.1
Attributes
- Section
A1.1.2: Multi-tenant service providers protect and separate all customer environments and data.
- Service
RBAC
A1.1.2.8Checks if a Kubernetes Service has public access settings enabled. The rule is NON_COMPLIANT if its type is not ClusterIP, or if it's of type LoadBalancer or NodePort, and exposes ports other than Port 22.1
Attributes
- Section
A1.1.2: Multi-tenant service providers protect and separate all customer environments and data.
- Service
API Server
A1.1.2.9Checks if the Kubernetes Pod Security Policy or Network Policy attached to the Pod resource prohibits public access. If the Pod security policy allows public access, it is NON_COMPLIANT.0
Attributes
- Section
A1.1.2: Multi-tenant service providers protect and separate all customer environments and data.
- Service
Core
A1.1.2.10Checks if a Kubernetes cluster snapshot (using a backup tool) is public. The rule is NON_COMPLIANT if any existing and new Kubernetes cluster snapshots is public.0
Attributes
- Section
A1.1.2: Multi-tenant service providers protect and separate all customer environments and data.
- Service
Core
A1.1.2.12Checks if Kubernetes Persistent Volume snapshots are public. The rule is NON_COMPLIANT if any existing and new Kubernetes Persistent Volume snapshots are public.1
Attributes
- Section
A1.1.2: Multi-tenant service providers protect and separate all customer environments and data.
- Service
RBAC
A1.1.2.13Checks if Kubernetes clusters are not publicly accessible. The rule is NON_COMPLIANT if the service is exposed on a public IP or if the `externalTrafficPolicy` is set to 'Cluster' without proper Network Policy configurations.1
Attributes
- Section
A1.1.2: Multi-tenant service providers protect and separate all customer environments and data.
- Service
API Server
A1.1.2.14Checks if Kubernetes Network Policies are in place to restrict unauthorized access to Pods. The rule is NON_COMPLIANT if Network Policies are not defined to limit network access to Pods in the cluster.1
Attributes
- Section
A1.1.2: Multi-tenant service providers protect and separate all customer environments and data.
- Service
Core
A1.1.2.15Checks if the required NetworkPolicies are configured to restrict public access for the specified Kubernetes namespaces. The rule is only NON_COMPLIANT when the defined NetworkPolicies do not match the expected configurations for controlling ingress and egress traffic.1
Attributes
- Section
A1.1.2: Multi-tenant service providers protect and separate all customer environments and data.
- Service
Core
A1.1.2.16Checks if the required network policies for public access are configured at the namespace level. The rule is NON_COMPLIANT if the configuration does not match one or more settings from the specified parameters (or default).0
Attributes
- Section
A1.1.2: Multi-tenant service providers protect and separate all customer environments and data.
- Service
API Server
A1.1.2.17Checks if Kubernetes Services are publicly accessible. The rule is NON_COMPLIANT if a Service of type LoadBalancer or NodePort is not listed in the excludedPublicServices parameter and has access settings that allow external traffic.1
Attributes
- Section
A1.1.2: Multi-tenant service providers protect and separate all customer environments and data.
- Service
API Server
A1.1.2.18Checks if the Kubernetes cluster has MFA Delete equivalent enabled for resource deletion policies. The rule is NON_COMPLIANT if resource deletion policies that require enhanced authentication are not enforced.0
Attributes
- Section
A1.1.2: Multi-tenant service providers protect and separate all customer environments and data.
- Service
Core
A1.1.2.19Checks if your Kubernetes Secrets do not allow unauthenticated access. The rule checks the Role-Based Access Control (RBAC) permissions, the secrets configuration, and any network policies that might expose the secrets.1
Attributes
- Section
A1.1.2: Multi-tenant service providers protect and separate all customer environments and data.
- Service
RBAC
A1.1.2.20Checks if your Kubernetes Persistent Volume Claims (PVCs) do not allow public write access. The rule checks the StorageClass settings, the PVC configurations, and the associated Access Modes.1
Attributes
- Section
A1.1.2: Multi-tenant service providers protect and separate all customer environments and data.
- Service
RBAC
A1.1.2.21Checks if direct internet access is disabled for a Kubernetes Pod. The rule is NON_COMPLIANT if the Pod is configured to use an External IP for internet access.0
Attributes
- Section
A1.1.2: Multi-tenant service providers protect and separate all customer environments and data.
- Service
Core
A1.1.2.22Checks if Kubernetes ConfigMaps owned by the namespace are public. The rule is NON_COMPLIANT if ConfigMaps with the owner 'Self' have anonymous access enabled.0
Attributes
- Section
A1.1.2: Multi-tenant service providers protect and separate all customer environments and data.
- Service
Kubernetes ConfigMap
A1.1.3: Multi-tenant service providers protect and separate all customer environments and data.4613
A1.1.3.1Checks if Kubernetes Services are of the type specified in the rule parameter serviceType. The rule returns NON_COMPLIANT if the Service does not match the endpoint type configured in the rule parameter.0
Attributes
- Section
A1.1.3: Multi-tenant service providers protect and separate all customer environments and data.
- Service
Core
A1.1.3.2Checks if a Kubernetes Ingress resource is configured to use HTTPS with an SSL certificate. The rule is NON_COMPLIANT if the Ingress does not have an associated TLS configuration with a valid certificate.0
Attributes
- Section
A1.1.3: Multi-tenant service providers protect and separate all customer environments and data.
- Service
API Server
A1.1.3.3Checks if Kubernetes APIs (such as those provided by the API server) are protected by Network Policies. The rule is NON_COMPLIANT for a Kubernetes API if it is not associated with a Network Policy.1
Attributes
- Section
A1.1.3: Multi-tenant service providers protect and separate all customer environments and data.
- Service
API Server
A1.1.3.4Checks if Kubernetes Ingress resources have a valid annotation for a Web Application Firewall (WAF) or a specific WAF ACL. The rule is NON_COMPLIANT if an Ingress resource is not associated with a WAF configuration.0
Attributes
- Section
A1.1.3: Multi-tenant service providers protect and separate all customer environments and data.
- Service
Core
A1.1.3.5Checks if the certificate associated with an Ingress resource in Kubernetes is the default SSL certificate. The rule is NON_COMPLIANT if an Ingress resource uses the default SSL certificate.0
Attributes
- Section
A1.1.3: Multi-tenant service providers protect and separate all customer environments and data.
- Service
API Server
A1.1.3.6Checks if the Bitbucket source repository URL contains sign-in credentials; marked as NON_COMPLIANT if the URL contains any sign-in information and COMPLIANT if it doesn't.0
Attributes
- Section
A1.1.3: Multi-tenant service providers protect and separate all customer environments and data.
- Service
Core
A1.1.3.7Checks if Kubernetes pods have public network access. The rule is NON_COMPLIANT if the 'hostNetwork' field is set to true in the pod specification.1
Attributes
- Section
A1.1.3: Multi-tenant service providers protect and separate all customer environments and data.
- Service
Core
A1.1.3.8Checks if Kubernetes stateful sets have public access. The rule is NON_COMPLIANT if any Kubernetes stateful sets have public network policies, exposing them to the internet.0
Attributes
- Section
A1.1.3: Multi-tenant service providers protect and separate all customer environments and data.
- Service
Core
A1.1.3.9Checks if the Kubernetes NetworkPolicy allows access for all pods. The rule is NON_COMPLIANT if 'allow all' is present and set to true.0
Attributes
- Section
A1.1.3: Multi-tenant service providers protect and separate all customer environments and data.
- Service
Core
A1.1.3.10Checks if the status of the Kubernetes Deployment rollout is successful or failed after the deployment update on the pod. The deployment is compliant if the status indicates success. For more information about deployments, see What is a deployment?0
Attributes
- Section
A1.1.3: Multi-tenant service providers protect and separate all customer environments and data.
- Service
Core
A1.1.3.11Checks if Kubernetes Network Policies have 'ingress' rules defined to allow traffic. The rule is NON_COMPLIANT for a Network Policy if 'ingress' rules are not configured.0
Attributes
- Section
A1.1.3: Multi-tenant service providers protect and separate all customer environments and data.
- Service
Core
A1.1.3.12Checks if the Kubernetes cluster endpoint is not publicly accessible. The rule is NON_COMPLIANT if the endpoint is publicly accessible.1
Attributes
- Section
A1.1.3: Multi-tenant service providers protect and separate all customer environments and data.
- Service
API Server
A1.1.3.13Checks if Kubernetes clusters have their services configured with private access only. The rule is NON_COMPLIANT if a service exposed is of type LoadBalancer and is accessible from outside the cluster.1
Attributes
- Section
A1.1.3: Multi-tenant service providers protect and separate all customer environments and data.
- Service
API Server
A1.1.3.14Checks if Ingress resources in Kubernetes are configured with certificates from a Certificate Manager. This rule is NON_COMPLIANT if at least 1 Ingress resource has at least 1 TLS configuration that is not using a certificate from the designated Certificate Manager or is configured with a certificate different from the designated Certificate Manager's certificate.1
Attributes
- Section
A1.1.3: Multi-tenant service providers protect and separate all customer environments and data.
- Service
API Server
A1.1.3.15Checks if the Kubernetes Services use TLS certificates provided by a specified certificate management solution (e.g., cert-manager). To use this rule, ensure that the Service is configured with a TLS or HTTPS endpoint. This rule is only applicable to Kubernetes Services configured for TLS. This rule does not check Ingress resources or any other types of Services.1
Attributes
- Section
A1.1.3: Multi-tenant service providers protect and separate all customer environments and data.
- Service
API Server
A1.1.3.16Checks if a Kubernetes cluster has network policies that restrict public access. The rule is NON_COMPLIANT if NetworkPolicy is not applied, or if applied, ports other than Port 22 are open in the allowed ingress or egress rules.0
Attributes
- Section
A1.1.3: Multi-tenant service providers protect and separate all customer environments and data.
- Service
Core
A1.1.3.17The rule INCOMING_SSH_DISABLED named restricted-ssh restricts incoming SSH connections to enhance security in Kubernetes.0
Attributes
- Section
A1.1.3: Multi-tenant service providers protect and separate all customer environments and data.
- Service
API Server
A1.1.3.18Checks if Load Balancers are associated with an authorized Kubernetes cluster. The rule is NON_COMPLIANT if Load Balancers are associated with an unauthorized cluster.0
Attributes
- Section
A1.1.3: Multi-tenant service providers protect and separate all customer environments and data.
- Service
Core
A1.1.3.19Checks if the Kubernetes Service policy attached to the Service resource prohibits public access. If the Service policy allows public access, it is NON_COMPLIANT.0
Attributes
- Section
A1.1.3: Multi-tenant service providers protect and separate all customer environments and data.
- Service
Core
A1.1.3.20Checks if a Kubernetes Pod is allowed access to a virtual private cloud (VPC) through the presence of network policies. The rule is NON_COMPLIANT if the Pod is not configured with the correct network policies for VPC access.0
Attributes
- Section
A1.1.3: Multi-tenant service providers protect and separate all customer environments and data.
- Service
Core
A1.1.3.21Checks if Kubernetes Network Policies allow unrestricted ingress traffic on default ports for SSH (22) or RDP (3389). The rule is NON_COMPLIANT if a Network Policy permits ingress traffic from any source IP to these ports.0
Attributes
- Section
A1.1.3: Multi-tenant service providers protect and separate all customer environments and data.
- Service
API Server
A1.1.3.22Checks if a Kubernetes Network Policy is configured with a user-defined default action for fragmented packets. The rule is NON_COMPLIANT if the default action for fragmented packets does not match with the user-defined default action.0
Attributes
- Section
A1.1.3: Multi-tenant service providers protect and separate all customer environments and data.
- Service
Core
A1.1.3.23Check if the Kubernetes NetworkPolicy is associated with ingress or egress rules. This policy is NON_COMPLIANT if no ingress or egress rules are defined in the NetworkPolicy, otherwise COMPLIANT if at least one rule exists.0
Attributes
- Section
A1.1.3: Multi-tenant service providers protect and separate all customer environments and data.
- Service
API Server
A1.1.3.24Checks if a Kubernetes NetworkPolicy contains ingress or egress rules. The policy is NON_COMPLIANT if there are no rules defined in the NetworkPolicy.0
Attributes
- Section
A1.1.3: Multi-tenant service providers protect and separate all customer environments and data.
- Service
API Server
A1.1.3.25Checks if there are public routes in the Kubernetes NetworkPolicy to an external service. The rule is NON_COMPLIANT if a NetworkPolicy allows traffic to a specific service from any source without restrictions.0
Attributes
- Section
A1.1.3: Multi-tenant service providers protect and separate all customer environments and data.
- Service
API Server
A1.1.3.26Checks if Kubernetes clusters are within a Virtual Private Cloud (VPC). The rule is NON_COMPLIANT if a Kubernetes service is exposed with type 'LoadBalancer' or 'NodePort' without proper network policies restricting access.1
Attributes
- Section
A1.1.3: Multi-tenant service providers protect and separate all customer environments and data.
- Service
Core
A1.1.3.27Checks if there are any Kubernetes Network Policies that do not conform to the default network policy. The rule is NON_COMPLIANT if there are any network policies that are not the default network policy.0
Attributes
- Section
A1.1.3: Multi-tenant service providers protect and separate all customer environments and data.
- Service
Core
A1.1.3.28Checks if the Kubernetes Database service (such as PostgreSQL or MySQL) instances are not publicly accessible. The rule is NON_COMPLIANT if the service type is set to LoadBalancer or if there are any external IPs assigned.0
Attributes
- Section
A1.1.3: Multi-tenant service providers protect and separate all customer environments and data.
- Service
Kubernetes Database Service
A1.1.3.29Checks if Kubernetes clusters are not publicly accessible. The rule is NON_COMPLIANT if the publicly accessible fields in the cluster configuration (e.g., `--advertise-address`, `--enable-aggregator-routing`, security group settings) are set to allow public access.0
Attributes
- Section
A1.1.3: Multi-tenant service providers protect and separate all customer environments and data.
- Service
Core
A1.1.3.30Checks if Kubernetes services have network policies that deny public access. The rule is NON_COMPLIANT if network policies do not restrict public access to the services.1
Attributes
- Section
A1.1.3: Multi-tenant service providers protect and separate all customer environments and data.
- Service
API Server
A1.1.3.31Verifies that the public access settings for Kubernetes resources (such as Pods or Services) are correctly configured at the cluster level. The rule is considered NON_COMPLIANT if the specified settings for public access do not align with the designated configuration specifications.1
Attributes
- Section
A1.1.3: Multi-tenant service providers protect and separate all customer environments and data.
- Service
API Server
A1.1.3.32Checks if the required network policies are configured to restrict public access at the namespace level. The rule is NON_COMPLIANT if the network policy does not match one or more settings from parameters or defaults.0
Attributes
- Section
A1.1.3: Multi-tenant service providers protect and separate all customer environments and data.
- Service
Core
A1.1.3.33Checks if Kubernetes Services are publicly accessible. The rule is NON_COMPLIANT if a Service is of type 'LoadBalancer' or 'NodePort' and is not listed in the excludedPublicServices parameter, and the service level settings are public.1
Attributes
- Section
A1.1.3: Multi-tenant service providers protect and separate all customer environments and data.
- Service
API Server
A1.1.3.34Checks if your Kubernetes persistent volume claims do not allow public access. The rule checks the access modes and any associated Network Policies or Role-Based Access Control (RBAC) settings.1
Attributes
- Section
A1.1.3: Multi-tenant service providers protect and separate all customer environments and data.
- Service
RBAC
A1.1.3.35Checks if your Kubernetes Persistent Volumes do not allow public write access. The rule checks the Persistent Volume Claims and their associated access modes, ensuring that only authorized users can write to the volumes.1
Attributes
- Section
A1.1.3: Multi-tenant service providers protect and separate all customer environments and data.
- Service
RBAC
A1.1.3.36Checks if a Kubernetes Pod is deployed within a specific namespace or within a list of approved namespaces. The rule is NON_COMPLIANT if a Pod is not deployed within a specified namespace or if its namespace is not included in the parameter list.0
Attributes
- Section
A1.1.3: Multi-tenant service providers protect and separate all customer environments and data.
- Service
Core
A1.1.3.37Checks if direct internet access is disabled for a Kubernetes Pod. The rule is NON_COMPLIANT if a Pod is configured to use an external IP or has access to the internet through its network settings.0
Attributes
- Section
A1.1.3: Multi-tenant service providers protect and separate all customer environments and data.
- Service
Core
A1.1.3.38Checks if a Kubernetes Service has Endpoints created for each corresponding Deployment or Pod in the specified namespace. The rule is NON_COMPLIANT if any Deployment or Pod does not have the corresponding Endpoints for the Service.0
Attributes
- Section
A1.1.3: Multi-tenant service providers protect and separate all customer environments and data.
- Service
Core
A1.1.3.39Checks if there are unused Network Policies. The rule is COMPLIANT if each Network Policy is associated with a Pod. The rule is NON_COMPLIANT if a Network Policy is not associated with a Pod.0
Attributes
- Section
A1.1.3: Multi-tenant service providers protect and separate all customer environments and data.
- Service
API Server
A1.1.3.40In Kubernetes, equivalent configuration checks would involve validating Network Policies to ensure that only specified pods can accept incoming traffic on certain ports. The check is NON_COMPLIANT if there are Network Policies allowing unrestricted traffic on all ports without specifying authorized ports.1
Attributes
- Section
A1.1.3: Multi-tenant service providers protect and separate all customer environments and data.
- Service
Core
A1.1.3.41Checks if a Kubernetes NetworkPolicy contains any ingress or egress rules. The NetworkPolicy is NON_COMPLIANT if there are no rules specified within it.0
Attributes
- Section
A1.1.3: Multi-tenant service providers protect and separate all customer environments and data.
- Service
API Server
A1.1.3.42Checks if a Kubernetes NetworkPolicy contains any ingress or egress rules. The policy is NON_COMPLIANT if no rules are present within the NetworkPolicy.0
Attributes
- Section
A1.1.3: Multi-tenant service providers protect and separate all customer environments and data.
- Service
API Server
A1.1.3.43Checks whether a Kubernetes NetworkPolicy exists in a namespace. This rule is NON_COMPLIANT if a NetworkPolicy does not exist, as it is recommended to enforce network segmentation.0
Attributes
- Section
A1.1.3: Multi-tenant service providers protect and separate all customer environments and data.
- Service
Core
A1.1.3.44Checks if Kubernetes Network Policies contain any ingress or egress rules. The policy is NON_COMPLIANT if there are no rules present within a Kubernetes Network Policy.0
Attributes
- Section
A1.1.3: Multi-tenant service providers protect and separate all customer environments and data.
- Service
Core
A1.1.3.45Checks whether a Kubernetes NetworkPolicy contains ingress or egress rules. This NetworkPolicy is COMPLIANT if it includes at least one rule and NON_COMPLIANT otherwise.0
Attributes
- Section
A1.1.3: Multi-tenant service providers protect and separate all customer environments and data.
- Service
API Server
A1.1.3.46Checks if a Kubernetes NetworkPolicy contains any ingress or egress rules. The policy is NON_COMPLIANT if there are no rules present within the NetworkPolicy.0
Attributes
- Section
A1.1.3: Multi-tenant service providers protect and separate all customer environments and data.
- Service
Core
A1.2.1: Multi-tenant service providers facilitate logging and incident response for all customers.3415
A1.2.1.1Checks if Kubernetes Ingress resources have access logging enabled. The rule is NON_COMPLIANT if an access log configuration is not defined for the Ingress resource.0
Attributes
- Section
A1.2.1: Multi-tenant service providers facilitate logging and incident response for all customers.
- Service
API Server
A1.2.1.2Checks if all methods in Kubernetes Ingress resources have logging enabled. The rule is NON_COMPLIANT if logging is not enabled or if the logging level is neither ERROR nor INFO.0
Attributes
- Section
A1.2.1: Multi-tenant service providers facilitate logging and incident response for all customers.
- Service
API Server
A1.2.1.3Checks if OpenTelemetry tracing is enabled on Kubernetes API Gateway (such as Istio or Ambassador). The rule is COMPLIANT if OpenTelemetry tracing is enabled and NON_COMPLIANT otherwise.0
Attributes
- Section
A1.2.1: Multi-tenant service providers facilitate logging and incident response for all customers.
- Service
Kubernetes API Gateway
A1.2.1.4Checks if a Kubernetes API server has audit logging enabled. The rule is NON_COMPLIANT if audit logging is not enabled, or 'audit-log-path' is set to a path that does not exist or is not configured correctly.1
Attributes
- Section
A1.2.1: Multi-tenant service providers facilitate logging and incident response for all customers.
- Service
API Server
A1.2.1.5Checks if Kubernetes Services are configured with a user-defined session affinity. The rule is NON_COMPLIANT if the session affinity setting does not match the user-defined session affinity mode.0
Attributes
- Section
A1.2.1: Multi-tenant service providers facilitate logging and incident response for all customers.
- Service
Core
A1.2.1.6Checks if Kubernetes Ingress resources are configured to log requests to a designated logging service. The rule is NON_COMPLIANT if an Ingress resource does not have logging enabled.0
Attributes
- Section
A1.2.1: Multi-tenant service providers facilitate logging and incident response for all customers.
- Service
API Server
A1.2.1.7Checks if at least one Kubernetes audit policy is logging data events for all resources in the cluster. The rule is NON_COMPLIANT if there are no policies in place that record data events.1
Attributes
- Section
A1.2.1: Multi-tenant service providers facilitate logging and incident response for all customers.
- Service
API Server
A1.2.1.8Checks that there is at least one Kubernetes audit policy defined with security best practices. This rule is COMPLIANT if there is at least one audit policy that meets all of the following: proper event retention, appropriate level of information logged, and compliance with organizational security requirements.1
Attributes
- Section
A1.2.1: Multi-tenant service providers facilitate logging and incident response for all customers.
- Service
API Server
A1.2.1.9Checks if Kubernetes Secrets are encrypted at rest with a specified encryption configuration. The rule is NON_COMPLIANT if a Secret is not encrypted or is encrypted with a key not specified in the encryption configuration.1
Attributes
- Section
A1.2.1: Multi-tenant service providers facilitate logging and incident response for all customers.
- Service
Core
A1.2.1.11Checks if the Kubernetes cluster has encryption enabled for secrets, using the specific encryption provider. The rule is COMPLIANT if the encryption provider is configured in the Kubernetes API server with an encryption config file.1
Attributes
- Section
A1.2.1: Multi-tenant service providers facilitate logging and incident response for all customers.
- Service
API Server
A1.2.1.12Checks if Kubernetes audit logging is enabled and if the logs are being stored securely. It's recommended that audit logging is configured to capture all events for compliance and security purposes. The rule is NON_COMPLIANT if audit logging is not enabled or misconfigured.1
Attributes
- Section
A1.2.1: Multi-tenant service providers facilitate logging and incident response for all customers.
- Service
API Server
A1.2.1.13Checks if a Kubernetes Pod has at least one logging option enabled. The rule is NON_COMPLIANT if the status of all present logging configurations is set to 'DISABLED'.0
Attributes
- Section
A1.2.1: Multi-tenant service providers facilitate logging and incident response for all customers.
- Service
Core
A1.2.1.14Checks if logging is enabled with a valid severity level for Kubernetes pod events. The rule is NON_COMPLIANT if logging is not enabled or pod logging does not have a severity level that is not valid.0
Attributes
- Section
A1.2.1: Multi-tenant service providers facilitate logging and incident response for all customers.
- Service
Core
A1.2.1.15Verifies whether a Kubernetes cluster has audit logging enabled. The rule is NON_COMPLIANT if the Kubernetes cluster does not have audit logging configured.1
Attributes
- Section
A1.2.1: Multi-tenant service providers facilitate logging and incident response for all customers.
- Service
API Server
A1.2.1.16Checks if a Kubernetes cluster has logging enabled for its API server. The rule is NON_COMPLIANT if 'apiServer.logging.enabled' is set to false.1
Attributes
- Section
A1.2.1: Multi-tenant service providers facilitate logging and incident response for all customers.
- Service
API Server
A1.2.1.17Checks if the logging configuration is set on active Kubernetes Pod specifications. This rule is NON_COMPLIANT if an active Pod does not have the logging configuration resource defined or the value for logging configuration is null in at least one container specification.0
Attributes
- Section
A1.2.1: Multi-tenant service providers facilitate logging and incident response for all customers.
- Service
Core
A1.2.1.18Checks if a Kubernetes cluster is configured with logging enabled. The rule is NON_COMPLIANT if logging for Kubernetes clusters is not enabled for all log types, including application logs, audit logs, and container logs.1
Attributes
- Section
A1.2.1: Multi-tenant service providers facilitate logging and incident response for all customers.
- Service
API Server
A1.2.1.19Checks if Kubernetes clusters are configured to send logs to a logging solution such as Fluentd or Fluent Bit. The rule is NON_COMPLIANT if logging is not properly set up or if log forwarding is disabled.0
Attributes
- Section
A1.2.1: Multi-tenant service providers facilitate logging and incident response for all customers.
- Service
Core
A1.2.1.20Checks if the LoadBalancer type Service in Kubernetes has access logging enabled. The rule is NON_COMPLIANT if the service annotations for access logging are not set to 'true' or if the specified log storage location does not match the designated S3 bucket name for logs.0
Attributes
- Section
A1.2.1: Multi-tenant service providers facilitate logging and incident response for all customers.
- Service
LoadBalancer Service
A1.2.1.21Checks if Kubernetes pods have logging enabled for monitoring purposes. The rule is NON_COMPLIANT if a pod does not have appropriate logging configuration enabled.0
Attributes
- Section
A1.2.1: Multi-tenant service providers facilitate logging and incident response for all customers.
- Service
Core
A1.2.1.22Checks if a Kubernetes cluster has audit logging enabled. The rule is NON_COMPLIANT if audit logging is not enabled for the cluster.1
Attributes
- Section
A1.2.1: Multi-tenant service providers facilitate logging and incident response for all customers.
- Service
API Server
A1.2.1.24Checks if a Kubernetes cluster has logging enabled for audit logs. The rule is NON_COMPLIANT if the Kubernetes cluster does not have audit logging enabled.1
Attributes
- Section
A1.2.1: Multi-tenant service providers facilitate logging and incident response for all customers.
- Service
API Server
A1.2.1.25Checks if Kubernetes Network Policies have logging enabled. The rule is NON_COMPLIANT if a logging type is not configured. You can specify which logging type you want the rule to check.0
Attributes
- Section
A1.2.1: Multi-tenant service providers facilitate logging and incident response for all customers.
- Service
API Server
A1.2.1.26Checks if Kubernetes clusters have logging configured to capture audit logs and are publishing them to a logging service such as Elasticsearch or a monitoring tool like Prometheus. The rule is NON_COMPLIANT if Kubernetes clusters do not have audit log publishing configured.1
Attributes
- Section
A1.2.1: Multi-tenant service providers facilitate logging and incident response for all customers.
- Service
API Server
A1.2.1.27Checks if the respective logs of Kubernetes pods are enabled. The rule is NON_COMPLIANT if any logs are not enabled for the pods.0
Attributes
- Section
A1.2.1: Multi-tenant service providers facilitate logging and incident response for all customers.
- Service
Core
A1.2.1.28Checks if Kubernetes clusters are logging audit events to a specific location. The rule is NON_COMPLIANT if audit logging is not enabled for a Kubernetes cluster or if the 'auditLogPath' parameter is provided but the logging destination does not match.1
Attributes
- Section
A1.2.1: Multi-tenant service providers facilitate logging and incident response for all customers.
- Service
API Server
A1.2.1.29Checks if Kubernetes clusters have the specified settings. The rule is NON_COMPLIANT if the Kubernetes cluster is not encrypted or encrypted with another key, or if a cluster does not have audit logging enabled.0
Attributes
- Section
A1.2.1: Multi-tenant service providers facilitate logging and incident response for all customers.
- Service
Core
A1.2.1.30Checks if DNS query logging is enabled for your Kubernetes cluster's CoreDNS configuration. The rule is NON_COMPLIANT if DNS query logging is not enabled.0
Attributes
- Section
A1.2.1: Multi-tenant service providers facilitate logging and incident response for all customers.
- Service
Core
A1.2.1.31Checks if Kubernetes services are publicly accessible. The rule is NON_COMPLIANT if a Kubernetes service is not listed in the excludedPublicServices parameter and the service type is LoadBalancer or NodePort.1
Attributes
- Section
A1.2.1: Multi-tenant service providers facilitate logging and incident response for all customers.
- Service
API Server
A1.2.1.32Checks if logging is enabled for your Kubernetes cluster's persistent volumes. The rule is NON_COMPLIANT if logging is not enabled.0
Attributes
- Section
A1.2.1: Multi-tenant service providers facilitate logging and incident response for all customers.
- Service
Core
A1.2.1.33Checks if Kubernetes Pods have logging enabled. The rule is NON_COMPLIANT if a Pod does not have logging enabled or the logging configuration is not at the minimum level required.0
Attributes
- Section
A1.2.1: Multi-tenant service providers facilitate logging and incident response for all customers.
- Service
Core
A1.2.1.34Checks if Kubernetes Network Policies are defined and enforced for all namespaces. The rule is NON_COMPLIANT if network policies are not defined for at least one namespace.1
Attributes
- Section
A1.2.1: Multi-tenant service providers facilitate logging and incident response for all customers.
- Service
Core
A1.2.1.35Checks if logging is enabled on Kubernetes network policies. The rule is NON_COMPLIANT if the logging is enabled but the logging destination does not match the expected value for the network policies.0
Attributes
- Section
A1.2.1: Multi-tenant service providers facilitate logging and incident response for all customers.
- Service
API Server
A1.2.1.36Checks if logging is enabled on Kubernetes Ingress resources. The rule is NON_COMPLIANT for an Ingress resource if it does not have logging enabled.0
Attributes
- Section
A1.2.1: Multi-tenant service providers facilitate logging and incident response for all customers.
- Service
API Server
A1.2.3: Multi-tenant service providers facilitate logging and incident response for all customers.10
A1.2.3.1Checks if security contact information is provided for Kubernetes cluster administrators. The rule is NON_COMPLIANT if security contact information for cluster administrators is not configured.0
Attributes
- Section
A1.2.3: Multi-tenant service providers facilitate logging and incident response for all customers.
- Service
Core
A3.2.5.1: PCI DSS scope is documented and validated.21
A3.2.5.1.1Checks if automated sensitive data discovery is enabled in Kubernetes. The rule is NON_COMPLIANT if automated sensitive data discovery is disabled. The rule is APPLICABLE for cluster administrator roles and NOT_APPLICABLE for regular user roles.0
Attributes
- Section
A3.2.5.1: PCI DSS scope is documented and validated.
- Service
Core
A3.2.5.1.2Checks if a specific Kubernetes PodSecurityPolicy is enabled in your cluster. The rule is NON_COMPLIANT if the 'privileged' attribute is set to 'true'.1
Attributes
- Section
A3.2.5.1: PCI DSS scope is documented and validated.
- Service
API Server
A3.2.5.2: PCI DSS scope is documented and validated.21
A3.2.5.1.3Checks if automated sensitive data discovery is enabled for Kubernetes Secrets Management. The rule is NON_COMPLIANT if automated sensitive data discovery for secrets is disabled. The rule is APPLICABLE for administrator accounts and NOT_APPLICABLE for regular user accounts.1
Attributes
- Section
A3.2.5.2: PCI DSS scope is documented and validated.
- Service
RBAC
A3.2.5.1.4Checks if a specific Kubernetes Security Tool (e.g., Kube-bench) is enabled in your cluster per namespace. The rule is NON_COMPLIANT if the 'status' attribute is not set to 'ENABLED'.0
Attributes
- Section
A3.2.5.2: PCI DSS scope is documented and validated.
- Service
Kubernetes Security
A3.3.1: PCI DSS is incorporated into business-as-usual (BAU) activities.81
A3.3.1.1Checks if OpenTelemetry tracing is enabled on Kubernetes Services. The rule is COMPLIANT if OpenTelemetry tracing is enabled for the Service and NON_COMPLIANT otherwise.0
Attributes
- Section
A3.3.1: PCI DSS is incorporated into business-as-usual (BAU) activities.
- Service
Core
A3.3.1.3Checks if Kubernetes alerts (e.g., from Prometheus or other monitoring tools) have an action configured in response to specific alert states (e.g., firing, pending, resolved). Optionally checks if any actions match a specified named resource. The rule is NON_COMPLIANT if no action is specified for the alert or the optional parameter.0
Attributes
- Section
A3.3.1: PCI DSS is incorporated into business-as-usual (BAU) activities.
- Service
Core
A3.3.1.5Checks whether Kubernetes events with the given metric name have the specified settings.0
Attributes
- Section
A3.3.1: PCI DSS is incorporated into business-as-usual (BAU) activities.
- Service
Core
A3.3.1.6Checks if Kubernetes audit logging is configured to send logs to a designated logging service (like Elasticsearch, Fluentd, or a specified log aggregation service). The audit configuration is NON_COMPLIANT if the log output destination is not set or is empty.1
Attributes
- Section
A3.3.1: PCI DSS is incorporated into business-as-usual (BAU) activities.
- Service
API Server
A3.3.1.7Checks if detailed monitoring (similar to Kubernetes 'prometheus') is enabled for Pods. The rule is NON_COMPLIANT if detailed monitoring is not enabled (i.e., the Prometheus metrics are not collected).0
Attributes
- Section
A3.3.1: PCI DSS is incorporated into business-as-usual (BAU) activities.
- Service
Core
A3.3.1.8Checks if Kubernetes Event Notifications are enabled for a specified resource (like a Pod). The rule is NON_COMPLIANT if Event Notifications are not set on the resource, or if the event type or destination do not match the expected criteria.0
Attributes
- Section
A3.3.1: PCI DSS is incorporated into business-as-usual (BAU) activities.
- Service
Core
A3.3.1.10Checks if Kubernetes Event logging is enabled for the delivery status of events sent to a namespace for the endpoints. The rule is NON_COMPLIANT if the event status notification for events is not enabled.0
Attributes
- Section
A3.3.1: PCI DSS is incorporated into business-as-usual (BAU) activities.
- Service
Kubernetes Event Management
A3.3.1.11Checks if the monitoring metrics collection is enabled for a Kubernetes network policy. The policy is NON_COMPLIANT if the 'metrics.enabled' field is set to false.0
Attributes
- Section
A3.3.1: PCI DSS is incorporated into business-as-usual (BAU) activities.
- Service
Core
A3.4.1: Logical access to the cardholder data environment is controlled and managed.2517
A3.4.1.1Checks if a Kubernetes Namespace has an attached resource-based policy (in this case, RoleBindings or ClusterRoleBindings) that prevents deletion of resources. The rule is NON_COMPLIANT if the Namespace does not have resource-based policies or has policies without a suitable 'deny' rule for deletion actions (such as delete pods, delete deployments, etc.).0
Attributes
- Section
A3.4.1: Logical access to the cardholder data environment is controlled and managed.
- Service
Core
A3.4.1.2Checks if Kubernetes pods have public IPs. The rule is NON_COMPLIANT if the pod spec contains a host network configuration with hostNetwork set to true, allowing the pod to use the node's network namespace.1
Attributes
- Section
A3.4.1: Logical access to the cardholder data environment is controlled and managed.
- Service
Core
A3.4.1.3Checks if Kubernetes Persistent Volume backups are public. The rule is NON_COMPLIANT if any Kubernetes Persistent Volume backups are public.1
Attributes
- Section
A3.4.1: Logical access to the cardholder data environment is controlled and managed.
- Service
RBAC
A3.4.1.4Checks if Kubernetes Persistent Volume (PV) snapshots are not publicly accessible. The rule is NON_COMPLIANT if one or more Persistent Volumes are configured to allow access from all users or unauthorized entities, meaning the snapshots are public.1
Attributes
- Section
A3.4.1: Logical access to the cardholder data environment is controlled and managed.
- Service
RBAC
A3.4.1.5Checks if Kubernetes Pods only have read-only access to their root filesystems. The rule is NON_COMPLIANT if the readOnlyRootFilesystem parameter in the securityContext of a PodSpec is set to 'false'.1
Attributes
- Section
A3.4.1: Logical access to the cardholder data environment is controlled and managed.
- Service
Core
A3.4.1.6Checks if Kubernetes Persistent Volume Claims (PVCs) use a defined access mode to enforce a specific root directory for storage. The rule is NON_COMPLIANT if the access mode allows unrestricted access to the entire file system.1
Attributes
- Section
A3.4.1: Logical access to the cardholder data environment is controlled and managed.
- Service
RBAC
A3.4.1.7Checks if Kubernetes Persistent Volume Claims (PVCs) are configured to enforce a specific user identity through security contexts. The rule is NON_COMPLIANT if 'runAsUser' is not defined in the security context or if parameters are provided and there is no match in the corresponding security parameters.1
Attributes
- Section
A3.4.1: Logical access to the cardholder data environment is controlled and managed.
- Service
RBAC
A3.4.1.8Checks if a Kubernetes cluster has network policies that restrict public access. The rule is NON_COMPLIANT if there are network policies allowing traffic from public IPs to any ports other than those specified in the allowed list (e.g., port 22 for SSH).1
Attributes
- Section
A3.4.1: Logical access to the cardholder data environment is controlled and managed.
- Service
Core
A3.4.1.9Checks whether Kubernetes namespaces have at least one service account.1
Attributes
- Section
A3.4.1: Logical access to the cardholder data environment is controlled and managed.
- Service
API Server
A3.4.1.10Checks if your Kubernetes service accounts have tokens or access credentials that have not been used within the specified number of days you provided. The rule is NON_COMPLIANT if there are inactive accounts not recently used.0
Attributes
- Section
A3.4.1: Logical access to the cardholder data environment is controlled and managed.
- Service
Core
A3.4.1.11Checks if the Kubernetes Role-Based Access Control (RBAC) permissions for the Service Account attached to the Pod prohibit public access. If the Service Account permissions allow public access, it is NON_COMPLIANT.1
Attributes
- Section
A3.4.1: Logical access to the cardholder data environment is controlled and managed.
- Service
RBAC
A3.4.1.12Checks if a Kubernetes database (like PostgreSQL or MySQL) snapshot is public. The rule is NON_COMPLIANT if any existing and new database snapshot is public.0
Attributes
- Section
A3.4.1: Logical access to the cardholder data environment is controlled and managed.
- Service
Core
A3.4.1.13Checks if the Kubernetes Database (such as PostgreSQL or MySQL deployed on Kubernetes) instances are not publicly accessible. The rule is NON_COMPLIANT if the service is exposed to the public network (e.g., type: LoadBalancer or external IP).0
Attributes
- Section
A3.4.1: Logical access to the cardholder data environment is controlled and managed.
- Service
Kubernetes Database Service
A3.4.1.14Checks if any Kubernetes Persistent Volume (PV) claims are publicly accessible. The rule is NON_COMPLIANT if any existing and new Kubernetes Persistent Volumes are exposed to the public.1
Attributes
- Section
A3.4.1: Logical access to the cardholder data environment is controlled and managed.
- Service
RBAC
A3.4.1.15Checks if Kubernetes clusters are not publicly accessible. The rule is NON_COMPLIANT if the service is exposed with a LoadBalancer type service in the service configuration.1
Attributes
- Section
A3.4.1: Logical access to the cardholder data environment is controlled and managed.
- Service
API Server
A3.4.1.16Checks if Kubernetes Secrets have confidential data protection settings enabled. The rule is NON_COMPLIANT if confidential data protection settings are not enabled for Kubernetes Secrets.1
Attributes
- Section
A3.4.1: Logical access to the cardholder data environment is controlled and managed.
- Service
Core
A3.4.1.17Checks if the required network policies are configured to restrict public access at the cluster level. The rule is only NON_COMPLIANT when the network policies set below do not match the corresponding rules in the configuration item.0
Attributes
- Section
A3.4.1: Logical access to the cardholder data environment is controlled and managed.
- Service
API Server
A3.4.1.18Checks if the necessary network policies and ingress settings are configured for the Kubernetes cluster to ensure proper access management and security. The rule is NON_COMPLIANT if the configuration does not match one or more required settings.1
Attributes
- Section
A3.4.1: Logical access to the cardholder data environment is controlled and managed.
- Service
Core
A3.4.1.19Checks if Kubernetes services are publicly accessible. The rule is NON_COMPLIANT if a Kubernetes service is not listed in the excludedPublicServices parameter and service type is LoadBalancer or NodePort.1
Attributes
- Section
A3.4.1: Logical access to the cardholder data environment is controlled and managed.
- Service
API Server
A3.4.1.20Checks if the Kubernetes Cluster has MFA Delete equivalent configurations for enhanced security measures on persistent storage. The rule is NON_COMPLIANT if there are no similar restrictions or security policies enabled.0
Attributes
- Section
A3.4.1: Logical access to the cardholder data environment is controlled and managed.
- Service
Core
A3.4.1.21Checks if your Kubernetes Persistent Volumes do not allow public read access. The rule checks the Persistent Volume policies, the access modes, and the role-based access control (RBAC) settings.1
Attributes
- Section
A3.4.1: Logical access to the cardholder data environment is controlled and managed.
- Service
RBAC
A3.4.1.22Checks if your Kubernetes Persistent Volumes (PVs) do not allow public write access. The rule verifies the access modes, resource quotas, and network policies associated with the persistent storage in the cluster.1
Attributes
- Section
A3.4.1: Logical access to the cardholder data environment is controlled and managed.
- Service
RBAC
A3.4.1.23Checks if direct internet access is disabled for a Kubernetes pod. The rule is NON_COMPLIANT if a pod has access to the internet through an external network policy or if it is deployed in a way that allows external traffic (e.g., using LoadBalancer service type).0
Attributes
- Section
A3.4.1: Logical access to the cardholder data environment is controlled and managed.
- Service
Core
A3.4.1.24Checks if Kubernetes Secrets have been accessed within a specified number of days. The rule is NON_COMPLIANT if a secret has not been accessed in 'unusedForDays' number of days. The default value is 90 days.0
Attributes
- Section
A3.4.1: Logical access to the cardholder data environment is controlled and managed.
- Service
Core
A3.4.1.25Checks if Kubernetes ConfigMaps created by the namespace are publicly accessible. The rule is NON_COMPLIANT if ConfigMaps with owner 'kube-system' are accessible without proper role-based access control (RBAC) settings.1
Attributes
- Section
A3.4.1: Logical access to the cardholder data environment is controlled and managed.
- Service
RBAC
A3.5.1: Suspicious events are identified and responded to.101
A3.5.1.1Checks if OpenTelemetry tracing is enabled on Kubernetes API Gateway (such as Istio or Ambassador). The rule is COMPLIANT if tracing is enabled and NON_COMPLIANT otherwise.0
Attributes
- Section
A3.5.1: Suspicious events are identified and responded to.
- Service
Kubernetes API Gateway
A3.5.1.2Checks if your Kubernetes deployments send event notifications to a specified monitoring service like Prometheus or an external alert manager. Optionally checks if specified notification channels (like Slack or email) are configured for alerts. The rule is NON_COMPLIANT if Kubernetes deployments do not send notifications.0
Attributes
- Section
A3.5.1: Suspicious events are identified and responded to.
- Service
Core
A3.5.1.3Checks if Kubernetes alerts (such as Prometheus Alertmanager alerts) have an action configured for firing, pending, or resolved states. Optionally checks if any actions match a named identifier. The rule is NON_COMPLIANT if there is no action specified for the alert or optional parameter.0
Attributes
- Section
A3.5.1: Suspicious events are identified and responded to.
- Service
Core
A3.5.1.5Checks whether Kubernetes alerts configured via Prometheus have the specified settings for the given metric name.0
Attributes
- Section
A3.5.1: Suspicious events are identified and responded to.
- Service
Core
A3.5.1.6Checks if Kubernetes logging is configured to send logs to a centralized logging system (e.g., Elasticsearch, Fluentd, etc.). The logging is CONCERNED if the logging configuration of the pod does not specify a destination for the logs.0
Attributes
- Section
A3.5.1: Suspicious events are identified and responded to.
- Service
Core
A3.5.1.7Checks if detailed monitoring is enabled for Kubernetes pods. The rule is NON_COMPLIANT if detailed monitoring is not enabled for the pods.0
Attributes
- Section
A3.5.1: Suspicious events are identified and responded to.
- Service
Core
A3.5.1.8Checks if Kubernetes Event Notifications are enabled for a specific resource (e.g., Pod, Deployment). The rule is NON_COMPLIANT if Event Notifications (via a specific service like Kubernetes Events or another notification system) are not set for a resource, or if the type of event or destination does not match the specified event types and destination parameters.0
Attributes
- Section
A3.5.1: Suspicious events are identified and responded to.
- Service
Core
A3.5.1.9Checks if a specific Kubernetes security feature (like Pod Security Policies or Network Policies) is enabled in a Kubernetes cluster. The rule is NON_COMPLIANT if the feature is not enabled.1
Attributes
- Section
A3.5.1: Suspicious events are identified and responded to.
- Service
API Server
A3.5.1.10Checks if Kubernetes Event Logging is enabled for the delivery status of notification messages sent to a specific service for the endpoints. The rule is NON_COMPLIANT if the delivery status notification for messages is not enabled.0
Attributes
- Section
A3.5.1: Suspicious events are identified and responded to.
- Service
Core
A3.5.1.11Checks if the Prometheus monitoring is enabled for Kubernetes deployments. The deployment is NON_COMPLIANT if the 'spec.template.spec.containers[].resources.limits.cpu' or 'spec.template.spec.containers[].resources.limits.memory' fields are not set, indicating that resource limits are not monitored.0
Attributes
- Section
A3.5.1: Suspicious events are identified and responded to.
- Service
Core