-
Notifications
You must be signed in to change notification settings - Fork 567
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
This gives a baseline for future changes, e.g., expanding where
namespace ACLs are used, switching access control to
untrusted-by-default.
The "Security considerations" section was adapted from
#2086
Signed-off-by: Michael Bridgen <michael@weave.works>- Loading branch information
Showing
1 changed file
with
166 additions
and
0 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,166 @@ | ||
| # RFC-0001 Memorandum on Flux Authorization | ||
|
|
||
| ## Summary | ||
|
|
||
| This RFC describes in detail, for [Flux version 0.24][] (Nov 2021), how Flux determines which | ||
| operations are allowed to proceed, and how this interacts with Kubernetes' access control. | ||
|
|
||
| ## Motivation | ||
|
|
||
| To this point, the Flux project has provided [examples of how to make a multi-tenant | ||
| system](https://github.com/fluxcd/flux2-multi-tenancy/tree/v0.1.0), but not explained exactly how | ||
| they relate to Flux's authorization model; nor has the authorization model itself been | ||
| documented. Further work on support for multi-tenancy, among other things, requires a full account | ||
| of Flux's authorization model as a baseline. | ||
|
|
||
| ### Goals | ||
|
|
||
| - Give a comprehensive account of Flux's authorization model | ||
|
|
||
| ### Non-Goals | ||
|
|
||
| - Justify the model as it stands; this RFC simply records the state as at v0.24. | ||
|
|
||
| ## Flux's authorization model | ||
|
|
||
| The Flux controllers undertake operations as specified by custom resources of the kinds defined in | ||
| the [Flux API][]. Most of the operations are through the Kubernetes API. Authorization for | ||
| operations on external systems is not accounted for here. | ||
|
|
||
| Flux controllers defer to [Kubernetes' native RBAC][k8s-rbac] and [namespace isolation][k8s-ns] to | ||
| determine which operations are authorized, when processing the custom resources in the Flux API. | ||
|
|
||
| In general, **Kubernetes API operations are constrained by the service account under which each | ||
| controller pod runs**. In the [default deployment of Flux][flux-rbac] each controller has its own | ||
| service account; and, the service accounts for the Kustomize controller and Helm controller have the | ||
| [`cluster-admin` cluster role][k8s-cluster-admin] bound to it. | ||
|
|
||
| Both the Kustomize controller and the Helm controller create, update and delete arbitrary sets of | ||
| configuration that they take as user input. For example, a Kustomization object that references a | ||
| GitRepository is processed by taking whatever is in the specified Git repository and applying it to | ||
| the cluster. This is informally called "syncing", and these user-supplied configurations will be | ||
| called "sync configurations" in the following. | ||
|
|
||
| There are five types of access that have a distinct treatment with respect to RBAC and namespace | ||
| isolation: | ||
|
|
||
| - reading and writing the Flux API object to be processed | ||
| - accessing dependencies of a Flux API object; for example, a secret that holds a decryption key | ||
| - accessing Flux API objects related to the object being processed; for example, a GitRepository | ||
| referenced by a Kustomization | ||
| - creating, updating and deleting Flux API objects as part of processing; for example, each | ||
| `HelmRelease` object contains a template for a Helm chart spec, which the Helm controller uses to | ||
| create a `HelmChart` object | ||
| - creating, updating, deleting, and health-checking of arbitrary objects as specified by _sync | ||
| configurations_ (as mentioned above). | ||
|
|
||
| This table summarises how these operations are subject to RBAC and namespace isolation. | ||
|
|
||
| | Type of operation | Accessed via | Namespace isolation | | ||
| |------------------------------------------------|----------------------------|------------------------------| | ||
| | Reading and writing the object to be processed | Controller service account | N/A | | ||
| | Dependencies of object to be processed | Controller service account | Same namespace only | | ||
| | Access to related Flux API objects | Controller service account | Some cross-namespace refs[1] | | ||
| | CRUD of Flux API objects | Controller service account | Created in same namespace | | ||
| | CRUD and healthcheck of sync configurations | Impersonation[2] | As directed by spec[2] | | ||
|
|
||
| [1] See "Cross-namespace references" below<br> | ||
| [2] See "Impersonation" below | ||
|
|
||
| There are two related mechanisms that affect the service account used for the operations marked with | ||
| "Impersonation" above: "impersonation" and "remote apply". These are explained in the following | ||
| sections. | ||
|
|
||
| ### Impersonation | ||
|
|
||
| The Kustomize controller and Helm controller both apply arbitrary sets of Kubernetes configuration | ||
| ("_synced configuration_" as above) to a cluster. These controllers use the service account named in | ||
| the field `.spec.serviceAccountName` in the `Kustomization` and `HelmRelease` objects respectively, | ||
| while applying and health-checking the synced configuration. This mechanism is called | ||
| "impersonation". | ||
|
|
||
| The `.spec.serviceAccountName` field is optional. If empty, the controller's service account is | ||
| used. | ||
|
|
||
| ### Remote apply | ||
|
|
||
| The Kustomize controller and Helm controller are able to apply a set of configuration to a cluster | ||
| other than the cluster in which they run. If the `Kustomization` or `HelmRelease` object [refers to | ||
| a secret containing a "kubeconfig" file][kubeconfig], the controller will construct a client using | ||
| that kubeconfig, and the client is used to apply the prepared set of configuration. The effect of | ||
| this is that the configuration will be applied as the user given in the kubeconfig; often this is a | ||
| user with the `cluster-admin` role bound to it, but not necessarily so. | ||
|
|
||
| All accesses that would use impersonation use the remote client instead. | ||
|
|
||
| ### Cross-namespace references | ||
|
|
||
| Some Flux API kinds have fields which can refer to a Flux API object in another namespace. The Flux | ||
| controllers do not respect namespace isolation when dereferencing these fields. The following are | ||
| fields that are not restricted to the namespace of the containing object, listed by API kind. | ||
|
|
||
| | API kind | field | explanation | | ||
| |----------|-------|-------------| | ||
| | **`kustomizations.kustomize.toolkit.fluxcd.io/v1beta2`** | `.spec.dependsOn` | Items are references that can include a namespace | | ||
| | | `.spec.healthChecks` | Items are references that can include a namespace (note: these are accessed using impersonation) | | ||
| | | `.spec.sourceRef` | This is a reference that can include a namespace | | ||
| | | `.spec.targetNamespace` | This sets or overrides the namespace given in the top-most `kustomization.yaml` | | ||
| | **`helmreleases.helm.toolkit.fluxcd/v2beta1`** | `.spec.dependsOn` | Items are references that can include a namespace | | ||
| | | `.spec.targetNamespace` | This gives the namespace into which a Helm chart is installed (note: using impersonation) | | ||
| | | `.spec.storageNamespace` | This gives the namespace in which the record of a Helm install is created (note: using impersonation) | | ||
| | | `.spec.chart.spec.sourceRef` | This is a reference (in the created `HelmChart` object) that can include a namespace | | ||
| | **`alerts.notification.toolkit.fluxcd.io/v1beta1`** | `.spec.eventSources` | Items are references that can include a namespace | | ||
| | **`receivers.notification.toolkit.fluxcd.io/v1beta1`** | `.spec.resources` | Items in this field are references that can include a namespace | | ||
| | **`imagepolicies.image.toolkit.fluxcd.io/v1beta1`** | `.spec.imageRepositoryRef` | This reference can include a namespace[1] | | ||
|
|
||
| [1] This particular cross-namespace reference is subject to additional access control; see "Access | ||
| control for cross-namespace references" below. | ||
|
|
||
| Note that the field `.spec.sourceRef` of **`imageupdateautomation.image.toolkit.fluxcd.io`** does | ||
| _not_ include a namespace. | ||
|
|
||
| #### Access control for cross-namespace references | ||
|
|
||
| In v0.24, an `ImagePolicy` object can refer to a `ImageRepository` object in another | ||
| namespace. Unlike most cross-namespace references, the controller processing `ImagePolicy` objects | ||
| applies additional access control, as given in the referenced `ImageRepository`: the field | ||
| [`.spec.accessFrom`][access-from-ref] grants access to the namespaces selected therein. Access is | ||
| denied unless granted. | ||
|
|
||
| ## Security considerations | ||
|
|
||
| ### Impersonation is optional | ||
|
|
||
| Flux does not insist on a service account to be supplied in `Kustomization` and `HelmRelease` | ||
| specifications, and the default is to use the controller's service account. That means a user with | ||
| the ability to create either of those objects can trivially arrange for a configuration to be | ||
| applied with the controller service account, which in the default deployment of Flux will have | ||
| `cluster-admin` bound to it. This represents a privilege escalation vulnerability in the default | ||
| deployment of Flux. To guard against it, an admission controller can be used to make the | ||
| `.spec.serviceAccountName` field mandatory; an example which uses Kyverno is given in [the | ||
| multi-tenancy implementation][multi-tenancy-eg]. | ||
|
|
||
| ### Cross-namespace references side-step namespace isolation | ||
|
|
||
| `HelmRelease` and `Kustomization` objects can refer to `GitRepository`, `HelmRepository`, or | ||
| `Bucket` (collectively "sources") in any other namespace. The referenced objects are accessed | ||
| through the controller's service account, which by default has `cluster-admin` bound to it. This | ||
| means all sources in a cluster are by default usable as a synced configuration, from any | ||
| namespace. To restrict access, an admission controller can be used to block cross-namespace | ||
| references; the [example using Kyverno][multi-tenancy-eg] from above also does this. | ||
|
|
||
| ## References | ||
|
|
||
| - [CVE-2021-41254](https://github.com/fluxcd/kustomize-controller/security/advisories/GHSA-35rf-v2jv-gfg7) | ||
| "Privilege escalation to cluster admin on multi-tenant environments" was fixed in flux2 **v0.15.0**. | ||
|
|
||
| [Flux version 0.24]: https://github.com/fluxcd/flux2/releases/tag/v0.24.0 | ||
| [serviceAccountName]: https://fluxcd.io/docs/components/kustomize/api/#kustomize.toolkit.fluxcd.io/v1beta2.KustomizationSpec | ||
| [kubeconfig]: https://fluxcd.io/docs/components/kustomize/api/#kustomize.toolkit.fluxcd.io/v1beta2.KubeConfig | ||
| [access-from-ref]: https://fluxcd.io/docs/components/image/imagerepositories/#allow-cross-namespace-references | ||
| [Flux API]: https://fluxcd.io/docs/components/ | ||
| [flux-rbac]: https://github.com/fluxcd/flux2/tree/v0.24.0/manifests/rbac | ||
| [k8s-ns]: https://kubernetes.io/docs/concepts/overview/working-with-objects/namespaces/ | ||
| [k8s-rbac]: https://kubernetes.io/docs/reference/access-authn-authz/rbac/ | ||
| [k8s-cluster-admin]: https://kubernetes.io/docs/reference/access-authn-authz/rbac/#user-facing-roles | ||
| [multi-tenancy-eg]: https://github.com/fluxcd/flux2-multi-tenancy/blob/main/infrastructure/kyverno-policies/flux-multi-tenancy.yaml |