Does Secret provider Job only reads & updates secrets under the same namespace where the job is executing or there is a way to force it to process secrets from other namespaces ?
@nathan.whipple @AndrewCopeland @joe.garcia @CaptainFluffyToes
No, the namespace is a hard requirement check for the authenticator. There’s no way to pull secrets from a different namespace than where the authenticator is currently running. That would pose a serious Segregation of Duties concern from a security perspective if it could.
Hey Abhishek,
Is there a management concern with having a 1 to 1 relationship between secrets provider and a specific namespace?
@joe.garcia @CaptainFluffyToes . Thanks alot for the inputs.
I’ll explain the use-case.
Basically we have K8s cluster running and we are based on Rancher for multi-tenancy. As you know rancher has a concept called “Projects” which lets Customer teams (tenants) have multiple namespaces for their services.
So basically because X team has a Project in Rancher which can contain 10 or 100 namespaces, we are trying to avoid creating the k8s secrets provider job on all the 100 namespaces because they belong to only 1 Customer team/Tenant. Thus, we are trying to find a way to have that 1 job for that tenant pull/update secrets from 100 namespaces which belong to them in that cluster instead of creating job per namespace.
Hi Abhishek,
IMO the tenants should be demanding segmentation between namespaces for secrets delivery. This is how they would get sufficient secrets access granularity and would align with common practices for security boundaries between applications.
Regards,
Nate