Profile Applicability:
 • Level 1

Description:
 Minimize the use of wildcards (*) in Kubernetes Roles and ClusterRoles. Wildcards match all items, and their usage may inadvertently grant excessive access to new resources, which could pose a security risk.

Rationale:
 The principle of least privilege recommends that users should only have the access required for their specific role and no more. Using wildcards for roles or cluster roles grants broader access than necessary, which could unintentionally expose new resources, such as custom resource definitions (CRDs) or future Kubernetes features, to unauthorized users.

Impact:
 Pros:

  • Reduces the risk of inadvertently granting excessive access to new resources.

  • Helps ensure that users or service accounts only have the specific access they need.

  • Improves overall security by applying more granular access controls.

Cons:

  • More detailed and specific role definitions may require more maintenance and careful planning.

  • Misconfigured roles may lead to insufficient access for legitimate users or workloads.

Default Value:
 By default, roles and cluster roles may have wildcard permissions for certain resources or actions, especially when creating broad roles or during initial configurations.

Pre-requisites:

  • Access to the Kubernetes cluster using kubectl.

  • Sufficient privileges to modify and review roles and cluster roles.

Remediation

Test Plan:

Using AWS Console:

  1. Retrieve all roles defined across the cluster's namespaces 

  2. Review the role definitions and look for the use of the wildcard * in the resources or verbs fields.

  1. Retrieve all cluster roles defined in the cluster 

  2. Review the cluster roles and look for any wildcard * usage.

  1. For each role or cluster role with a wildcard, ensure it is replaced with specific objects or actions wherever possible.

Using AWS CLI:

  1. List the roles in all namespaces:

    kubectl get roles --all-namespaces -o yaml

  1. Review the YAML output for any roles using the wildcard *.

  2. List all cluster roles:

    kubectl get clusterroles -o yaml

  1. Check the cluster roles for any wildcard entries and ensure that each one is justified or replaced with more specific permissions.

Implementation Plan

Using AWS Console:

  1. Identify roles and cluster roles that use wildcards (*).

  2. Replace the wildcard with specific resource types or verbs where possible.

    • Example: Replace resources: ["*"] with the actual resources needed such as ["pods", "services"].

    • Example: Replace verbs: ["*"] with more specific verbs such as ["get", "list"].

  3. Apply the updated role or cluster role definitions.

  4. Test that the new role configurations do not break any required functionality.

Using AWS CLI:

  1. Modify roles and cluster roles to remove wildcards by replacing them with specific objects or actions.

  2. Example:

    kubectl apply -f updated-role-definition.yaml

  1. Ensure that no necessary functionality is disrupted by the changes.

Backout Plan

Using AWS Console:

  1. If the new role configurations cause issues, revert the changes to the original configuration.

  2. Restore wildcard usage if needed, but document the reasoning behind such usage for security reviews.

Using AWS CLI:

  1. If issues arise, revert the role and cluster role changes by applying the previous configuration.

  2. Ensure that roles with excessive access are only restored when absolutely necessary.

References:

  1. Kubernetes RBAC Documentation

  2. Kubernetes Secrets Management
  3. CIS EKS Benchmark v1.6.0