Add dynamic service accounts in namespace matchLabel

[cnelson]

When a namespace is created with a given label, I'd like to provision a service account in that namespace, and create rolebindings for it in other static namespaces

For example,

I have a static namespace named foo that always exists. Now when I create a new namespace with the label access: foo I'd like to

• Automatically create a service account in the the newly created namespace
• Create a rolebinding in the foo namespace that references this dynamically created account.

Is this possible?

[sudermanjr]

Yep, that is possible. Please take a look at https://github.com/FairwindsOps/rbac-manager#dynamic-namespaces-and-labels

In this case your subject will be a service account, but that example should get you going.

[cnelson]

@sudermanjr I'm not quite getting how to make this work. I've got a config that looks like this:

rbacBindings:
  - name: foo
    subjects:
      - kind: ServiceAccount
        name: some-name
    roleBindings:
      - clusterRole: admin
         namespace: foo
         namespaceSelector:
           matchLabels:
             access: foo

which leads to two issues:

• I can't specify the namespace for the service account in question, because I don't know it (I want it to be in whatever namespace matches the namespace selector. Leaving it unset, causes this error in the logs: Error creating Service Account: an empty namespace may not be set during creation

• Assuming there is a way to create the service account in this manner, It doesn't appear that I can use namespace: foo to attempt to create a rolebinding in that namespace, while also using the namespace selector to do this based on labels. I end up with a rolebinding in the namespace matching the selector, not in in the foo namespace.

Does this make sense? I'm happy to provide more detail if needed

[sudermanjr]

Hmmm. This is interesting.

I am fairly certain that even if you specify the namespace on the serviceAccount (which you have to, you are correct), that it will create the first SA in that namespace, and then create additional ones in each namespace for matchLabels.

This may be a flaw in the logic for namespace selector. I will need to test that out.

[sudermanjr]

Oh, and to create the label-matched bindings and the single-namespace binding, you'll need to specify multiple bindings, like so:

rbacBindings:
  - name: foo
    subjects:
      - kind: ServiceAccount
        name: some-name
        namespace: foo
    roleBindings:
      - clusterRole: admin
         namespaceSelector:
           matchLabels:
             access: foo
      - clusterRole: admin
         namespace: foo

I'm going to test that config on a local cluster here in a bit

[sudermanjr]

apiVersion: rbacmanager.reactiveops.io/v1beta1
kind: RBACDefinition
metadata:
  name: testing
rbacBindings:
  - name: foo
    subjects:
      - kind: ServiceAccount
        name: test-service-account
        namespace: foo
    roleBindings:
      - clusterRole: admin
        namespaceSelector:
          matchLabels:
            access: foo
      - clusterRole: admin
        namespace: foo

└─ k get sa -n foo
NAME                   SECRETS   AGE
default                1         54s
test-service-account   1         6s

└─ kubectl get rolebinding -n foo
NAME                ROLE                AGE
testing-foo-admin   ClusterRole/admin   13s

└─ kubectl create ns foo2
namespace/foo2 created
└─ k label ns foo2 access=foo
namespace/foo2 labeled

└─ k get sa -n foo2
NAME      SECRETS   AGE
default   1         88s

└─ k get rolebinding -n foo2
NAME                ROLE                AGE
testing-foo-admin   ClusterRole/admin   84s

On inspecting that rolebinding in foo2:

  subjects:
  - kind: ServiceAccount
    name: test-service-account
    namespace: foo

Looks like I was entirely wrong initially. Sorry about the confusion.

[sudermanjr]

This might be a good feature request, but I would have to look at the code to make sure.

[cnelson]

If this use case is a feature you'd accept, I could submit a PR for it, provided we figure out how this should actually work first :)

[cnelson]

@sudermanjr checking in on this? Thoughts on if this is a use case you'd want to support in this tool?

[sudermanjr]

Sorry for dropping this.

I think it is something we would be willing to support. I need to ask my fellow maintainers. I posed the question internally.

[sudermanjr]

Talked to @lucasreed and I think this is something we would accept a PR, but it will be a non-trivial amount of effort. Because of that, we probably won't be able to dedicate a large amount of time to it.