From 6e6bd8573fa1e312bc8e5df8c0647f96aca2cbb1 Mon Sep 17 00:00:00 2001 From: Vincent Gramer Date: Tue, 28 Feb 2023 15:07:15 +0100 Subject: [PATCH] backport iam-role-based-access-control in v2.22 Signed-off-by: Vincent Gramer --- .../_index.en.md | 121 ++++++++++++++++++ .../groups-support/_index.en.md | 0 .../role-based-access-control/_index.en.md | 40 ------ .../add-seed-cluster-EE/_index.en.md | 2 +- .../upgrade-from-2.20-to-2.21/_index.en.md | 2 +- 5 files changed, 123 insertions(+), 42 deletions(-) create mode 100644 content/kubermatic/v2.22/architecture/iam-role-based-access-control/_index.en.md rename content/kubermatic/v2.22/architecture/{role-based-access-control => iam-role-based-access-control}/groups-support/_index.en.md (100%) delete mode 100644 content/kubermatic/v2.22/architecture/role-based-access-control/_index.en.md diff --git a/content/kubermatic/v2.22/architecture/iam-role-based-access-control/_index.en.md b/content/kubermatic/v2.22/architecture/iam-role-based-access-control/_index.en.md new file mode 100644 index 0000000000..fb690ac973 --- /dev/null +++ b/content/kubermatic/v2.22/architecture/iam-role-based-access-control/_index.en.md @@ -0,0 +1,121 @@ ++++ +title = "IAM and Role-Based Access Control" +date = 2020-04-02T12:07:15+02:00 +weight = 5 + ++++ + +KKP components use OpenID Connect (OIDC) protocol for authentication and RBAC for authorization. +By default, KKP provides [Dex](#authentication-with-dex) as OIDC provider, but you can configure your own provider. For more information, +please refer to the [OIDC provider]({{< ref "../../tutorials-howtos/OIDC-Provider-Configuration" >}}) chapter. + +## Authentication with Dex +[Dex](https://dexidp.io/) is an identity service that uses OIDC to drive authentication for KKP components. It acts as a +portal to other identity providers through [connectors](https://dexidp.io/docs/connectors/). This lets Dex defer +authentication to these connectors. Multiple connectors may be configured at the same time. Most popular are: +* [GitHub](https://dexidp.io/docs/connectors/github/) +* [Google](https://dexidp.io/docs/connectors/google/) +* [LDAP](https://dexidp.io/docs/connectors/ldap/) +* [Microsoft](https://dexidp.io/docs/connectors/microsoft/) +* [OAuth 2.0](https://dexidp.io/docs/connectors/oauth/) +* [OpenID Connect](https://dexidp.io/docs/connectors/oidc/) +* [SAML2.0](https://dexidp.io/docs/connectors/saml/) + +Check out the [Dex documentation](https://dexidp.io/docs/connectors/) for a list of available providers and how to setup their configuration. + +To configure Dex connectors, edit `.dex.connectors` in the `values.yaml` + +Example to update or set up Github connector: +``` +dex: + ingress: + [...] + connectors: + - type: github + id: github + name: GitHub + config: + clientID: + clientSecret: + redirectURI: https:///dex/callback + orgs: + - name: +``` + +And apply the changes to the cluster: + +```bash +helm --namespace oauth upgrade --install --wait --values /path/to/your/helm-values.yaml oauth charts/oauth/ +``` + +## Authorization +Authorization is managed at multiple levels to ensure users only have access to authorized resources. KKP uses its own +authorization system to control access to various resources within the platform, including projects and clusters. +Administrators and project owners define and manage these policies and provide specific access control rules for users +and groups. + + +The Kubernetes Role-Based Access Control (RBAC) system is also used to control access to user cluster level resources, +such as namespaces, pods, and services. Please refer to [Cluster Access]({{< ref "../../tutorials-howtos/cluster-access" >}}) +to configure RBAC. + +### Kubermatic Kubernetes Platform (KKP) Users +There are two kinds of users in KKP: **admin** and **non-admin** users. + +**Admin** users can manage settings that impact the whole Kubermatic installation and users. For example, they can set default +values for cluster creation, like the number of machine Deployment's replica or enforce some integrations, like +[Monitoring and logging stack]({{< ref "../monitoring-logging-alerting/user-cluster/" >}}) on user clusters. All these settings are explained in detail in the [Administration chapter]({{< ref "../../tutorials-howtos/administration " >}}). +Moreover, KKP admins have access to all projects. + +On the other hand, **non-admin** users only have access to the projects they are granted. The KKP role they are associated with +determines their access level. + +### KKP Roles + +A project is an entity that logically groups various resources. All resources in a project can be accessed by users that have the correct role associated with them. +Affiliation of a user to one of the roles gives them certain powers they are allowed to use within a project. + +There are three roles: owner, editor, and viewer. These roles are concentric; that is, the owner role includes the permissions +of the editor role, and the editor role includes the permissions of the viewer role. + +- **viewer**: read-only access to see project resources +- **editor**: can see the project content that the viewer can view and additionally can create, edit and delete clusters in the project +- **owner**: can do everything that the editor can do and additionally manage permissions for the project + +The following table summarizes the permissions + +| | Viewer | Editor | Owner | +|-----------------------------------|---------------------------------------------------------------------------------------------------------------------------------|---------------------------------------------------------------------------------------------------------------------------------|---------------------------------------------------------------------------------------------------------------------------------| +| cluster [^1] | RO | RW | RW | +| cluster nodes (machineDeployment) | RO | RW | RW | +| K8s Dashboard | permission relies on [Kubernetes cluster rbac]({{< ref "../../tutorials-howtos/cluster-access" >}}) | permission relies on [Kubernetes cluster rbac]({{< ref "../../tutorials-howtos/cluster-access" >}}) | permission relies on [Kubernetes cluster rbac]({{< ref "../../tutorials-howtos/cluster-access" >}}) | +| Web terminal | X | permission relies on [Kubernetes cluster rbac]({{< ref "../../tutorials-howtos/cluster-access" >}}) | permission relies on [Kubernetes cluster rbac]({{< ref "../../tutorials-howtos/cluster-access" >}}) | +| events | RO | RO | RO | +| RBAC (cluster) | X | RO | RO | +| addons | List | RW | RW | +| applications | List | RW | RW | +| system applications | List | RW | RW | +| OPA Default Constraints | List | List | List | +| OPA Constraints | RO | RW | RW | +| OPA Gatekeeper config | RO | RW | RW | +| MLA AlertManager config | RO | RW | RW | +| MLA ruleGroup | RO | RW | RW | +| MLA Grafana UI | [grafana organization viewer](https://grafana.com/docs/grafana/latest/administration/roles-and-permissions/#organization-roles) | [grafana organization editor](https://grafana.com/docs/grafana/latest/administration/roles-and-permissions/#organization-roles) | [grafana organization editor](https://grafana.com/docs/grafana/latest/administration/roles-and-permissions/#organization-roles) | +| MLA alertermanager UI | RW | RW | RW | +| SSH Keys | RO | RW | RW | +| project's members | X | X | RW | +| project's groups | X | X | RW | +| project's service account | X | X | RW | +| etcd automatic backup | RO | RW | RW | +| etcd snapshot | RO | RW | RW | +| etcd restore | RO | RW | RW | +| cluster Template | RO | RW | RW | + +[^1]: even owner can not change the settings enforced for the whole KKP installation. + +### KKP Service Accounts + +A service account is a special type of user account that belongs to the KKP project, instead of to an individual +end-user. A service account is considered as project's resource. Only the owner of a project can create and update a +service account. There is no need to create new groups for service accounts. It’s assigned to one of the already defined +groups: `editors` or `viewers`. diff --git a/content/kubermatic/v2.22/architecture/role-based-access-control/groups-support/_index.en.md b/content/kubermatic/v2.22/architecture/iam-role-based-access-control/groups-support/_index.en.md similarity index 100% rename from content/kubermatic/v2.22/architecture/role-based-access-control/groups-support/_index.en.md rename to content/kubermatic/v2.22/architecture/iam-role-based-access-control/groups-support/_index.en.md diff --git a/content/kubermatic/v2.22/architecture/role-based-access-control/_index.en.md b/content/kubermatic/v2.22/architecture/role-based-access-control/_index.en.md deleted file mode 100644 index 5a499b402a..0000000000 --- a/content/kubermatic/v2.22/architecture/role-based-access-control/_index.en.md +++ /dev/null @@ -1,40 +0,0 @@ -+++ -title = "Role-based Access Control" -date = 2020-04-02T12:07:15+02:00 -weight = 5 - -+++ - -This guide explains how to configure Role-Based Access Control for KKP. To configure Role-Based Access Control for -user cluster, please refer to [Cluster Access]({{< ref "../../tutorials-howtos/cluster-access" >}}) page. - -## Overview - -A project is an entity that logically groups various resources. All resources in a project can be accessed by users that have the correct role associated with them. -Affiliation of a user to one of the roles gives them certain powers they are allowed to use within a project. - -## Kubermatic Kubernetes Platform (KKP) Roles - -There are three roles: owner, editor, and viewer. These roles are concentric; that is, the owner role includes the permissions -of the editor role, and the editor role includes the permissions of the viewer role. - - - **viewer**: read-only access to see project resources - - - **editor**: can see the project content that the viewer can view and additionally can create, edit and delete clusters in the project - - - **owner**: can do everything that the editor can do and additionally manage permissions for the project - -The following table summarizes the permissions: - -| Name | Permissions | -|---------------------------------------------------|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| -| viewer | Permissions for read-only actions that do not affect the state, such as viewing.
Viewers are not allowed to interact with service accounts (user).
Viewers are not allowed to interact with members of a project (UserProjectBinding) | -| editor | All viewer permissions, plus permissions to create, edit & delete the cluster.
Editors are not allowed to delete a project. Editors are not allowed to interact with members of a project (UserProjectBinding).
Editors are not allowed to interact with service accounts (user) | -| owner (role can not be held by a service account) | All editor permissions and permissions for managing permissions for a project.
Only the owners of a project can create a service account (aka. users)
Only the owners of a project can manipulate members | - -## KKP Service Accounts - -A service account is a special type of user account that belongs to the KKP project, instead of to an individual -end-user. A service account is considered as project's resource. Only the owner of a project can create and update a -service account. There is no need to create new groups for service accounts. It’s assigned to one of the already defined -groups: `editors` or `viewers`. diff --git a/content/kubermatic/v2.22/installation/install-kkp-EE/add-seed-cluster-EE/_index.en.md b/content/kubermatic/v2.22/installation/install-kkp-EE/add-seed-cluster-EE/_index.en.md index 4c514d70d4..cd8a5a0b91 100644 --- a/content/kubermatic/v2.22/installation/install-kkp-EE/add-seed-cluster-EE/_index.en.md +++ b/content/kubermatic/v2.22/installation/install-kkp-EE/add-seed-cluster-EE/_index.en.md @@ -60,4 +60,4 @@ Once you have set up a seed in your KKP environment, check out some EE-only feat - Set up [Metering]({{< ref "../../../tutorials-howtos/metering/" >}}) to measure and report resource consumption across your KKP installation. - Configure [Resource Quotas]({{< ref "../../../architecture/concept/kkp-concepts/resource-quotas/" >}}) to limit resource consumption in KKP projects. -- Assign [roles to OIDC groups]({{< ref "../../../architecture/role-based-access-control/groups-support/" >}}) to manage authorization for large amount of users. +- Assign [roles to OIDC groups]({{< ref "../../../architecture/iam-role-based-access-control/groups-support/" >}}) to manage authorization for large amount of users. diff --git a/content/kubermatic/v2.22/installation/upgrading/upgrade-from-2.20-to-2.21/_index.en.md b/content/kubermatic/v2.22/installation/upgrading/upgrade-from-2.20-to-2.21/_index.en.md index c80b38a9f2..efaec10b8b 100644 --- a/content/kubermatic/v2.22/installation/upgrading/upgrade-from-2.20-to-2.21/_index.en.md +++ b/content/kubermatic/v2.22/installation/upgrading/upgrade-from-2.20-to-2.21/_index.en.md @@ -119,6 +119,6 @@ After finishing the upgrade, check out some of the new features that were added - [Operating System Manager]({{< ref "../../../tutorials-howtos/operating-system-manager/" >}}) (available as preview in KKP 2.20, but enabled by default in 2.21) - Support for Rocky Linux as new OS and VMware Cloud Director as new cloud provider - [Resource Quotas]({{< ref "../../../architecture/concept/kkp-concepts/resource-quotas/" >}}) (available in Enterprise Edition) -- [KKP role assignments for OIDC groups]({{< ref "../../../architecture/role-based-access-control/groups-support/" >}}) (available in Enterprise Edition) +- [KKP role assignments for OIDC groups]({{< ref "../../../architecture/iam-role-based-access-control/groups-support/" >}}) (available in Enterprise Edition) Check out the [changelog](https://github.com/kubermatic/kubermatic/blob/main/docs/changelogs/CHANGELOG-2.21.md) for a full list of changes.