Feature: match allow on namespace annotations

[devthejo]

Describe the problem/challenge you have
We have multi-tenant clusters where isolation is done by rancher. The mechanism is simple, anyone is scoped in a rancher project, anyone can create new namespace and scope it in it's project scope by adding an annotation that is matching the project id. To summarize this annotation is the guarantee that this namespace will not be accessed by another tenant.
In our dev cluster, we have unpredictable new namespace that will be created for review environments and we want be able to use SecretImport in them, but the constraint in SecretExport based on the destination namespace is not sufficient to address our case.

Describe the solution you'd like
We would like be able to specify ToNamespaceAnnotations as following, instead of ToNamespace on SecretExport

kind: SecretExport
metadata:
  name: user-password
  namespace: user1
spec:
  toNamespaceAnnotations:
    projectId: my-project-id

This could also be

kind: SecretExport
metadata:
  name: user-password
  namespace: user1
spec:
  toNamespaceAnnotationKey: projectId
  toNamespaceAnnotationValue: my-project-id

Anything else you would like to add:
I can try to make a PR if this feature is welcome :-)

---

Vote on this request

This is an invitation to the community to vote on issues, to help us prioritize our backlog. Use the "smiley face" up to the right of this comment to vote.

👍 "I would like to see this addressed as soon as possible"
👎 "There are other more important things to focus on right now"

We are also happy to receive and review Pull Requests if you would like to work on this issue.

[neil-hickey]

hi @devthejo , thanks for submitting!

• Is this annotation specific to rancher or your use-case? What does the annotation look like?
• I'm not very familiar with rancher, is this "tenant via annotation" a standard part of rancher?

I'm not opposed to you making the PR, I just want to make sure that this feature would be useful for the project and not just for your particular use-case if it is specific to your environment.

[devthejo]

hi @neil-hickey, thanks for your reactivity!

• Is this annotation specific to rancher or your use-case? What does the annotation look like?
• I'm not very familiar with rancher, is this "tenant via annotation" a standard part of rancher?

This is the way rancher do, yes we can call this "tenant via annotation" and this feature could be useful for any user of rancher that want to use secretgen-controller.

This is how it's look like:

apiVersion: v1
kind: Namespace
metadata:
  annotations:
    field.cattle.io/projectId: "abcde:12345"
  name: my-namespace

[neil-hickey]

Ok great, thanks for that background info!

That seems like a genuine use-case for secretgen controller. It's purpose is to make secrets available (copy/move etc) across namespaces (as one main use-case) - in this case the annotation is providing that tenancy.

Let me know if you need any help with PRs :)

[devthejo]

here is the PR: #337
:-)

[vrabbi]

Just my 2 cents:
It i think would make more sense possibly to generalize this a bit with a standard k8s selector object using something similar to the matchLabels or matchExpression formats. This would allow for other models of tenancy that exist which use labels for example and not annotations.

The format im thinking could like like:

selectorMatchFields:
- key:
operator: <[In|NotIn|Exists|DoesNotExist]>
values: [ ]

This for example is used in cartographer supply chains and offers a lot of flexibility.

The key in the annotation case would be metadata.annotations[<rancher annotation] and the operator would be In and the value would be the tennant id.
This would allow matching on any field of a namespace or even multiple fields as it is an array.

While a bit more verbose, i think the extra flexibility may be worth it.

The code for this exists in cartographer and could im guessing be re used here without making it too difficult.

[devthejo]

OK @vrabbi, thanks for advice, I'll drop a new PR very soon.

[devthejo]

here is the new PR according to selectorMatchFields spec: #376 !

[gary-van-woerkens]

Can't wait for the release !!! 🤤