Skip to main content

More Info:

The Kubernetes API stores secrets, which may be service account tokens for the Kubernetes API or credentials used by workloads in the cluster. Access to these secrets should be restricted to the smallest possible group of users to reduce the risk of privilege escalation.

Risk Level

High

Address

Security

Compliance Standards

  • APRA CPS 234 (Australia)
  • BSI C5 (Germany)
  • Brazil LGPD
  • CCPA / CPRA (California)
  • CIS Critical Security Controls v8
  • CIS GKE
  • CMMC 2.0
  • CSA Cloud Controls Matrix v4
  • DPDPA
  • Digital Operational Resilience Act (EU)
  • Essential 8
  • ISO/IEC 27017
  • ISO/IEC 27018
  • ISO/IEC 27701
  • KSA PDPL
  • MAS Technology Risk Management (Singapore)
  • MITRE ATT&CK (Cloud)
  • NIS2 Directive
  • NIST SP 800-171
  • NYDFS 23 NYCRR 500
  • SWIFT Customer Security Controls Framework
  • Sarbanes-Oxley IT General Controls
  • UK NCSC Cyber Assessment Framework

Triage and Remediation

Remediation

Manual Steps

  1. Identify roles with sensitive Secret access
    • Run on: any machine with kubectl access
  2. Review who is bound to each identified Role
    • Run on: any machine with kubectl access
    • Manually decide which users/service accounts/groups truly require get/list/watch on secrets.
  3. Inspect the exact Secret permissions in a Role
    • Run on: any machine with kubectl access
    • Manually determine which rules for resources: ["secrets"] and verbs: ["get","list","watch"] can be removed or narrowed (e.g., by resourceNames or fewer verbs).
  4. Edit Roles to minimize Secret access
    • Run on: any machine with kubectl access
      For each Role needing change:
    In the editor:
    • Locate rules: entries where resources includes secrets.
    • Remove unneeded verbs get, list, watch from verbs:.
    • If Secret access is not required, delete the entire rule containing secrets. Save and exit to apply changes.
  5. If necessary, adjust RoleBindings instead of Roles
    • Run on: any machine with kubectl access
      If some subjects no longer need Secret access but others still do:
    • Create a new, reduced-privilege Role without Secret access:
    • Rebind subjects that should not see secrets:
    • Then remove those subjects from the original RoleBinding:
  6. Verify minimized Secret access
    • Run on: any machine with kubectl access
On any machine with kubectl access:
  1. Discover roles that can get/list/watch secrets
  2. For each role, review who uses it (RoleBindings)
  3. Remove unnecessary get/list/watch verbs from a role (example)
    Export the current role:
    Edit /tmp/role-<NAMESPACE>-<ROLE_NAME>.yaml and, in any rule that includes resources: ["secrets"], remove get, list, and watch from the verbs list if not strictly required. For example, change:
    to:
    Apply the updated role:
  4. If a role’s secret access is not needed at all, remove the rule entirely
    In the same exported YAML, delete any rules entry where resources includes secrets, then apply:
  5. If access is still needed by a smaller group, create a more scoped role and re-bind
    Example minimal role allowing get on a specific secret only:
    Apply it:
    Then update or create a RoleBinding to use this scoped role instead of a broader one:
  6. Verification (re-run the audit logic)