Allow viewers to read SealedSecrets #540
Conversation
| rbac.authorization.k8s.io/aggregate-to-edit: "true" | ||
| rbac.authorization.k8s.io/aggregate-to-admin: "true" |
There was a problem hiding this comment.
are these really necessary?
|
I'm a bit confused; I've worked in clusters where I had only read-only access and I remember I was able to see all resources in all the namespaces I had access. Does this PR adds the ability for people to see SealedResources of namespaces I wouldn't otherwise have access? |
|
This PR adds the ability to gain cluster-wide view access through the existing ClusterRole "view". There are several ways to provide view access. In a up-to-date cluster there are 3 special ClusterRoles which can be bound with a ClusterRolebinding:
Several projects use this pattern: |
|
Ok.thanks. can you please undo the version bump to the chart version? I'd like to add this also to the standalone yaml manifest (generated from the controller.jsonnet) and make a new release of both sealed-secrets and the helm chart combined |
Since SealedSecrets only contains encrypted data, we allow reading this kind of resource for users with view permissions. There's an existing "view" role (besides "edit" and "admin") in every cluster which gets updated with ClusterRoles containing special aggregate instructions via annotations: ~~~ rbac.authorization.k8s.io/aggregate-to-view: "true" rbac.authorization.k8s.io/aggregate-to-edit: "true" rbac.authorization.k8s.io/aggregate-to-admin: "true" ~~~ The view role in my use case is also used by event exporters (ie. the one provided by Opsgenie). All occurring events are received, enriched with the metadata of the relevant object and forwarded to an arbitrary monitoring/log system of choice. Without this role the event exporter cannot read the SealedSecrets object.
Done :) |
|
Hi @mkmik , |
|
@juan131 can you please take a look if this is still relevant? |
|
@mkilchhofer sorry but I just saw this.. Would you be willing to reopen this PR so we can reconsider it? |
juan131
added
backlog
Since SealedSecrets only contains encrypted data, we allow reading this kind of resource for
users with view permissions. There's an existing "view" role (besides "edit" and "admin") in every cluster
which gets updated with ClusterRoles containing special aggregate instructions via annotations:
The view role in my use case is also used by event exporters (ie. the one provided by Opsgenie). All occurring
events are received, enriched with the metadata of the relevant object and forwarded to an arbitrary
monitoring/log system of choice. Without this role the event exporter cannot read the SealedSecrets object.