Adds RBAC content to security guide (#1096)

Co-authored-by: Steven Smith <stevsmit@stevsmit-thinkpadt14gen4.remote.csb>

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*. 
 

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.
 ====

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:

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.  

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

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]