Skip to main content
Pulumi logo Pulumi logo
  1. Docs
  2. Reference
  3. Pre-built Policy Packs
  4. CIS Kubernetes
  5. AWS (EKS)

CIS Kubernetes - AWS (EKS)

    This page lists all 28 policies in the CIS Kubernetes pack for AWS (EKS), as published in cis-kubernetes-aws version 1.0.1.

    Policies by control

    2.1 Audit Logging — Enable audit logs for EKS clusters to track all API server requests and administrative actions.

    3.1-3.2 Kubelet Configuration — Ensure kubelet configuration follows security best practices including proper authentication, authorization, and file permissions.

    4.1 RBAC and Authentication — Restrict administrator privileges to dedicated administrator accounts on enterprise assets. Implement proper RBAC controls.

    4.2 Pod Security — Implement and manage a firewall on servers. Minimize the admission of privileged containers and containers with dangerous capabilities.

    4.4-4.5 Secret Management and Namespaces — Prefer using secrets as files over secrets as environment variables. Ensure default namespace is not used for workloads.

    5.1 Container Registry Security — Ensure Image Vulnerability Scanning using Amazon ECR image scanning. Minimize user access to Amazon ECR.

    5.2-5.3 IAM and Encryption — Prefer using dedicated EKS Service Accounts. Ensure Kubernetes Secrets are encrypted using Customer Master Keys (CMKs) managed in AWS KMS.

    5.4 Network Security — Restrict Access to the Control Plane Endpoint. Ensure Network Policy is Enabled and set as appropriate. Encrypt traffic to HTTPS load balancers with TLS certificates.

    Policy details

    eks-cluster-access-manager-enabled

    Severity: medium · Enforcement: advisory

    Ensure EKS clusters use the Cluster Access Manager API for enhanced access control management.

    • 4.1 RBAC and Authentication — Restrict administrator privileges to dedicated administrator accounts on enterprise assets. Implement proper RBAC controls.
    Remediation
    Fix: Enable Cluster Access Manager for EKS Cluster
    const cluster = new aws.eks.Cluster("cluster", {
        accessConfig: {
            authenticationMode: "API_AND_CONFIG_MAP",  // Or "API" for full EKS Access API
            bootstrapClusterCreatorAdminPermissions: false,
        },
        // ... other config
    });
    

    eks-cluster-audit-logging-enabled

    Severity: high · Enforcement: advisory

    Ensure EKS clusters have audit logging enabled for security monitoring and compliance.

    • 2.1 Audit Logging — Enable audit logs for EKS clusters to track all API server requests and administrative actions.
    Remediation
    Fix: Enable Audit Logging for EKS Cluster
    const cluster = new aws.eks.Cluster("cluster", {
        enabledClusterLogTypes: [
            "api",
            "audit",
            "authenticator",
            "controllerManager",
            "scheduler"
        ],
        // ... other config
    });
    

    eks-cluster-cloudwatch-logs-enabled

    Severity: medium · Enforcement: advisory

    Ensure EKS clusters have all CloudWatch log types enabled for comprehensive audit logging.

    • 2.1 Audit Logging — Enable audit logs for EKS clusters to track all API server requests and administrative actions.
    Remediation
    Fix: Enable All CloudWatch Log Types for EKS Cluster
    const cluster = new aws.eks.Cluster("cluster", {
        enabledClusterLogTypes: [
            "api",
            "audit",
            "authenticator",
            "controllerManager",
            "scheduler"
        ],
        // ... other config
    });
    

    eks-cluster-endpoint-restrict-public-access

    Severity: high · Enforcement: advisory

    Ensure EKS cluster endpoints are not publicly accessible for enhanced security.

    • 5.4 Network Security — Restrict Access to the Control Plane Endpoint. Ensure Network Policy is Enabled and set as appropriate. Encrypt traffic to HTTPS load balancers with TLS certificates.
    Remediation
    Fix: Restrict Public Access to EKS Cluster Endpoint
    const cluster = new aws.eks.Cluster("cluster", {
        vpcConfig: {
            endpointPublicAccess: false,  // Disable public access
            endpointPrivateAccess: true,  // Enable private access
            // ... other config
        },
    });
    

    eks-ecr-image-scanning-enabled

    Severity: medium · Enforcement: advisory

    Ensure ECR repositories have image scanning enabled for vulnerability detection.

    • 5.1 Container Registry Security — Ensure Image Vulnerability Scanning using Amazon ECR image scanning. Minimize user access to Amazon ECR.
    Remediation
    Fix: Enable Image Scanning for ECR Repository
    const repository = new aws.ecr.Repository("repository", {
        imageScanningConfiguration: {
            scanOnPush: true,
        },
        // ... other config
    });
    

    eks-ecr-private-repository

    Severity: low · Enforcement: advisory

    Ensure ECR repositories do not have overly permissive access policies.

    • 5.1 Container Registry Security — Ensure Image Vulnerability Scanning using Amazon ECR image scanning. Minimize user access to Amazon ECR.
    Remediation
    Fix: Minimize Access to ECR Repository

    Review and restrict ECR repository policies to grant access only to necessary principals:

    const repositoryPolicy = new aws.ecr.RepositoryPolicy("policy", {
        repository: repository.name,
        policy: JSON.stringify({
            Version: "2012-10-17",
            Statement: [{
                Sid: "AllowPullFromSpecificRole",
                Effect: "Allow",
                Principal: {
                    AWS: specificRoleArn,  // Only specific role, not "*"
                },
                Action: [
                    "ecr:GetDownloadUrlForLayer",
                    "ecr:BatchGetImage",
                    "ecr:BatchCheckLayerAvailability",
                ],
            }],
        }),
    });
    

    eks-iam-authenticator-enabled

    Severity: medium · Enforcement: advisory

    Ensure EKS clusters do not use legacy ConfigMap-only authentication mode and instead use EKS Access API with IAM.

    • 4.1 RBAC and Authentication — Restrict administrator privileges to dedicated administrator accounts on enterprise assets. Implement proper RBAC controls.
    Remediation
    Fix: Use IAM Authentication for EKS

    AWS EKS uses IAM authentication by default. Ensure proper IAM role mappings are configured:

    // Create access entry for IAM principal
    const accessEntry = new aws.eks.AccessEntry("userAccess", {
        clusterName: cluster.name,
        principalArn: userRoleArn,
        type: "STANDARD",
    });
    
    // Associate with access policy
    const policyAssociation = new aws.eks.AccessPolicyAssociation("userPolicy", {
        clusterName: cluster.name,
        principalArn: userRoleArn,
        policyArn: "arn:aws:eks::aws:cluster-access-policy/AmazonEKSViewPolicy",
        accessScope: {
            type: "cluster",
        },
    });
    

    eks-launch-template-kubelet-config

    Severity: high · Enforcement: advisory

    Detects explicitly insecure kubelet configurations in EKS launch templates. Only reports violations for configurations that are provably wrong (e.g., anonymous auth enabled, overly permissive file permissions).

    • 3.1-3.2 Kubelet Configuration — Ensure kubelet configuration follows security best practices including proper authentication, authorization, and file permissions.
    Remediation
    Fix: Remove Insecure Kubelet Configurations

    This policy detects EXPLICITLY insecure configurations. Remove or fix any detected issues:

    Insecure flags to avoid:

    • --anonymous-auth=true (remove or set to false)
    • --authorization-mode=AlwaysAllow (use Webhook instead)
    • --read-only-port=<non-zero> (set to 0)
    • --streaming-connection-idle-timeout=0 (set to 5m or appropriate value)
    • --make-iptables-util-chains=false (remove or set to true)
    • --rotate-certificates=false (remove or set to true)

    Insecure file permissions to avoid:

    • chmod 777, chmod 755, etc. on kubeconfig files (use 644 or more restrictive)
    • chown <non-root>:<non-root> on kubeconfig files (use root:root)

    Example secure configuration:

    const launchTemplate = new aws.ec2.LaunchTemplate("nodeTemplate", {
        userData: pulumi.all([cluster.name]).apply(([clusterName]) => {
            const script = `#!/bin/bash
    set -o xtrace
    /etc/eks/bootstrap.sh ${clusterName} \\
      --kubelet-extra-args '--read-only-port=0 \\
        --anonymous-auth=false \\
        --authorization-mode=Webhook \\
        --streaming-connection-idle-timeout=5m \\
        --rotate-certificates=true'
    
    ##### Set secure file permissions
    chmod 644 /var/lib/kubelet/kubeconfig
    chown root:root /var/lib/kubelet/kubeconfig`;
            return Buffer.from(script).toString('base64');
        }),
    });
    

    Note: This policy does NOT fail on missing secure configurations - it only fails on EXPLICITLY insecure ones.

    eks-load-balancer-tls-encryption

    Severity: high · Enforcement: advisory

    Ensure internet-facing load balancers use HTTPS listeners with TLS certificates for encrypted traffic. Internal load balancers are exempt from this requirement.

    • 5.4 Network Security — Restrict Access to the Control Plane Endpoint. Ensure Network Policy is Enabled and set as appropriate. Encrypt traffic to HTTPS load balancers with TLS certificates.
    Remediation
    Fix: Configure TLS for Load Balancer

    For Application Load Balancers:

    const listener = new aws.lb.Listener("httpsListener", {
        loadBalancerArn: lb.arn,
        port: 443,
        protocol: "HTTPS",
        sslPolicy: "ELBSecurityPolicy-TLS-1-2-2017-01",
        certificateArn: certificateArn,
        defaultActions: [{
            type: "forward",
            targetGroupArn: targetGroup.arn,
        }],
    });
    

    For Classic Load Balancers:

    const listener = new aws.elb.LoadBalancer("lb", {
        listeners: [{
            instancePort: 80,
            instanceProtocol: "http",
            lbPort: 443,
            lbProtocol: "https",
            sslCertificateId: certificateArn,
        }],
    });
    

    Note: This policy only applies to internet-facing load balancers. Internal load balancers are exempt from TLS requirements.

    eks-network-policy-enabled

    Severity: medium · Enforcement: advisory

    Ensure EKS clusters have a network policy add-on enabled for pod-level network segmentation. Supports vpc-cni with network policy enabled and Calico addon. This policy validates that each EKS cluster has at least one network policy addon configured.

    • 5.4 Network Security — Restrict Access to the Control Plane Endpoint. Ensure Network Policy is Enabled and set as appropriate. Encrypt traffic to HTTPS load balancers with TLS certificates.
    Remediation
    Fix: Enable Network Policy for EKS Cluster

    Install a CNI plugin that supports network policies, such as AWS VPC CNI with Network Policy support or Calico:

    // Option 1: Enable VPC CNI Network Policy support
    const addon = new aws.eks.Addon("vpc-cni", {
        clusterName: cluster.name,
        addonName: "vpc-cni",
        configurationValues: JSON.stringify({
            enableNetworkPolicy: "true",
        }),
    });
    
    // Option 2: Install Calico
    const calico = new aws.eks.Addon("calico", {
        clusterName: cluster.name,
        addonName: "calico",
    });
    

    eks-node-group-iam-role-minimal-policy

    Severity: medium · Enforcement: advisory

    Ensure EKS node groups have minimal IAM permissions, especially read-only access to ECR.

    • 5.2-5.3 IAM and Encryption — Prefer using dedicated EKS Service Accounts. Ensure Kubernetes Secrets are encrypted using Customer Master Keys (CMKs) managed in AWS KMS.
    Remediation
    Fix: Use Read-Only ECR Access for Node Groups

    Attach only the AmazonEC2ContainerRegistryReadOnly policy for ECR access:

    const nodeRole = new aws.iam.Role("nodeRole", {
        assumeRolePolicy: JSON.stringify({
            Version: "2012-10-17",
            Statement: [{
                Effect: "Allow",
                Principal: { Service: "ec2.amazonaws.com" },
                Action: "sts:AssumeRole",
            }],
        }),
    });
    
    // Attach read-only ECR policy
    new aws.iam.RolePolicyAttachment("nodeRoleEcrReadOnly", {
        role: nodeRole.name,
        policyArn: "arn:aws:iam::aws:policy/AmazonEC2ContainerRegistryReadOnly",
    });
    

    eks-node-group-launch-template-required

    Severity: medium · Enforcement: advisory

    Ensure EKS node groups use launch templates to enforce kubelet configuration.

    • 3.1-3.2 Kubelet Configuration — Ensure kubelet configuration follows security best practices including proper authentication, authorization, and file permissions.
    Remediation
    Fix: Use Launch Template for Node Group

    Create a launch template with proper kubelet configuration:

    const launchTemplate = new aws.ec2.LaunchTemplate("nodeTemplate", {
        userData: pulumi.interpolate`#!/bin/bash
    set -o xtrace
    /etc/eks/bootstrap.sh ${cluster.name} \
      --kubelet-extra-args '--read-only-port=0 --anonymous-auth=false --authorization-mode=Webhook'
    `,
    });
    
    const nodeGroup = new aws.eks.NodeGroup("nodes", {
        clusterName: cluster.name,
        launchTemplate: {
            id: launchTemplate.id,
            version: pulumi.interpolate`${launchTemplate.latestVersion}`,
        },
        // ... other config
    });
    

    eks-secrets-encryption-kms-enabled

    Severity: critical · Enforcement: advisory

    Ensure EKS clusters encrypt Kubernetes secrets using AWS KMS Customer Master Keys.

    • 5.2-5.3 IAM and Encryption — Prefer using dedicated EKS Service Accounts. Ensure Kubernetes Secrets are encrypted using Customer Master Keys (CMKs) managed in AWS KMS.
    Remediation
    Fix: Enable KMS Encryption for EKS Secrets
    const kmsKey = new aws.kms.Key("eksKmsKey", {
        description: "EKS Secret Encryption Key",
    });
    
    const cluster = new aws.eks.Cluster("cluster", {
        encryptionConfig: {
            provider: {
                keyArn: kmsKey.arn,
            },
            resources: ["secrets"],
        },
        // ... other config
    });
    

    eks-service-accounts-iam-role-binding

    Severity: low · Enforcement: advisory

    Reminder to configure OIDC providers for EKS clusters to enable IRSA. This is a basic check that cannot verify correct configuration.

    • 5.2-5.3 IAM and Encryption — Prefer using dedicated EKS Service Accounts. Ensure Kubernetes Secrets are encrypted using Customer Master Keys (CMKs) managed in AWS KMS.
    Remediation
    Reminder: Create OIDC Provider for IRSA
    const oidcProvider = new aws.iam.OpenIdConnectProvider("eksOidc", {
        clientIdLists: ["sts.amazonaws.com"],
        thumbprintLists: [thumbprint],
        url: cluster.identity.oidcs[0].issuer,
    });
    

    Note: This policy only checks if OIDC providers exist, not if they’re correctly configured.

    k8s-cluster-admin-role-binding-minimized

    Severity: high · Enforcement: advisory

    Ensure cluster-admin ClusterRole is bound to a minimal number of users and service accounts.

    • 4.1 RBAC and Authentication — Restrict administrator privileges to dedicated administrator accounts on enterprise assets. Implement proper RBAC controls.
    Remediation
    Fix: Minimize cluster-admin Role Bindings

    Use more specific roles instead of cluster-admin:

    // Instead of binding cluster-admin, create specific roles
    const role = new k8s.rbac.v1.Role("specificRole", {
        metadata: { namespace: "default" },
        rules: [{
            apiGroups: [""],
            resources: ["pods"],
            verbs: ["get", "list", "watch"],
        }],
    });
    
    const roleBinding = new k8s.rbac.v1.RoleBinding("specificBinding", {
        metadata: { namespace: "default" },
        roleRef: {
            apiGroup: "rbac.authorization.k8s.io",
            kind: "Role",
            name: role.metadata.name,
        },
        subjects: [{
            kind: "User",
            name: "specific-user",
        }],
    });
    

    k8s-default-namespace-not-used

    Severity: medium · Enforcement: advisory

    Ensure workloads are not deployed to the default namespace.

    • 4.4-4.5 Secret Management and Namespaces — Prefer using secrets as files over secrets as environment variables. Ensure default namespace is not used for workloads.
    Remediation
    Fix: Use Dedicated Namespaces

    Create and use dedicated namespaces:

    const namespace = new k8s.core.v1.Namespace("app-namespace", {
        metadata: {
            name: "my-app",
        },
    });
    
    const deployment = new k8s.apps.v1.Deployment("app", {
        metadata: {
            namespace: namespace.metadata.name,
        },
        // ... rest of deployment spec
    });
    

    k8s-default-service-accounts-not-used

    Severity: medium · Enforcement: advisory

    Ensure workloads do not use the default service account.

    • 4.1 RBAC and Authentication — Restrict administrator privileges to dedicated administrator accounts on enterprise assets. Implement proper RBAC controls.
    Remediation
    Fix: Use Dedicated Service Accounts

    Create and use dedicated service accounts for workloads:

    const serviceAccount = new k8s.core.v1.ServiceAccount("appServiceAccount", {
        metadata: {
            namespace: "default",
            name: "my-app-sa",
        },
    });
    
    const deployment = new k8s.apps.v1.Deployment("app", {
        spec: {
            template: {
                spec: {
                    serviceAccountName: serviceAccount.metadata.name,
                    // ... rest of pod spec
                },
            },
        },
    });
    

    k8s-pod-security-allow-privilege-escalation-minimized

    Severity: high · Enforcement: advisory

    Ensure containers do not allow privilege escalation.

    • 4.2 Pod Security — Implement and manage a firewall on servers. Minimize the admission of privileged containers and containers with dangerous capabilities.
    Remediation
    Fix: Disable Privilege Escalation

    Set allowPrivilegeEscalation to false in container security context:

    const pod = new k8s.core.v1.Pod("pod", {
        spec: {
            containers: [{
                name: "app",
                image: "nginx",
                securityContext: {
                    allowPrivilegeEscalation: false,
                    runAsNonRoot: true,
                    capabilities: {
                        drop: ["ALL"],
                    },
                },
            }],
        },
    });
    

    k8s-pod-security-host-ipc-minimized

    Severity: high · Enforcement: advisory

    Ensure containers do not share the host IPC namespace.

    • 4.2 Pod Security — Implement and manage a firewall on servers. Minimize the admission of privileged containers and containers with dangerous capabilities.
    Remediation
    Fix: Disable Host IPC Sharing

    Remove hostIPC from pod spec:

    const pod = new k8s.core.v1.Pod("pod", {
        spec: {
            hostIPC: false,  // Explicitly set to false or remove
            containers: [{
                name: "app",
                image: "nginx",
            }],
        },
    });
    

    k8s-pod-security-host-network-minimized

    Severity: high · Enforcement: advisory

    Ensure containers do not share the host network namespace.

    • 4.2 Pod Security — Implement and manage a firewall on servers. Minimize the admission of privileged containers and containers with dangerous capabilities.
    Remediation
    Fix: Disable Host Network Sharing

    Remove hostNetwork from pod spec:

    const pod = new k8s.core.v1.Pod("pod", {
        spec: {
            hostNetwork: false,  // Explicitly set to false or remove
            containers: [{
                name: "app",
                image: "nginx",
            }],
        },
    });
    

    k8s-pod-security-host-pid-minimized

    Severity: high · Enforcement: advisory

    Ensure containers do not share the host process ID namespace.

    • 4.2 Pod Security — Implement and manage a firewall on servers. Minimize the admission of privileged containers and containers with dangerous capabilities.
    Remediation
    Fix: Disable Host PID Sharing

    Remove hostPID from pod spec:

    const pod = new k8s.core.v1.Pod("pod", {
        spec: {
            hostPID: false,  // Explicitly set to false or remove
            containers: [{
                name: "app",
                image: "nginx",
            }],
        },
    });
    

    k8s-pod-security-privileged-containers-minimized

    Severity: critical · Enforcement: advisory

    Ensure containers do not run in privileged mode.

    • 4.2 Pod Security — Implement and manage a firewall on servers. Minimize the admission of privileged containers and containers with dangerous capabilities.
    Remediation
    Fix: Disable Privileged Mode

    Remove privileged flag from container security context:

    const pod = new k8s.core.v1.Pod("pod", {
        spec: {
            containers: [{
                name: "app",
                image: "nginx",
                securityContext: {
                    privileged: false,  // Explicitly set to false or remove
                    runAsNonRoot: true,
                    capabilities: {
                        drop: ["ALL"],
                    },
                },
            }],
        },
    });
    

    k8s-rbac-bind-impersonate-escalate-minimized

    Severity: critical · Enforcement: advisory

    Ensure Roles and ClusterRoles do not grant dangerous permissions: bind, impersonate, and escalate, which can lead to privilege escalation.

    • 4.1 RBAC and Authentication — Restrict administrator privileges to dedicated administrator accounts on enterprise assets. Implement proper RBAC controls.
    Remediation
    Fix: Remove Dangerous RBAC Permissions

    Avoid granting bind, impersonate, and escalate permissions:

    // Bad: DON'T grant these dangerous permissions
    const dangerousRole = new k8s.rbac.v1.ClusterRole("dangerous", {
        rules: [{
            apiGroups: ["rbac.authorization.k8s.io"],
            resources: ["clusterroles", "roles"],
            verbs: ["bind", "escalate"],  // DON'T DO THIS
        }, {
            apiGroups: [""],
            resources: ["users", "groups", "serviceaccounts"],
            verbs: ["impersonate"],  // DON'T DO THIS
        }],
    });
    
    // Good: Grant only necessary read permissions
    const safeRole = new k8s.rbac.v1.ClusterRole("safe", {
        rules: [{
            apiGroups: ["rbac.authorization.k8s.io"],
            resources: ["clusterroles", "roles"],
            verbs: ["get", "list", "watch"],  // Read-only
        }],
    });
    

    Why these are dangerous:

    • bind: Allows binding roles with more permissions than the user has
    • impersonate: Allows acting as another user/service account
    • escalate: Allows creating roles with more permissions than the user has

    k8s-rbac-create-pods-minimized

    Severity: medium · Enforcement: advisory

    Ensure Roles and ClusterRoles do not grant excessive permissions to create pods or resources that can create pods (deployments, jobs, etc.).

    • 4.1 RBAC and Authentication — Restrict administrator privileges to dedicated administrator accounts on enterprise assets. Implement proper RBAC controls.
    Remediation
    Fix: Minimize Pod Creation Permissions

    Avoid granting create permissions on pods and pod-creating resources:

    // Good: Read-only access to pods
    const podReader = new k8s.rbac.v1.Role("podReader", {
        metadata: { namespace: "default" },
        rules: [{
            apiGroups: [""],
            resources: ["pods"],
            verbs: ["get", "list", "watch"],  // Read-only
        }],
    });
    
    // Bad: Avoid granting pod creation abilities
    const podCreator = new k8s.rbac.v1.Role("podCreator", {
        rules: [{
            apiGroups: [""],
            resources: ["pods", "pods/exec", "pods/attach"],
            verbs: ["create", "*"],  // DON'T DO THIS unless absolutely necessary
        }],
    });
    

    Resources that can create pods and should be restricted:

    • pods, pods/exec, pods/attach, pods/portforward
    • deployments, replicasets, statefulsets, daemonsets, jobs, cronjobs
    • replicationcontrollers

    k8s-rbac-secret-access-minimized

    Severity: critical · Enforcement: advisory

    Ensure Roles and ClusterRoles do not grant excessive permissions to secrets (create, update, patch, delete, or wildcard verbs).

    • 4.1 RBAC and Authentication — Restrict administrator privileges to dedicated administrator accounts on enterprise assets. Implement proper RBAC controls.
    Remediation
    Fix: Minimize Secret Access Permissions

    Limit secret access to read-only (get, list, watch) unless write access is explicitly required:

    // Good: Read-only secret access
    const readOnlyRole = new k8s.rbac.v1.Role("secretReader", {
        metadata: { namespace: "default" },
        rules: [{
            apiGroups: [""],
            resources: ["secrets"],
            verbs: ["get", "list", "watch"],  // Read-only access
        }],
    });
    
    // Bad: Avoid granting write access to secrets
    const writeRole = new k8s.rbac.v1.Role("secretWriter", {
        rules: [{
            apiGroups: [""],
            resources: ["secrets"],
            verbs: ["*"],  // DON'T DO THIS
        }],
    });
    

    Only grant create/update/delete/patch permissions when absolutely necessary and document the justification.

    k8s-rbac-wildcard-use-minimized

    Severity: high · Enforcement: advisory

    Ensure Roles and ClusterRoles do not use wildcards for resources, verbs, or apiGroups.

    • 4.1 RBAC and Authentication — Restrict administrator privileges to dedicated administrator accounts on enterprise assets. Implement proper RBAC controls.
    Remediation
    Fix: Remove Wildcards from RBAC Rules

    Be specific about resources, verbs, and API groups:

    const role = new k8s.rbac.v1.Role("specificRole", {
        metadata: { namespace: "default" },
        rules: [{
            apiGroups: [""],  // Specific API group, not "*"
            resources: ["pods", "services"],  // Specific resources, not "*"
            verbs: ["get", "list", "watch"],  // Specific verbs, not "*"
        }],
    });
    

    k8s-secrets-as-files-not-env-vars

    Severity: medium · Enforcement: advisory

    Ensure secrets are mounted as files via volumes rather than exposed as environment variables.

    • 4.4-4.5 Secret Management and Namespaces — Prefer using secrets as files over secrets as environment variables. Ensure default namespace is not used for workloads.
    Remediation
    Fix: Mount Secrets as Files

    Use volume mounts instead of environment variables for secrets:

    // Bad: Using secrets as environment variables
    const badPod = new k8s.core.v1.Pod("bad-pod", {
        spec: {
            containers: [{
                name: "app",
                image: "myapp:latest",
                env: [{
                    name: "DB_PASSWORD",
                    valueFrom: {
                        secretKeyRef: {
                            name: "db-secret",
                            key: "password",
                        },
                    },
                }],
            }],
        },
    });
    
    // Good: Mount secrets as files
    const goodPod = new k8s.core.v1.Pod("good-pod", {
        spec: {
            containers: [{
                name: "app",
                image: "myapp:latest",
                volumeMounts: [{
                    name: "secret-volume",
                    mountPath: "/etc/secrets",
                    readOnly: true,
                }],
            }],
            volumes: [{
                name: "secret-volume",
                secret: {
                    secretName: "db-secret",
                },
            }],
        },
    });
    // Access secret via: cat /etc/secrets/password
    

    Benefits of file-based secrets:

    • Not visible in process listings
    • Not logged by default
    • Can be rotated without container restart (with proper file watching)

    k8s-service-account-token-mounted-minimized

    Severity: medium · Enforcement: advisory

    Ensure service account tokens are not automatically mounted in pods unless explicitly required.

    • 4.1 RBAC and Authentication — Restrict administrator privileges to dedicated administrator accounts on enterprise assets. Implement proper RBAC controls.
    Remediation
    Fix: Disable Service Account Token Auto-Mounting

    Set automountServiceAccountToken: false unless the pod needs Kubernetes API access:

    // Good: Disable auto-mounting when not needed
    const pod = new k8s.core.v1.Pod("myPod", {
        metadata: { name: "my-pod" },
        spec: {
            automountServiceAccountToken: false,  // Explicitly disable
            containers: [{
                name: "app",
                image: "nginx:latest",
            }],
        },
    });
    
    // Also disable at ServiceAccount level
    const sa = new k8s.core.v1.ServiceAccount("myServiceAccount", {
        metadata: { name: "my-sa" },
        automountServiceAccountToken: false,  // Disable by default
    });
    

    Only enable when the pod explicitly requires Kubernetes API access.

      The infrastructure as code platform for any cloud.