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 Pulumi Cloud feature is available in the Business Critical edition.

    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.