limit cluster wide access to secrets

[r0bj]

Giving to k8s-image-availability-exporter cluster wide access to all secrets is a little concern. As far as I understand it's to be able to use container registry credentials, right?
So it would be useful to have option, eg.:

1. Disable such a wide access to every secret in the cluster if we don't use any images from private registries.
   Currently if we want limit access to secrets by removing from RBAC:

  - apiGroups:
      - ""
    resources:
      - secrets
    verbs:
      - list
      - watch
      - get

it's causing k8s-image-availability-exporter fail to start with:

E0529 18:35:41.985749       1 reflector.go:123] pkg/mod/k8s.io/client-go@v0.0.0-20191016111102-bec269661e48/tools/cache/reflector.go:96: Failed to list *v1.Secret: secrets is forbidden: User "system:serviceaccount:kube-system:image-availability-exporter" cannot list resource "secrets" in API group "" at the cluster scope

2. Limit access to secrets for k8s-image-availability-exporter to only particular namespaces.

[zuzzas]

Hi. Sorry for the delay.

Yes, the concert is valid. I'll see if I can address it this week.

[zuzzas]

The current approach is extremely simple and efficient since it creates a global API Watch, and cross-references pullSecretReferences with the secrets directly in the memory of the image-availability-exporter.

[nabokihms]

There is a simple way to limit access to secrets that contain CRI credentials by using the ValidatingAdmissionPolicy. It will help us the reduce capabilities without refactoring the whole exporter.

[ikusomr]

Hi team,
do you have any plans regarding the issue eventually?

[nabokihms]

For now the issue is in the help wanted status, because the task is not in our nearest backlog. However, we appreciate any ideas and any help with the implementation.

[nabokihms]

One of my ideas was to pass the label selector for namespaces that the exporter can monitor. Then, filter namespaces by the selector and subscribe to secrets controllers and pods only in the limited scope of the cluster.

[ikusomr]

One of my ideas was to pass the label selector for namespaces that the exporter can monitor

Vote for this. We are currently thinking of using the service, but security concerns force us to either analyze any alternatives or develop extra controls, since:

• the service account has access to all secrets in the cluster, meaning anyone with proper RBAC permissions (e.g. impersonation to the service account) can gain these privileges which is critical for shared environments;
• the pod stores information about all cluster secrets in memory, meaning it’s critical to restrict any kind of ‘exec’ access to the pod; but since the image is built on top of distroless, it looks as a minor concern.

[nabokihms]

There is already a label to select namespaces, oh my. Thus, the only thing required is to refactor the informers to look into specific namespaces instead of requesting resources clusterwide. Then, clusterwide secret access will not be required anymore, it will be enough to create roles/rolebindings in desired namespaces (if needed).