Mirrors
/
flux2
mirror of https://github.com/fluxcd/flux2.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Incorporate Michael's suggestions

Browse Source 
Signed-off-by: Stefan Prodan <stefan.prodan@gmail.com>
pull/2086/head
Stefan Prodan 3 years ago
parent d23d87ac94
commit dc7cb189fc
No known key found for this signature in database
GPG Key ID: 3299AEB0E4085BAF
1 changed files with 19 additions and 15 deletions
Show Stats Download Patch File Download Diff File

34
rfcs/0001-multi-tenancy/README.md
Unescape Escape View File

@ -2,35 +2,39 @@
## Summary ## Summary
The main goal of this RFC is to define the Kubernetes tenancy models supported by Flux. This RFC defines two models for multi-tenancy using Flux and describes their reference implementations.
## Motivation ## Motivation
As of Flux v0.23.0, the documentation contains references to account impersonation, reconciliation isolation and other The documentation [here](https://fluxcd.io/docs/) describes the security model of Flux.
multi-tenancy related features without clearly defining which tenancy models are supported by Flux and how To this point, the Flux project has provided
they relate to source access control and Kubernetes role-based access control. [examples of multi-tenancy](https://github.com/fluxcd/flux2-multi-tenancy/tree/v0.1.0),
but not explained exactly how they relate to Flux's security model.
This RFC explains two multi-tenancy implementations, their security properties,
and how they map to the security model.
### Goals ### Goals
- Define multi-tenancy from a Flux user perspective. - Define two models for multi-tenancy, "soft multi-tenancy" and "hard multi-tenancy".
- List the types of users that interact with Flux in regard to multi-tenancy. - Explain when each model is appropriate.
- List the tenancy models supported by Flux. - List the tenancy models supported by Flux.
- Explain the differences between tenancy models. - Describe a reference implementation of each model with Flux.
### Non-Goals ### Non-Goals
- Explain in detail the Kubernetes architecture in regard to multi-tenancy. - Give an exhaustive account of multi-tenancy implementations.
- Provide an end-to-end workflow of how to setup multi-tenancy with Flux. - Provide an [end-to-end workflow](](https://github.com/fluxcd/flux2-multi-tenancy/tree/v0.1.0))
of how to setup multi-tenancy with Flux.
## Introduction ## Introduction
Flux allows different organizations and/or teams to share the same Kubernetes control plane to deliver applications Flux allows different organizations and/or teams to share the same Kubernetes control plane.
in a GitOps manner. Flux enables segmentation and isolation of resources across tenants by leveraging Flux enables segmentation and isolation of resources across tenants by using
Kubernetes Cluster API, namespaces and role-based access control. Kubernetes Cluster API, namespaces and role-based access control.
## User Roles ## User Roles
There are two types of users that interact with Flux: platform admins and tenants. The tenancy models assume two types of user: platform admins and tenants.
Besides installing Flux, all the other operations (deploy applications, configure ingress, policies, etc) Besides installing Flux, all the other operations (deploy applications, configure ingress, policies, etc)
do not require users to have direct access to the Kubernetes API. Flux acts as a proxy between users and do not require users to have direct access to the Kubernetes API. Flux acts as a proxy between users and
the Kubernetes API, using Git as source of truth for the cluster desired state. Changes to the clusters the Kubernetes API, using Git as source of truth for the cluster desired state. Changes to the clusters
@ -46,7 +50,7 @@ The repository(s) owned by the platform admins are reconciled on the cluster(s)
the [cluster-admin](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#user-facing-roles) the [cluster-admin](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#user-facing-roles)
Kubernetes cluster role. Kubernetes cluster role.
Example of operations performed by cluster admins: Example of operations performed by platform admins:
- Bootstrap Flux onto cluster(s). - Bootstrap Flux onto cluster(s).
- Extend the Kubernetes API with custom resource definitions and validation webhooks. - Extend the Kubernetes API with custom resource definitions and validation webhooks.
@ -108,7 +112,7 @@ for more details on how to harden shared clusters.
#### Tenants Onboarding #### Tenants Onboarding
When onboarding tenants, platform admins have the option to assign namespaces, set When onboarding tenants, platform admins have the option to assign namespaces, set
permissions and register the tenants main repositories onto clusters in a declarative manner. permissions and register the tenants main repositories onto clusters.
The Flux CLI offers an easy way of generating all the Kubernetes manifests needed to onboard tenants: The Flux CLI offers an easy way of generating all the Kubernetes manifests needed to onboard tenants:
@ -179,7 +183,7 @@ spec:
``` ```
Note that the [cluster-admin](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#user-facing-roles) Note that the [cluster-admin](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#user-facing-roles)
role is used in a `RoleBinding`, this only gives full control over every resource in the role binding's namespace. role is used in a `RoleBinding`; this only gives full control over every resource in the role binding's namespace.
Once the tenants main repositories are registered on the cluster(s), the tenants can configure their app delivery Once the tenants main repositories are registered on the cluster(s), the tenants can configure their app delivery
in Git using Kubernetes namespace-scoped resources such as `Deployments`, `Services`, Flagger `Canaries`, in Git using Kubernetes namespace-scoped resources such as `Deployments`, `Services`, Flagger `Canaries`,

Write Preview
Loading…
Cancel
Save