diff --git a/modules/administration-guide/examples/snip_che-configuring-cluster-roles-for-users.adoc b/modules/administration-guide/examples/snip_che-configuring-cluster-roles-for-users.adoc index fc4fa822c8..9106ef217c 100644 --- a/modules/administration-guide/examples/snip_che-configuring-cluster-roles-for-users.adoc +++ b/modules/administration-guide/examples/snip_che-configuring-cluster-roles-for-users.adoc @@ -1,7 +1,7 @@ [id="configuring-cluster-roles-for-users"] -= Configuring cluster roles for {prod-short} users += Grant additional permissions to users -You can grant {prod-short} users more cluster permissions by adding cluster roles to those users. +Grant your developers additional {kubernetes} permissions by adding cluster roles so they can access resources beyond the default workspace operations. .Prerequisites @@ -11,22 +11,22 @@ You can grant {prod-short} users more cluster permissions by adding cluster role . Define the user roles name: + -[source,subs="+quotes,+macros"] +[source,bash,subs="+quotes,+macros"] ---- $ USER_ROLES=____ <1> ---- <1> Unique resource name. -. Find out the namespace where the {prod-short} Operator is deployed: +. Determine the namespace where the {prod-short} Operator is deployed: + -[source,subs="+quotes,+macros,+attributes"] +[source,bash,subs="+quotes,+macros,+attributes"] ---- $ OPERATOR_NAMESPACE=$({orch-cli} get pods -l app.kubernetes.io/component={prod-operator} -o jsonpath={".items[0].metadata.namespace"} --all-namespaces) ---- . Create needed roles: + -[source,subs="+quotes,+macros"] +[source,bash,subs="+quotes,+macros"] ---- $ kubectl apply -f - < List of users allowed to access {prod}. <2> List of groups of users allowed to access {prod} (for {ocp} only). <3> List of users denied access to {prod}. -<4> List of groups of users denied to access {prod} (for {ocp} only). +<4> List of groups of users denied access to {prod} (for {ocp} only). + -. Wait for the rollout of the {prod-short} server components to be completed. +If a user is on both `allow` and `deny` lists, access is denied. If `allowUsers` and `allowGroups` are empty, all users are allowed except the ones on the `deny` lists. If `denyUsers` and `denyGroups` are empty, only the users from `allow` lists are allowed. If both `allow` and `deny` lists are empty, all users are allowed. -[NOTE] -==== +. Wait for the rollout of the {prod-short} server components to complete. -To allow a user to access {prod-short}, add them to the `allowUsers` list. Alternatively, choose a group the user is a member of and add the group to the `allowGroups` list. -To deny a user access to {prod-short}, add them to the `denyUsers` list. Alternatively, choose a group the user is a member of and add the group to the `denyGroups` list. -If the user is on both `allow` and `deny` lists, they are denied access to {prod-short}. +.Verification -If `allowUsers` and `allowGroups` are empty, all users are allowed to access {prod-short} except the ones on the `deny` lists. -If `denyUsers` and `denyGroups` are empty, only the users from `allow` lists are allowed to access {prod-short}. +* Log in to the {prod-short} dashboard as a user on the `allowUsers` list and verify access to the dashboard. +* Log in as a user on the `denyUsers` list and verify that {prod-short} returns a `403 Forbidden` response. -If both `allow` and `deny` lists are empty, all users are allowed to access {prod-short}. +.Additional resources -==== +* xref:configuring-cluster-roles-for-users.adoc[] +* xref:removing-user-data-in-compliance-with-the-gdpr.adoc[] diff --git a/modules/secure/pages/configuring-cluster-roles-for-users.adoc b/modules/secure/pages/configuring-cluster-roles-for-users.adoc index eae517f54f..f14b41b666 100644 --- a/modules/secure/pages/configuring-cluster-roles-for-users.adoc +++ b/modules/secure/pages/configuring-cluster-roles-for-users.adoc @@ -1,5 +1,5 @@ :_content-type: PROCEDURE -:description: Configuring cluster roles for {prod-short} users +:description: Grant additional permissions to users :keywords: administration-guide, user, roles, permissions :navtitle: Grant additional permissions to users :page-aliases: administration-guide:configuring-cluster-roles-for-users.adoc diff --git a/modules/secure/pages/managing-identities-and-authorizations.adoc b/modules/secure/pages/managing-identities-and-authorizations.adoc index 4e3c4f7e82..b3b50e7d77 100644 --- a/modules/secure/pages/managing-identities-and-authorizations.adoc +++ b/modules/secure/pages/managing-identities-and-authorizations.adoc @@ -1,5 +1,5 @@ :_content-type: ASSEMBLY -:description: Managing identities and authorizations +:description: Control who can access {prod-short} :keywords: administration-guide, managing-identities-and-authorizations :navtitle: Control who can access {prod-short} :page-aliases: administration-guide:managing-identities-and-authorizations.adoc, .:managing-identities-and-authorizations.adoc, authenticating-users.adoc, authorizing-users.adoc, configuring-authorization.adoc, configuring-openshift-oauth.adoc, configuring-minikube-github-authentication.adoc @@ -7,6 +7,4 @@ [id="managing-identities-and-authorizations"] = Control who can access {prod-short} -This section describes different aspects of managing identities and authorizations of {prod}. - -include::partial$snip_persona-admin.adoc[] +Control who can access {prod-short} by restricting it to authorized users and groups, managing permissions, and complying with data protection regulations such as GDPR. diff --git a/modules/secure/pages/removing-user-data-in-compliance-with-the-gdpr.adoc b/modules/secure/pages/removing-user-data-in-compliance-with-the-gdpr.adoc index dc301f49b2..f4ef59acb8 100644 --- a/modules/secure/pages/removing-user-data-in-compliance-with-the-gdpr.adoc +++ b/modules/secure/pages/removing-user-data-in-compliance-with-the-gdpr.adoc @@ -1,5 +1,5 @@ :_content-type: PROCEDURE -:description: Removing user data in compliance with the GDPR +:description: Remove user data for GDPR compliance :keywords: administration-guide, user-data, gdpr, remove-data :navtitle: Remove user data for GDPR compliance :page-aliases: administration-guide:removing-user-data-in-compliance-with-the-gdpr.adoc, .:removing-user-data.adoc, removing-user-data.adoc @@ -7,31 +7,45 @@ [id="removing-user-data-in-compliance-with-the-gdpr"] = Remove user data for GDPR compliance -You can remove a user’s data on {ocp} in compliance with the link:https://gdpr.eu/[General Data Protection Regulation (GDPR)] that enforces the right of individuals to have their personal data erased. The process for other {kubernetes} infrastructures might vary. Follow the user management best practices of the provider you are using for the {prod} installation. +Remove a user's data from {ocp} when a developer leaves your organization, to comply with the link:https://gdpr.eu/[General Data Protection Regulation (GDPR)]. The process for other {kubernetes} infrastructures might vary. Follow the user management best practices of the provider you are using for the {prod} installation. -include::partial$snip_persona-admin.adoc[] - -WARNING: Removing user data as follows is irreversible! All removed data is deleted and unrecoverable! +[WARNING] +==== +Removing user data as follows is irreversible. All removed data is deleted and unrecoverable. +==== .Prerequisites -* An active `oc` session with administrative permissions for the {ocp} cluster. See link:https://docs.openshift.com/container-platform/latest/cli_reference/openshift_cli/getting-started-cli.html[Getting started with the OpenShift CLI]. +* An active `{orch-cli}` session with administrative permissions for the {ocp} cluster. See link:https://docs.openshift.com/container-platform/{ocp4-ver}/cli_reference/openshift_cli/getting-started-cli.html[Getting started with the OpenShift CLI]. .Procedure -. List all the users in the OpenShift cluster using the following command: +. List all the users in the {orch-name} cluster: + -[source,shell,subs="+quotes,macros,attributes"] +[source,bash,subs="+quotes,+attributes"] ---- -$ oc get users +$ {orch-cli} get users ---- + . Delete the user entry: ++ +[IMPORTANT] +==== +If the user has any associated resources (such as projects, roles, or service accounts), you must delete those first before deleting the user. +==== ++ +[source,bash,subs="+quotes,+attributes"] +---- +$ {orch-cli} delete user ____ +---- -IMPORTANT: If the user has any associated resources (such as projects, roles, or service accounts), you need to delete those first before deleting the user. +.Verification -[source,shell,subs="+quotes,macros,attributes"] +* Verify the user no longer appears in the cluster: ++ +[source,bash,subs="+quotes,+attributes"] ---- -$ oc delete user +$ {orch-cli} get users ---- .Additional resources diff --git a/modules/secure/pages/security-best-practices.adoc b/modules/secure/pages/security-best-practices.adoc index 20fa72080c..aa23a34958 100644 --- a/modules/secure/pages/security-best-practices.adoc +++ b/modules/secure/pages/security-best-practices.adoc @@ -1,5 +1,5 @@ :_content-type: CONCEPT -:description: Security best practices +:description: Protect your deployment :keywords: security, best practices :navtitle: Protect your deployment //:page-aliases: @@ -7,14 +7,36 @@ [id="security-best-practices"] = Protect your deployment -Get an overview of key best security practices for {prod} that can help you -foster a more resilient development environment. - -include::partial$snip_persona-admin.adoc[] +Protect your {prod} deployment by applying these security practices to safeguard developer credentials, isolate workspaces, and reduce the cluster attack surface. {prod} runs on top of OpenShift, which provides the platform, and the foundation for the products functioning on top of it. OpenShift documentation is the entry point for security hardening. -.Project isolation in OpenShift +== What is secure by default + +{prod-short} applies these protections automatically when you install it. No configuration is required: + +* *Project isolation.* Each developer gets a dedicated `-devspaces` {namespace}. Users cannot access other users' resources. +* *Role-based access control (RBAC).* The Operator creates ClusterRoles that grant developers permissions only within their own {namespace}. +* *Authentication.* Only authenticated OpenShift users can access {prod-short}. The gateway enforces RBAC on every request. +* *Container security context.* Workspace pods run as non-root with dropped capabilities. The `container-build` SecurityContextConstraint adds only `SETGID` and `SETUID` for container builds. + +== What you must configure + +These security tasks require administrator action: + +* *OAuth for Git providers.* Without OAuth, developers must manually create personal access token secrets. Set up OAuth for your Git providers to give developers credential-free repository access. +* *Access restrictions.* By default, all authenticated OpenShift users can access {prod-short}. Use the `advancedAuthorization` CheCluster property to restrict access to specific users and groups. + +== What you can optionally harden + +These additional measures strengthen your security posture but are not required: + +* *Network policies.* Control ingress and egress traffic between workspace pods to limit the attack surface. +* *Resource quotas and limit ranges.* Prevent resource abuse by setting per-project consumption constraints. +* *Extension management.* Restrict IDE extensions to trusted sources, especially in air-gapped environments. +* *Self-signed certificates.* Import custom TLS certificates if your Git server or artifact repositories use internal certificate authorities. + +== Project isolation in OpenShift In OpenShift, project isolation is similar to {namespace} isolation in {kubernetes} but is achieved through the concept of projects. A project in OpenShift is a top-level organizational unit that provides isolation and collaboration between different applications, teams, or workloads within a cluster. @@ -26,26 +48,22 @@ devEnvironments: defaultNamespace: autoProvision: false ---- -include::administration-guide:example$snip_che-curated-access.adoc[] -.Role-based access control (RBAC) +With this setup, you achieve curated access to {prod-short}, where cluster administrators control provisioning for each user and can explicitly configure various settings including resource limits and quotas. Learn more about project provisioning in the xref:administration-guide:provisioning-namespaces-in-advance.adoc[]. + +== Role-based access control (RBAC) By default, the {prod-short} operator creates the following ClusterRoles: * `-cheworkspaces-clusterrole` * `-cheworkspaces-devworkspace-clusterrole` -[NOTE] -==== -The `` prefix corresponds to the project name where the {prod} CheCluster CR is located. -==== - -The first time a user accesses {prod}, the corresponding RoleBinding is created in the `-devspaces` project. +The `` prefix corresponds to the project name where the {prod} CheCluster CR is located. The first time a user accesses {prod}, the corresponding RoleBinding is created in the `-devspaces` project. -All resources and actions you can grant users permission to use in their {namespace} is listed below. +The following table lists the resources and actions that you can grant users permission to use in their {namespace}. -.Overview of resources and actions available in a user's {namespace}. -[cols="1,1"] +.Overview of resources and actions available in a user's {namespace} +[cols="1,1",options="header"] |=== |Resources |Actions @@ -98,16 +116,19 @@ All resources and actions you can grant users permission to use in their {namesp |"get", "create", "delete", "list", "update", "patch", "watch" |=== -include::administration-guide:example$snip_che-user-granted-permission.adoc[] +[IMPORTANT] +==== +Each user is granted permissions only to their namespace and cannot access other users' resources. Cluster administrators can add extra permissions to users. They should not remove permissions granted by default. +For more details about configuring cluster roles for {prod} users and role-based access control, see the Additional resources section. +==== -.Dev environment isolation +== Dev environment isolation -Isolation of the development environments is implemented using OpenShift projects. -Every developer has a project in which the following objects are created and managed: +Isolation of the development environments is implemented using OpenShift projects. Every developer has a project in which the following objects are created and managed: -* Cloud Development Environment (CDE) Pods, including the IDE server. -* Secrets containing developer credentials, such as a Git token, SSH keys, and a Kubernetes token. +* Cloud Development Environment (CDE) Pods, including the Integrated Development Environment (IDE) server. +* Secrets containing developer credentials, such as a Git token, SSH keys, and a {kubernetes} token. * ConfigMaps with developer-specific configuration, such as the Git name and email. * Volumes that persist data such as the source code, even when the CDE Pod is stopped. @@ -116,36 +137,24 @@ Every developer has a project in which the following objects are created and man Access to the resources in a namespace must be limited to the developer owning it. Granting read access to another developer is equivalent to sharing the developer credentials and should be avoided. ==== -.Enhanced authorization +== Enhanced authorization -The current trend is -to split an infrastructure into several "fit for purpose" clusters -instead of having a gigantic monolith OpenShift cluster. -However, administrators might still want to provide granular access, -and restrict the availability of certain functionalities to particular users. +The current trend is to split an infrastructure into several "fit for purpose" clusters instead of having a gigantic monolith OpenShift cluster. A "fit for purpose" cluster is specifically designed and configured to meet the requirements of a particular use case or workload. It is tailored to optimize performance and resource utilization based on the characteristics of the workloads it manages. -[NOTE] -==== -A "fit for purpose" OpenShift cluster refers to a cluster that is specifically designed -and configured to meet the requirements and goals of a particular use case or workload. -It is tailored to optimize performance, resource utilization, -and other factors based on the characteristics of the workloads it will be managing. -For {prod}, it is recommended to have this type of cluster provisioned. -==== +For {prod}, this type of cluster is recommended. However, administrators might still want to provide granular access and restrict the availability of certain functionalities to particular users. -For this purpose, -optional properties that you can use to set up granular access for different groups and users are available in the CheCluster Custom Resource: +For this purpose, optional properties that you can use to configure granular access for different groups and users are available in the CheCluster Custom Resource: * `allowUsers` * `allowGroups` * `denyUsers` * `denyGroups` -Below is an example of access configuration: +The following example shows an access configuration: -[source, code] +[source,yaml] ---- - networking: +networking: auth: advancedAuthorization: allowUsers: @@ -160,31 +169,19 @@ Below is an example of access configuration: - openshift-group-c ---- -[NOTE] -==== -Users in the `denyUsers` and `denyGroup` categories will not be able to use {prod} and will see a warning when trying to access the User Dashboard. -==== +Users in the `denyUsers` and `denyGroup` categories cannot use {prod} and see a warning when trying to access the User Dashboard. -.Authentication +== Authentication and access verification -Only authenticated OpenShift users can access {prod}. -The Gateway Pod uses a role-based access control (RBAC) subsystem -to determine whether a developer is authorized to access a Cloud Development Environment (CDE) or not. +Only authenticated OpenShift users can access {prod}. The Gateway Pod uses a role-based access control (RBAC) subsystem to determine whether a developer is authorized to access a Cloud Development Environment (CDE) or not. -The CDE Gateway container checks the developer's {kubernetes} roles. -If their roles allow access to the CDE Pod, the connection to the development environment is allowed. -By default, only the owner of the {namespace} has access to the CDE Pod. +The CDE Gateway container checks the developer's {kubernetes} roles. If their roles allow access to the CDE Pod, the connection to the development environment is allowed. By default, only the owner of the {namespace} has access to the CDE Pod. -[IMPORTANT] -==== -Access to the resources in a namespace must be limited to the developer owning it. Granting `read` access to another developer is equivalent to sharing the developer credentials and should be avoided. -==== - -.Security context and security context constraint +== Security context and security context constraint {prod} adds `SETGID` and `SETUID` capabilities to the specification of the CDE Pod container security context: -[source, code] +[source,json] ---- "spec": { "containers": [ @@ -204,80 +201,69 @@ Access to the resources in a namespace must be limited to the developer owning i This provides the ability for users to build container images from within a CDE. -By default, {prod} assigns a specific `SecurityContextConstraint` (SCC) to the users that allows them to start a Pod with such capabilities. This SCC grants more capabilities to the users compared to the default `restricted` SCC but less capability compared to the `anyuid` SCC. This default SCC is pre-created in the {prod-short} namespace and named `container-build`. +By default, {prod} assigns users a specific `SecurityContextConstraint` (SCC) that allows them to start a Pod with such capabilities. This SCC grants more capabilities to the users compared to the default `restricted` SCC but less capability compared to the `anyuid` SCC. This default SCC is pre-created in the {prod-short} namespace and named `container-build`. Setting the following property in the CheCluster Custom Resource prevents assigning extra capabilities and SCC to users: -[source, code] +[source,yaml] ---- spec: devEnvironments: disableContainerBuildCapabilities: true ---- -.Resource Quotas and Limit Ranges +== Resource Quotas and Limit Ranges -Resource Quotas and Limit Ranges are {kubernetes} features you can use to help prevent bad actors and resource abuse within a cluster. -Specifically, they allow you to set resource consumption constraints for pods and containers. -By combining Resource Quotas and Limit Ranges, -you can enforce project-specific policies to prevent bad actors from consuming excessive resources. +Resource Quotas and Limit Ranges are {kubernetes} features you can use to help prevent bad actors and resource abuse within a cluster. Specifically, they allow you to set resource consumption constraints for pods and containers. By combining Resource Quotas and Limit Ranges, you can enforce project-specific policies to prevent bad actors from consuming excessive resources. -These mechanisms contribute to better resource management, stability, and fairness within an OpenShift cluster. -More details about link:https://docs.openshift.com/container-platform/4.14/applications/quotas/quotas-setting-per-project.html[Resource quotas] and link:https://docs.openshift.com/container-platform/4.14/nodes/clusters/nodes-cluster-limit-ranges.html[Limit ranges] are available in the OpenShift documentation. +These mechanisms contribute to better resource management, stability, and fairness within an OpenShift cluster. More details about resource quotas and limit ranges are available in the OpenShift documentation. -.Network policies +== Network policies -Network policies provide an additional layer of security by controlling network traffic between -pods in a {kubernetes} cluster. By default, every pod can communicate with every other pod and service on the cluster, -see link:https://docs.redhat.com/en/documentation/openshift_container_platform/{ocp4-ver}/html/networking_overview/index#about-openshift-sdn[OpenShift networking overview]. +Network policies provide an additional layer of security by controlling network traffic between pods in a {kubernetes} cluster. By default, every pod can communicate with every other pod and service on the cluster. Implementing network policies allows you to: * Control ingress and egress traffic to and from workspace pods * Limit the attack surface by denying unauthorized network access -When configuring network policies for {prod}, -ensure that pods in the {prod-short} namespace can still communicate with pods in user namespaces, -as this is required for proper functionality. - -For detailed instructions on implementing network policies with {prod}, see xref:administration-guide:configuring-network-policies.adoc[]. +When configuring network policies for {prod}, ensure that pods in the {prod-short} namespace can still communicate with pods in user namespaces. This communication is required for proper functionality. -.Disconnected environment +== Disconnected environment -An air-gapped OpenShift disconnected cluster refers to an OpenShift cluster -isolated from the internet or any external network. -This isolation is often done for security reasons to protect sensitive or critical systems from potential cyber threats. -In an air-gapped environment, -the cluster cannot access external repositories or registries to download container images, updates, or dependencies. +An air-gapped OpenShift disconnected cluster refers to an OpenShift cluster isolated from the internet or any external network. This isolation is often done for security reasons to protect sensitive or critical systems from potential cyber threats. In an air-gapped environment, the cluster cannot access external repositories or registries to download container images, updates, or dependencies. {prod} is supported and can be installed in a restricted environment. -include::install:example$snip_che-installation-instructions.adoc[] -.Managing extensions +== Extension security -By default, {prod} -includes the embedded Open VSX registry -which contains a limited set of extensions for the Microsoft Visual Studio Code - -Open Source editor. -Alternatively, cluster administrators can specify a different plugin registry in the Custom Resource, for example -https://open-vsx.org that contains thousands of extensions. -They can also build a custom Open VSX registry. -include::administration-guide:example$snip_che-managing-extensions.adoc[] +By default, {prod} includes the embedded Open VSX registry which contains a limited set of extensions for the Microsoft Visual Studio Code - Open Source editor. Alternatively, cluster administrators can specify a different plugin registry in the Custom Resource, for example the open-vsx.org registry that contains thousands of extensions. They can also build a custom Open VSX registry. [IMPORTANT] ==== -Installing extra extensions increases potential risks. To minimize these risks, make sure to only install extensions from reliable sources and regularly update them. +Installing extra extensions increases potential risks. To minimize these risks, ensure that you only install extensions from reliable sources and regularly update them. ==== -.Secrets +== Credential and secret protection -Keep sensitive data stored as {kubernetes} secrets in the users’ -namespaces confidential (for example Personal Access Tokens (PAT), and SSH keys). +Keep sensitive data stored as {kubernetes} secrets in the users' namespaces confidential (for example Personal Access Tokens (PAT), and SSH keys). -.Git repositories +== Git repositories It is crucial to operate within Git repositories that you are familiar with and that you trust. Before incorporating new dependencies into the repository, verify that they are well-maintained and regularly release updates to address any identified security vulnerabilities in their code. +.Additional resources + +* xref:administration-guide:provisioning-namespaces-in-advance.adoc[] +* xref:configuring-cluster-roles-for-users.adoc[] +* link:https://docs.openshift.com/container-platform/{ocp4-ver}/authentication/using-rbac.html[OpenShift role-based access control] +* link:https://docs.openshift.com/container-platform/{ocp4-ver}/applications/quotas/quotas-setting-per-project.html[Resource quotas per project] +* link:https://docs.openshift.com/container-platform/{ocp4-ver}/nodes/clusters/nodes-cluster-limit-ranges.html[Limit ranges] +* link:https://docs.redhat.com/en/documentation/openshift_container_platform/{ocp4-ver}/html/networking_overview/index#about-openshift-sdn[OpenShift networking overview] +* xref:administration-guide:configuring-network-policies.adoc[] +* xref:install:proc_installing-che-in-a-restricted-environment.adoc[] +* xref:administration-guide:extensions-for-microsoft-visual-studio-code-open-source.adoc[] + diff --git a/modules/secure/partials/snip_persona-admin.adoc b/modules/secure/partials/snip_persona-admin.adoc deleted file mode 100644 index 9857252bbf..0000000000 --- a/modules/secure/partials/snip_persona-admin.adoc +++ /dev/null @@ -1 +0,0 @@ -This page is for platform administrators who install, configure, and manage {prod-short} on {orch-name} clusters. To learn more about common roles and example tasks referenced in {prod-short} documentation, see xref:discover:roles-and-tasks.adoc[].