Skip to main content

​
Impact & Risk Analysis

  • Severity: High
  • CIS Benchmark: CIS 5.1.2
  • Impact: Privilege Escalation & Credential Theft. Kubernetes Secrets often contain sensitive service account tokens, database passwords, or external API keys. If an attacker gains get or list access to Secrets, they can retrieve these tokens and impersonate other service accounts (potentially gaining cluster-admin access) or access external resources.

​
Common Misconfiguration

Creating “developer” or “operator” roles that grant * (wildcard) access to resources in a namespace, inadvertently including secrets. Alternatively, granting get access to secrets to CI/CD tools that only need to deploy applications but not read back the credentials.

​
Vulnerable Example

# Vulnerable Role
# Grants read access to ALL resources, including Secrets
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: default
  name: dev-access
rules:
- apiGroups: [""]
  # VULNERABLE: Includes 'secrets' implicitly
  resources: ["*"]
  verbs: ["get", "list", "watch"]

​
Secure Example

# Secure Role
# Explicitly lists resources, EXCLUDING secrets
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: default
  name: dev-access-secure
rules:
- apiGroups: [""]
  # SECURE: secrets are missing from this list
  resources: ["pods", "services", "configmaps", "persistentvolumeclaims"]
  verbs: ["get", "list", "watch"]

​
Audit Procedure

Review the users and roles that have get, list, or watch access to secrets objects in the Kubernetes API. You can dump all Roles and ClusterRoles to search for secret access: 
kubectl get roles,clusterroles --all-namespaces -o yaml | grep -C 5 "secrets"
  • Analyze: Look for rules where resources includes secrets or *.
  • Verify: Ensure that only system components (like system:controller:namespace-controller) or specific administrators have this access.

​
Remediation

Where possible, restrict access to secret objects in the cluster by removing get, list, and watch permissions from Roles and ClusterRoles.
  1. Identify the Role granting excessive access.
  2. Edit the Role to remove secrets from the resources list.
  3. If resources: ["*"] is used, replace it with an explicit list of resources that does not include secrets.