Skip to content

fix(kubernetes): correlate secret rules with resourceNames - #7625

Open
0xTaoZ wants to merge 1 commit into
bridgecrewio:mainfrom
0xTaoZ:agent/fix-k8s-read-secrets-resource-names
Open

fix(kubernetes): correlate secret rules with resourceNames#7625
0xTaoZ wants to merge 1 commit into
bridgecrewio:mainfrom
0xTaoZ:agent/fix-k8s-read-secrets-resource-names

Conversation

@0xTaoZ

@0xTaoZ 0xTaoZ commented Jul 26, 2026

Copy link
Copy Markdown

Summary

Fixes #7616.

CKV2_K8S_5 previously treated rules.resourceNames exists as a role-wide safe condition. That meant a ClusterRole with one unrestricted secrets-read rule and a separate resourceNames-scoped secrets rule could pass, because the scoped rule satisfied the flattened attribute check.

This changes the policy to use a JSONPath condition that looks for the risky case on the same RBAC rule entry: secrets or wildcard resources, read verbs or wildcard verbs, and no resourceNames. The check now passes only when no such unscoped rule exists.

Tests

  • pytest -q tests/kubernetes/graph/checks/test_yaml_policies.py -k ReadAllSecrets
  • git diff --check
  • checkov -f tests/kubernetes/graph/checks/resources/ReadAllSecrets/Failing/MixedResourceNamesClusterRole.yaml --framework kubernetes --check CKV2_K8S_5 --quiet

Note: the CLI smoke scan emitted a local certificate warning while fetching Prisma guideline metadata, but still evaluated the fixture and reported the expected CKV2_K8S_5 failure.

Risk

Narrow policy-only change with a parser-backed Kubernetes graph regression fixture. Existing safe resourceNames-scoped RoleBinding coverage remains in the same test case.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

CKV2_K8S_5 passes when a ClusterRole/Role has one resourceNames-scoped secrets rule alongside a separate, unrestricted secrets rule

1 participant