Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

limit cluster wide access to secrets #7

Open
r0bj opened this issue May 29, 2020 · 8 comments
Open

limit cluster wide access to secrets #7

r0bj opened this issue May 29, 2020 · 8 comments
Labels
help wanted Extra attention is needed

Comments

@r0bj
Copy link

r0bj commented May 29, 2020

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/[email protected]/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
  1. Limit access to secrets for k8s-image-availability-exporter to only particular namespaces.
@zuzzas
Copy link
Contributor

zuzzas commented Jun 29, 2020

Hi. Sorry for the delay.

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

@zuzzas
Copy link
Contributor

zuzzas commented Jun 29, 2020

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
Copy link
Member

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.

@nabokihms nabokihms added the help wanted Extra attention is needed label Jan 4, 2024
@ikusomr
Copy link

ikusomr commented Jan 15, 2024

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

@nabokihms
Copy link
Member

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
Copy link
Member

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
Copy link

ikusomr commented Jan 16, 2024

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
Copy link
Member

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).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
help wanted Extra attention is needed
Projects
None yet
Development

No branches or pull requests

4 participants