Delete secrets Kubernetes ClusterRole warns about viewing secrets

[evankanderson]

IDs

ksv041

Description

Using trivy to scan a manifest with a ClusterRole that grants delete only on secrets leads to the following critical warning:

CRITICAL: ClusterRole 'delete-controlled-resources' shouldn't have access to manage resource 'secrets'
════════════════════════════════════════
Viewing secrets at the cluster-scope is akin to cluster-admin in most clusters as there are typically at least one service accounts (their token stored in a secret) bound to cluster-admin directly or a role/clusterrole that gives similar permissions.

See https://avd.aquasec.com/misconfig/ksv041

Reproduction Steps

1. Add a ClusterRole with delete permission on secrets, e.g.

   
   apiVersion: rbac.authorization.k8s.io/v1
   kind: ClusterRole
   metadata:
     # We expect that these resources will be managed by controllers, so "delete"
     # really allows "switch it off and on again"
     name: delete-controlled-resources
   rules:
     - apiGroups: [""]
       resources: ["secrets", "pods"]
       verbs: ["delete"]

2. Run trivy fs --scanners misconfig on the file or a directory containing it, and get the warning above

Target

Filesystem

Scanner

Misconfiguration

Target OS

No response

Debug Output

$ trivy fs --scanners misconfig --severity CRITICAL --debug ./argocd/production/cluster-config/eng-debug.yaml 
2024-05-16T21:41:33-07:00	DEBUG	Parsed severities	severities=[CRITICAL]
2024-05-16T21:41:33-07:00	DEBUG	Ignore statuses	statuses=[]
2024-05-16T21:41:33-07:00	DEBUG	Cache dir	dir="/Users/evan/Library/Caches/trivy"
2024-05-16T21:41:33-07:00	INFO	Misconfiguration scanning is enabled
2024-05-16T21:41:33-07:00	DEBUG	Policies successfully loaded from disk
2024-05-16T21:41:33-07:00	DEBUG	Enabling misconfiguration scanners	scanners=[azure-arm cloudformation dockerfile helm kubernetes terraform terraformplan-json terraformplan-snapshot]
2024-05-16T21:41:33-07:00	DEBUG	[nuget] The nuget packages directory couldn't be found. License search disabled
2024-05-16T21:41:33-07:00	DEBUG	Scanning files for misconfigurations...	scanner="Helm"
2024-05-16T21:41:33-07:00	DEBUG	[misconf] 41:33.342567000 helm.scanner.rego                Overriding filesystem for checks!
2024-05-16T21:41:33-07:00	DEBUG	[misconf] 41:33.343081000 helm.scanner.rego                Loaded 3 embedded libraries.
2024-05-16T21:41:33-07:00	DEBUG	[misconf] 41:33.369300000 helm.scanner.rego                Loaded 191 embedded policies.
2024-05-16T21:41:33-07:00	DEBUG	[misconf] 41:33.400396000 helm.scanner.rego                Loaded 194 policies from disk.
2024-05-16T21:41:33-07:00	DEBUG	[misconf] 41:33.400643000 helm.scanner.rego                Overriding filesystem for data!
2024-05-16T21:41:33-07:00	DEBUG	Scanning files for misconfigurations...	scanner="Kubernetes"
2024-05-16T21:41:33-07:00	DEBUG	[misconf] 41:33.586033000 kubernetes.scanner.rego          Overriding filesystem for checks!
2024-05-16T21:41:33-07:00	DEBUG	[misconf] 41:33.586600000 kubernetes.scanner.rego          Loaded 3 embedded libraries.
2024-05-16T21:41:33-07:00	DEBUG	[misconf] 41:33.614351000 kubernetes.scanner.rego          Loaded 191 embedded policies.
2024-05-16T21:41:33-07:00	DEBUG	[misconf] 41:33.650482000 kubernetes.scanner.rego          Loaded 194 policies from disk.
2024-05-16T21:41:33-07:00	DEBUG	[misconf] 41:33.650765000 kubernetes.scanner.rego          Overriding filesystem for data!
2024-05-16T21:41:33-07:00	DEBUG	[misconf] 41:33.850202000 kubernetes.scanner               Scanning 7 files...
2024-05-16T21:41:33-07:00	DEBUG	[misconf] 41:33.850227000 kubernetes.scanner.rego          Scanning 7 inputs...
2024-05-16T21:41:34-07:00	DEBUG	OS is not detected.
2024-05-16T21:41:34-07:00	INFO	Detected config files	num=1
2024-05-16T21:41:34-07:00	DEBUG	Scanned config file	path="eng-debug.yaml"
2024-05-16T21:41:34-07:00	DEBUG	Found an ignore file	path=".trivyignore"

eng-debug.yaml (kubernetes)

Tests: 24 (SUCCESSES: 23, FAILURES: 1, EXCEPTIONS: 0)
Failures: 1 (CRITICAL: 1)

CRITICAL: ClusterRole 'delete-controlled-resources' shouldn't have access to manage resource 'secrets'
═══════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════
Viewing secrets at the cluster-scope is akin to cluster-admin in most clusters as there are typically at least one service accounts (their token stored in a secret) bound to cluster-admin directly or a role/clusterrole that gives similar permissions.

See https://avd.aquasec.com/misconfig/ksv041
───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
 eng-debug.yaml:39-41
───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
  39 ┌   - apiGroups: [""]
  40 │     resources: ["secrets", "pods"]
  41 └     verbs: ["delete"]
───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────

Version

$ trivy --version
Version: 0.51.1
Vulnerability DB:
  Version: 2
  UpdatedAt: 2024-05-17 00:17:49.370123778 +0000 UTC
  NextUpdate: 2024-05-17 06:17:49.370123517 +0000 UTC
  DownloadedAt: 2024-05-17 04:36:45.529888 +0000 UTC
Check Bundle:
  Digest: sha256:6d0771effa53c6cf8130861fc3ac28f5515c35a028edb4bb1e67261b9218c80e
  DownloadedAt: 2024-05-17 04:40:19.924465 +0000 UTC

Checklist

• Read the documentation regarding wrong detection
• Ran Trivy with -f json that shows data sources and confirmed that the security advisory in data sources was correct

[simar7]

cc @chen-keinan

[chen-keinan]

@evankanderson can you please add your expected results

[evankanderson]

I would expect no warnings -- users do not have access to read secrets.

[evankanderson]

Note that the only permission granted is delete -- this requires that the user already knows the name of the secret. We're using ExternalSecrets to sync secrets into the cluster, so granting delete permission allows a user to force ExternalSecrets to re-sync the secret value from the external store.

I don't want to disable this warning altogether, but I'm having trouble how having only delete permission can lead to:

Viewing secrets at the cluster-scope ...

Since no view (get or list) access is granted.

[evankanderson]

(There might be an argument that could be constructed around granting only create access providing an escalation to cluster-admin, but delete seems of a different nature.)