iCompaas Support

Profile Applicability:
 • Level 1

Description:
 Minimize the number of users and service accounts who have the ability to create new pods in Kubernetes. Allowing the creation of pods in a namespace can potentially lead to privilege escalation, such as by assigning privileged service accounts or mounting hostPaths that access sensitive data, unless Pod Security Policies are in place.

Rationale:
 Creating pods provides the potential to escalate privileges by assigning elevated roles to those pods or manipulating their environment. This access should be granted sparingly to prevent misuse and minimize the security risk.

Impact:
 Pros:

• Reduces the risk of privilege escalation by limiting who can create pods.

• Prevents the unauthorized or excessive creation of pods with elevated privileges or access to sensitive data.

• Minimizes potential attack surfaces in the cluster.

Cons:

• Requires careful planning to ensure that system components that require pod creation access are not inadvertently restricted.

Default Value:
 By default, certain system components and service accounts, such as cluster-admin and controllers in the kube-system namespace, have the ability to create pods.

Pre-requisites:

• Access to Kubernetes via kubectl.

• Sufficient permissions to review and modify roles and bindings related to pod creation.

Remediation

Test Plan:

Using AWS Console:

1. Review users and service accounts with create access to pod objects.
   

2. Identify the roles or service accounts that have create access to pods in the cluster.

3. Review and ensure that only those who require this access for their duties are granted the ability to create pods.

Using AWS CLI:

1. Get the list of cluster role bindings for principals that have create access to pods:
   

   kubectl get clusterrolebindings -o=customcolumns=NAME:.metadata.name,ROLE:.roleRef.name,SUBJECT:.subjects[*].name

2. Review the output and ensure that only necessary service accounts or users have the ability to create pods.

Implementation Plan

Using AWS Console:

1. Identify roles and service accounts that currently have access to create pods.

2. Modify roles to limit create permissions on pods to only those necessary for cluster operation.

3. For service accounts that do not require pod creation, remove the associated role binding or restrict the scope of their permissions to avoid granting excessive access:

4. Ensure that essential system components that require the ability to create pods are not inadvertently restricted.

Using AWS CLI:

1. Review the clusterrolebindings for users or service accounts that have create permissions for pods.

2. Modify the bindings to ensure that only essential components or users have the ability to create pods.

3. Remove or modify unnecessary bindings with:
   

   kubectl delete clusterrolebinding [name]

4. Verify that system components that require this access are still able to function as expected.

Backout Plan

Using AWS Console:

1. If removing the ability to create pods causes issues with required workloads or system components, re-add the necessary role bindings for those users or service accounts.

2. Ensure that only the minimum required permissions are granted.

Using AWS CLI:

1. If issues arise, restore the clusterrolebinding for the users or service accounts who need to create pods:
   

   kubectl create clusterrolebinding [name] --clusterrole=cluster-admin --user=[user]

2. Ensure that access is restricted appropriately after restoring the bindings.

References:

1. Kubernetes RBAC Documentation

2. Kubernetes Pod Security Policies

3. Kubernetes Role-Based Access Control (RBAC)

CIS Controls: