From 84f5e99ec8ab62d4f4ad32c18db84b450e93c19d Mon Sep 17 00:00:00 2001 From: Steven Smith <77019920+stevsmit@users.noreply.github.com> Date: Tue, 10 Sep 2024 16:19:23 -0400 Subject: [PATCH] Adds RBAC content to security guide (#1096) Co-authored-by: Steven Smith --- modules/allow-access-user-repo.adoc | 3 +++ .../operator-custom-ssl-certs-config-bundle.adoc | 14 +++++++++----- modules/robot-account-overview.adoc | 3 +++ modules/role-based-access-control-intro.adoc | 14 +++++++------- tls-config/master.adoc | 14 +++++++++++++- use_quay/master.adoc | 1 - 6 files changed, 35 insertions(+), 14 deletions(-) diff --git a/modules/allow-access-user-repo.adoc b/modules/allow-access-user-repo.adoc index 7c38079eb..9b88be878 100644 --- a/modules/allow-access-user-repo.adoc +++ b/modules/allow-access-user-repo.adoc @@ -23,6 +23,9 @@ endif::[] ifeval::["{context}" == "use-quay"] {productname}. endif::[] +ifeval::["{context}" == "quay-security"] +{productname}. +endif::[] . On the v2 UI, click *Repositories*. diff --git a/modules/operator-custom-ssl-certs-config-bundle.adoc b/modules/operator-custom-ssl-certs-config-bundle.adoc index c9b3660e0..d21be4c40 100644 --- a/modules/operator-custom-ssl-certs-config-bundle.adoc +++ b/modules/operator-custom-ssl-certs-config-bundle.adoc @@ -2,16 +2,20 @@ [id="operator-custom-ssl-certs-config-bundle"] = Configuring custom SSL/TLS certificates for {productname-ocp} -You can configure custom SSL/TLS certificates before or after the initial deployment of {productname-ocp}. This process involves creating or updating the `configBundleSecret` resource within the `QuayRegistry` YAML file to integrate your custom certificates. +When {productname} is deployed on {ocp}, the `tls` component of the `QuayRegistry` custom resource definition (CRD) is set to `managed` by default. As a result, {ocp}'s Certificate Authority is used to create HTTPS endpoints and to rotate SSL/TLS certificates. -[NOTE] +You can configure custom SSL/TLS certificates before or after the initial deployment of {productname-ocp}. This process involves creating or updating the `configBundleSecret` resource within the `QuayRegistry` YAML file to integrate your custom certificates and setting the `tls` component to `unmanaged`. + +[IMPORTANT] ==== -If you are adding the certificates to an existing deployment, you must include the existing `config.yaml` file in the new config bundle secret, even if you are not making any configuration changes. +When configuring custom SSL/TLS certificates for {productname}, administrators are responsible for certificate rotation. ==== -The following procedures enable you to apply custom SSL/TLS certificates to ensure secure communication and meet specific security requirements for your {productname-ocp} deployment. These steps assumed you have already created a Certificate Authority (CA) file, an `ssl.key`, and an `ssl.cert`. The procedure then shows you how to integrate those files into your {productname-ocp} deployment, which ensures that your registry operates with the specified security settings and conforms to your organization's SSL/TLS policies. +The following procedures enable you to apply custom SSL/TLS certificates to ensure secure communication and meet specific security requirements for your {productname-ocp} deployment. These steps assumed you have already created a Certificate Authority (CA) bundle or an `ssl.key`, and an `ssl.cert`. The procedure then shows you how to integrate those files into your {productname-ocp} deployment, which ensures that your registry operates with the specified security settings and conforms to your organization's SSL/TLS policies. [NOTE] ==== -The following procedure is used for securing {productname} with an HTTPS certificate. Note that this differs from managing Certificate Authority Trust Bundles. CA Trust Bundles are used by system processes within the `Quay` container to verify certificates against trusted CAs, and ensure that services like LDAP, storage backend, and OIDC connections are trusted. +* The following procedure is used for securing {productname} with an HTTPS certificate. Note that this differs from managing Certificate Authority Trust Bundles. CA Trust Bundles are used by system processes within the `Quay` container to verify certificates against trusted CAs, and ensure that services like LDAP, storage backend, and OIDC connections are trusted. + +* If you are adding the certificates to an existing deployment, you must include the existing `config.yaml` file in the new config bundle secret, even if you are not making any configuration changes. ==== \ No newline at end of file diff --git a/modules/robot-account-overview.adoc b/modules/robot-account-overview.adoc index 897c4e6a4..1435427b0 100644 --- a/modules/robot-account-overview.adoc +++ b/modules/robot-account-overview.adoc @@ -16,6 +16,9 @@ endif::[] ifeval::["{context}" == "use-quay"] {productname} endif::[] +ifeval::["{context}" == "quay-security"] +{productname}. +endif::[] registry. They are similar to {ocp} service accounts. Setting up a Robot Account results in the following: diff --git a/modules/role-based-access-control-intro.adoc b/modules/role-based-access-control-intro.adoc index ae41696e2..73a888800 100644 --- a/modules/role-based-access-control-intro.adoc +++ b/modules/role-based-access-control-intro.adoc @@ -1,15 +1,15 @@ -[[role-based-access-control]] -= Role-based access control (RBAC) +[id="role-based-access-control"] += {productname} permissions model -{productname} offers three types of permissions: +{productname}'s permission model provides fine-grained access control over repositories and the content of those repositories, helping ensure secure collaboration and automation. {productname} administrators can grant users and robot accounts one of the following levels of access: -* `Read`, which allows users, robots, and teams to pull images. -* `Write`, which allows users, robots, and teams to push images. -* `Admin`, which provides users, robots, and teams with administrative privileges. +* *Read*: Allows users, robots, and teams to pull images. +* *Write*: Allows users, robots, and teams to push images. +* *Admin*: Provides users, robots, and teams administrative privileges. [NOTE] ==== Administrative users can delegate new permissions for existing users and teams, change existing permissions, and revoke permissions when necessary ==== -Permissions can be delegated across the entire organization and on specific repositories. For example, `Read` permissions can be set to a specific team within the organization, while `Admin` permissions can be given to all users across all repositories within the organization. +Collectively, these levels of access provide users or robot accounts the ability to perform specific tasks, like pulling images, pushing new versions of an image into the registry, or managing the settings of a repository. These permissions can be delegated across the entire organization and on specific repositories. For example, *Read* permissions can be set to a specific team within the organization, while *Admin* permissions can be given to all users across all repositories within the organization. diff --git a/tls-config/master.adoc b/tls-config/master.adoc index afa6cee89..f9905be4b 100644 --- a/tls-config/master.adoc +++ b/tls-config/master.adoc @@ -18,13 +18,24 @@ This guide provides guidance for enhancing the security of your {productname} de * Adding additional Certificate Authorities to {productname-ocp} * Clair vulnerability reporting +//rbac + +include::modules/role-based-access-control-intro.adoc[leveloffset=+1] +include::modules/teams-overview.adoc[leveloffset=+2] +include::modules/set-team-role.adoc[leveloffset=+3] +include::modules/managing-team-members-repo-permissions-ui.adoc[leveloffset=+3] +include::modules/setting-role-of-team-within-organization-api.adoc[leveloffset=+3] +include::modules/default-permissions-v2-ui.adoc[leveloffset=+2] +include::modules/default-permissions-api.adoc[leveloffset=+2] +include::modules/allow-access-user-repo.adoc[leveloffset=+2] +include::modules/adjust-access-user-repo-api.adoc[leveloffset=+2] + //private repo include::modules/proc_use-quay-create-repo.adoc[leveloffset=+1] include::modules/adjusting-repository-visibility-via-the-ui.adoc[leveloffset=+2] include::modules/adjusting-repository-access-via-the-api.adoc[leveloffset=+2] - //robot accounts include::modules/robot-account-overview.adoc[leveloffset=+1] include::modules/creating-robot-account-v2-ui.adoc[leveloffset=+2] @@ -62,3 +73,4 @@ include::modules/config-custom-ssl-certs-kubernetes.adoc[leveloffset=+2] //isolated builds +//clair diff --git a/use_quay/master.adoc b/use_quay/master.adoc index aaf1beabf..700955b93 100644 --- a/use_quay/master.adoc +++ b/use_quay/master.adoc @@ -66,7 +66,6 @@ include::modules/deleting-team-within-organization-api.adoc[leveloffset=+4] include::modules/default-permissions-v2-ui.adoc[leveloffset=+2] include::modules/default-permissions-api.adoc[leveloffset=+2] -//think this section needs work include::modules/allow-access-user-repo.adoc[leveloffset=+2] include::modules/adjust-access-user-repo-api.adoc[leveloffset=+2]