4 minute read
The Gardener API server supports a cluster-scoped
Project resource which is used for data isolation between individual Gardener consumers. For example, each development team has its own project to manage its own shoot clusters.
Project is backed by a Kubernetes
Namespace that contains the actual related Kubernetes resources like
apiVersion: core.gardener.cloud/v1beta1 kind: Project metadata: name: dev spec: namespace: garden-dev description: "This is my first project" purpose: "Experimenting with Gardener" owner: apiGroup: rbac.authorization.k8s.io kind: User name: email@example.com members: - apiGroup: rbac.authorization.k8s.io kind: User name: firstname.lastname@example.org role: admin # roles: # - viewer # - uam # - serviceaccountmanager # - extension:foo - apiGroup: rbac.authorization.k8s.io kind: User name: email@example.com role: viewer # tolerations: # defaults: # - key: <some-key> # whitelist: # - key: <some-key>
.spec.namespace field is optional and is initialized if unset.
The name of the resulting namespace will be determined based on the
Project name and UID, e.g.
It’s also possible to adopt existing namespaces by labeling them
project.gardener.cloud/name=dev beforehand (otherwise, they cannot be adopted).
When deleting a Project resource, the corresponding namespace is also deleted.
To keep a namespace after project deletion, an administrator/operator (not Project members!) can annotate the project-namespace with
.spec.purpose fields can be used to describe to fellow team members and Gardener operators what this project is used for.
Each project has one dedicated owner, configured in
.spec.owner using the
The owner is the main contact person for Gardener operators.
Please note that the
.spec.owner field is deprecated and will be removed in future API versions in favor of the
owner role, see below.
The list of members (again a list in
.spec.members using the
rbac.authorization.k8s.io/v1.Subject type) contains all the people that are associated with the project in any way.
Each project member must have at least one role (currently described in
.spec.members.role, additional roles can be added to
.spec.members.roles). The following roles exist:
admin: This allows to fully manage resources inside the project (e.g., secrets, shoots, configmaps, and similar).
serviceaccountmanager: This allows to fully manage service accounts inside the project namespace and request tokens for them. Please refer to this document.
uam: This allows to add/modify/remove human users or groups to/from the project member list. Technical users (service accounts) can be managed by all admins.
viewer: This allows to read all resources inside the project except secrets.
owner: This combines the
- Extension roles (prefixed with
extension:): Please refer to this document.
The project controller inside the Gardener Controller Manager is managing RBAC resources that grant the described privileges to the respective members.
There are three central
gardener.cloud:system:project-serviceaccountmanager that grant the permissions for namespaced resources (e.g.,
RoleBindings created in the respective namespace the project members get bound to these
ClusterRoles and, thus, the needed permissions.
There are also project-specific
ClusterRoles granting the permissions for cluster-scoped resources, e.g. the
For each role, the following
RoleBindings are created:
User Access Management
Projects created before Gardener v1.8 all admins were allowed to manage other members.
Beginning with v1.8 the new
uam role is being introduced.
It is backed by the
manage-members custom RBAC verb which allows to add/modify/remove human users or groups to/from the project member list.
Human users are subjects with
name!=system:serviceaccount:*, and groups are subjects with
The management of service account subjects (
name=system:serviceaccount:*) is not controlled via the
uam custom verb but with the standard
patch verbs for projects.
All newly created projects will only bind the owner to the
The owner can still grant the
uam role to other members if desired.
For projects created before Gardener v1.8 the Gardener Controller Manager will migrate all projects to also assign the
uam role to all
admin members (to not break existing use-cases). The corresponding migration logic is present in Gardener Controller Manager from v1.8 to v1.13.
The project owner can gradually remove these roles if desired.
When a project is not actively used for some period of time the project is marked as “stale”. This is done by controller called “Stale Projects Reconciler”. Once the project is marked as stale there is a time frame in which if not used it will be deleted by that controller. More detailed information can be found here.