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
Discussed in https://github.com/aquasecurity/trivy-operator/discussions/2053