Configure trivy-operator to use single ImagePullSecret from operator namespace without enabling global secret access

[maltemorgenstern]

Discussed in https://github.com/aquasecurity/trivy-operator/discussions/2053

^{Originally posted by **maltemorgenstern** May 4, 2024} Hey there, I have a question about private registries. We are running a private registry for all of our docker images (there are gatekeeper policies in place to enforce that only internal images can be deployed into the cluster). Therefore every deployment/namespace contains an `ImagePullSecret` with credentials to our registry. Using the default `trivy-operator` configuration this works like a charm - and reports for all resources are being created (because the operator is using the `ImagePullSecret` from each workload to pull the image, see [the docs](https://aquasecurity.github.io/trivy-operator/latest/docs/vulnerability-scanning/private-registries/)). The problem is that the default configuration comes with highly privileged permissions. Because `operator.accessGlobalSecretsAndServiceAccount` defaults to `true`, the deployed `ClusterRole` grants the operator access to all secrets in all namespaces - which is being criticised by our security team. ```yaml - apiGroups: - "" resources: - secrets verbs: - create - get - update ``` Based on [this discussion](https://github.com/aquasecurity/trivy-operator/discussions/1618) instead of using the `ImagePullSecret` in each namespace one can configure the operator to use a different secret from other namespaces. In our case we would just reference the secret from the operator namespace which contains credentials that are valid for all images in the cluster: ```yaml operator: # Do not allow access to everything (to increase security) accessGlobalSecretsAndServiceAccount: false # Instead configure operator to read ImagePullSecret from its own namespace privateRegistryScanSecretsNames: {"trivy-operator":"internal-pullsecret"} ``` But this does not work - and all scan jobs fail with `unauthorized` errors. Looking at the code the reason seems to be that `privateRegistryScanSecretsNames` requires `accessGlobalSecretsAndServiceAccount` to be enabled? https://github.com/aquasecurity/trivy-operator/blob/4b1c6c3aed3e115ad1e4b62c51c73dcfcfa20e92/pkg/vulnerabilityreport/controller/workload.go#L255-L269 And - in general - I can understand this requirement - because if you reference a workload namespace as the secret source that cluster-wide access is required to read the data. But if the namespace is the operator namespace this is not needed - because the default role already contains the required permissions to read kubernetes secrets: https://github.com/aquasecurity/trivy-operator/blob/4b1c6c3aed3e115ad1e4b62c51c73dcfcfa20e92/deploy/helm/templates/rbac/role.yaml#L18-L25 ### Question - Is there currently a way to provide access to private registries without granting the operator access to all secrets in the cluster? - If not: what do you think about the idea to add another option for providing the credentials - which would be referencing a local ImagePullSecret and therefor not needing global access? Kind Regard Malte

[github-actions[bot]]

This issue is stale because it has been labeled with inactivity.

[maltemorgenstern]

There is an open pull request for this feature waiting for review: #2161

[github-actions[bot]]

This issue is stale because it has been labeled with inactivity.