flux2
flux2 copied to clipboard
fluxcd
[RFC] Access control for cross-namespace source refs
This RFC proposes a way to share sources between namespaces when running Flux on multi-tenant clusters.
Supersedes #582
@stefanprodan I'd like to say the problem that I see in the ACL proposal and the user story 3. As a tenant somehow I need to know each GitRepository name+namespace allowed to use by me. It's a bit implicit for me. However ACL can solve my problem, when I have a tenant wich 10+ namespaces. I would place a GitRepository with ACLs to one of the tenant namespace. E.g.: tenant-name-system.
On the other hand, the SourceReflection looks more explicitly, however, I don't know how to properly prevent creating SourceReflections resources by one tenant in another tenant namespace.
Another implicit behavior for me is an implicit reference from ImageUpdateAutomation to ImagePolicy.
I think the primary issue I see with ACLs is understanding what is available to you in terms of sources. As much as I like the idea of having some sort of CLI support for grabbing the available sources, I cannot think of a good way to show the available sources in a secure way to the tenant user
I think the primary issue I see with ACLs is understanding what is available to you in terms of sources. As much as I like the idea of having some sort of CLI support for grabbing the available sources, I cannot think of a good way to show the available sources in a secure way to the tenant user
ACLs are very much like network polices. As far as I know, there is no way for a tenant to query Kubernetes API and get a list of endpoints that allow ingress traffic from its namespace.
I think the primary issue I see with ACLs is understanding what is available to you in terms of sources. As much as I like the idea of having some sort of CLI support for grabbing the available sources, I cannot think of a good way to show the available sources in a secure way to the tenant user
A way to achieve this could be by a platform admin leveraging the built-in RBAC, having a pre-agreed namespace (say flux-shared) and provide list permissions to all sources that are available to a given tenant. Effectively allowing them to query them via kubectl. But it would be the platform admin's responsibility to ensure both RBAC and ACL permissions are in-sync.
Hello
Do you have plan to do the same thing between ImagePoliciy and ImageUpdateAutomation ressources ?
An example:
apiVersion: image.toolkit.fluxcd.io/v1beta1
kind: ImagePolicy
metadata:
name: podinfo
namespace: flux-system
spec:
imageRepositoryRef:
name: podinfo
policy:
semver:
range: 5.0.x
accessFrom:
namespaceSelectors:
- matchLabels:
kubernetes.io/metadata.name: flux-system
or maybe I misunderstood how the update automation controller works ^^
Do you have plan to do the same thing between ImagePoliciy and ImageUpdateAutomation ressources ?
Yes, this RFC is for the source-controller APIs, once we settle on a solution, I’ll create a new RFC for image automation.
I think the primary issue I see with ACLs is understanding what is available to you in terms of sources. As much as I like the idea of having some sort of CLI support for grabbing the available sources, I cannot think of a good way to show the available sources in a secure way to the tenant user
ACLs are very much like network polices. As far as I know, there is no way for a tenant to query Kubernetes API and get a list of endpoints that allow ingress traffic from its namespace.
@jonathan-innis @stefanprodan
Should we move forward with ACL's, implementing the ACL's via intermediary RoleBindings and relying on User Impersonation to enforce the policy will have the benefit of making the list of allowed Sources available via the kubectl/flux CLI as long as the CLI user also has access to impersonate the reconcile User.
This is another great reason to not build our own authorization mechanism. Since the policy is recorded and enforced by the kube-apiserver, all clients that request the resource can be constrained to the proper rules.
example:
kubectl auth can-i get gitrepository \
--all-namespaces --as system:serviceaccount:flux-system:reconciler
The apiserver is happy to tell you via RBAC whether or not a particular User can access resources, either generally or by name in whichever namespace.
@stealthybox we currently offer a way to disable cross-ns refs and enforce a default SA on multi-tenant environments https://fluxcd.io/docs/installation/#multi-tenancy-lockdown
We’ve reached out to TAG Security for guidance on ACLs. IMO ACLs made like network polices are way easier to setup than RBAC.
@stefanprodan I think that an important feature for this should be an additional CLI command to to make it clear which namespaces can access what resources. Generally the most difficult part of network policies is debugging. Other than that I think this looks good.
Closing this with the resolution: Adopt ReferenceGrant once SIG Auth API Group promotes the API to GA.
@stefanprodan, sorry to write in this closed PR, but, I'm understanding that until ReferenceGrant doesn't go GA by the SIG Auth API Group, FluxCD community won't do any movement in order to support cross-namespace support?
I'm asking because there is very little movement in the KEP, and seems this could go for long. I do not know if FluxCD community could provide at least some sort of feature to allow people to get the cross-namespace functionality (and its huge value) right now, with a big disclaimer that once it is supported by K8s core, it will be migrated to it.
From what I see, the API the SIG will implement seems pretty clear and in use in the gateway-api SIG, from where they want to export it from, so even Flux could already work knowing which will how the final implementation might look like.
Of course I understand that making work to have it deprecated soon(ish) has little value, but seeing how things are moving might make sense to invest the time, specially when there are some PRs around already with lots of dicussion or close to have the feature/value implemented.
