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

[maltemorgenstern]

Discussed in #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).

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.

- apiGroups:
  - ""
  resources:
  - secrets
  verbs:
  - create
  - get
  - update

Based on this discussion 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:

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?

trivy-operator/pkg/vulnerabilityreport/controller/workload.go

Lines 255 to 269 in 4b1c6c3

	if r.AccessGlobalSecretsAndServiceAccount && len(reusedReports) == 0 {
	privateRegistrySecrets, err := r.Config.GetPrivateRegistryScanSecretsNames()
	if err != nil {
	return err
	}
	pConfig, err := r.PluginContext.GetConfig()
	if err != nil {
	return err
	}
	multiSecretSupport := trivy.MultiSecretSupport(trivy.Config{PluginConfig: pConfig})
	credentials, err = r.CredentialsByServer(ctx, owner, privateRegistrySecrets, multiSecretSupport)
	if err != nil {
	return err
	}
	}

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:

trivy-operator/deploy/helm/templates/rbac/role.yaml

Lines 18 to 25 in 4b1c6c3

	- apiGroups:
	- ""
	resources:
	- secrets
	verbs:
	- create
	- get
	- delete

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]

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]

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

[maltemorgenstern]

The pull request is still open and awaiting a review.