Limiting user access at a namespace level


I want to limit users’ access so they can only see or manipulate resources in a namespace that they have access to. Essentially, I want team members to have insight into the pipelines that are relevant to them but not see any for other products. The only way I was able to do this was by creating an account per application per cluster (hal config provider k8s account add appA-<env> --namespaces appA) and then use requiredGroupMembership to limit these users.

Is there a better way to do this, and are there any performance related concerns with adding hundreds of kubernetes accounts within Spinnaker?


Is this using the V1 or V2 Kubernetes provider? I think the V2 provider does not (yet) scale as well to large (100+) number of accounts because of its reliance on kubectl.

@ttomsu what are your thoughts on making namespace a protected resource in fiat?


We are using the V1 provider. V1 will utilize less resources than V2 in this situation?


V1 will utilize less resources than V2 in this situation?

Yes – the client library does a lot less work (at the expense of some functionality) than kubectl.


We’re becoming interested in the idea of protected namespaces as well. Our multitenancy plan in k8s would result in a relatively large number of namespaces (100s) and we anticipate Spinnaker won’t scale well with that many different accounts (which would be necessary for permission mapping).

Having namespaces be a protected resource seems like it would solve this problem - has there been any more thought into that direction? I tried looking around in Spinnaker issues for anything around it, but wasn’t able to find anything.

EDIT: Actually, having multiple namespaces in one account probably has the same scale problems with kubectl that having multiple accounts would have, now that I think about it (if kubectl caching calls happen per namespace)