Merge pull request #181 from hlxsites/migrate-pr-docker-access

Migrate the PR for deprecating Docker Access Control

docs/en/compute-edition/31/admin-guide/secrets/secrets-manager.adoc

@@ -13,11 +13,10 @@ Utilizing the orchestrator’s built-in secrets management capabilities when you
 It undermines the principal benefit of a secrets store, which is managing all sensitive data in a single location.
 
 
-=== Theory of operation
+=== Theory of Operation
 
 When a user or orchestrator starts a container, Defender injects the secrets you specify into the container.
-In order for secret injection to work, all Docker commands must be routed through Defender, so be sure to download your client certs and setup your environment variables under *Manage > Authentication > User Certificates*.
-
+In order for secret injection to work, all Docker commands must be routed through Defender. Refer to xref:inject-secrets.adoc[Inject Secrets into Containers].
 There are several moving parts in the solution:
 
 image::secrets_manager_791688.png[width=400]

docs/en/enterprise-edition/content-collections/runtime-security/authentication/active-directory.adoc

@@ -138,6 +138,5 @@ image::runtime-security/logout.png[width=200]
 
 . At Console's login page, enter the UPN and password of an existing Active Directory user.
 +
-If the log in is successful, you are directed to the view appropriate for the user's role.
-If you have the Access User role, you are directed to a single page, where you can download certs for xref:../access-control/rbac.adoc[Docker client role-based access control].
+If the login is successful, you are directed to the view appropriate for the user's role.
 

docs/en/enterprise-edition/content-collections/runtime-security/authentication/openldap.adoc

@@ -8,11 +8,6 @@ Integrating Prisma Cloud with OpenLDAP lets users access Prisma Cloud using thei
 With OpenLDAP integration, you can:
 
 * Re-use the identities and groups already set up in your OpenLDAP directory.
-* Extend your organization’s access control logic to the management of Docker containers.
-
-For example, you could specify that only members of the group Dev Ops Admins can start and stop containers in the production environment.
-For more information, see the article for setting up role-based access control for xref:../access-control/rbac.adoc[Docker Engine].
-
 
 [.task]
 === Integrating OpenLDAP
@@ -95,5 +90,4 @@ image::runtime-security/logout.png[width=200]
 
 . Log in to Console using the credentials of an existing OpenLDAP user.
 +
-If the log in is successful, you are directed to the view appropriate for the user's role.
-If you have the Access User role, you are directed to a single page, where you can download certs for xref:../access-control/rbac.adoc[Docker client role-based access control].
+If the login is successful, you are directed to the view appropriate for the user's role.

docs/en/enterprise-edition/content-collections/runtime-security/authentication/saml.adoc

@@ -128,11 +128,10 @@ Configure Prisma Cloud Console.
 
 
 [.task]
-=== Granting access by group
+=== Granting Access by Group
 
 Grant access to Prisma Cloud Console by group.
 Each group must be assigned a xref:../authentication/user-roles.adoc[role].
-You can optionally use these groups to define xref:../access-control/rbac.adoc[RBAC rules] for controlling who can run which Docker Engine commands in your environment.
 
 [.procedure]
 . Open Console.
@@ -158,11 +157,10 @@ Console does not verify if that the value entered matches a group name in the SA
 
 
 [.task]
-=== Granting access by user
+=== Granting Access by User
 
 Grant access to Prisma Cloud Console by user.
 Each user must be assigned a xref:../authentication/user-roles.adoc[role].
-You can optionally use these user to define xref:../access-control/rbac.adoc[RBAC rules] for controlling who can run which Docker Engine commands in your environment.
 
 [.procedure]
 . Open Console.

docs/en/enterprise-edition/content-collections/runtime-security/configure/certificates.adoc

@@ -18,18 +18,6 @@ NOTE: Customizing certificates is only allowed for Prisma Cloud Compute edition.
 |Your organization CA
 |Compute edition
 
-|xref:../access-control/rbac.adoc[Docker access control]
-|Client certificates
-
-To enforce Docker access control, client certs should be installed on any host where the docker client can be run.
-|Clients (users) access to remote Docker Engine instances
-|Customize your own certificates for your clients
-
-Explicit list of trusted certificates can be defined under *Manage > Authentication > System certificates > Client certificates > Explicit certificate trust list*
-|Console CA
-|Customize under *Manage > Authentication > System certificates > Client certificates > CA certificate*
-|Compute edition
-
 |Certificate-based authentication to Console
 |
 |Clients access the Console
@@ -186,64 +174,8 @@ NOTE: HTTP Public Key Pinning (HPKP) was a security feature that was used to tel
 This feature is no longer recommended.
 See https://developer.mozilla.org/en-US/docs/Web/HTTP/Public_Key_Pinning
 
-
-=== Docker role-based access control certificates
-
-These certificates settings are related to the xref:../access-control/rbac.adoc[Docker access control] feature. Using the Docker access control, you can validate that Docker commands only run from remote machines through Defender on port 9998. Any user running Docker commands on port 9998 must be authenticated and authorized. By default, the Console generates certificates for users to authenticate to Defender. Any command run against Defender must also be explicitly allowed.
-
-Prisma Cloud lets you use your own certificates for Docker access control.
-Customize the Docker access control certificates, by providing Prisma Cloud the CA that signs the client (user) certificates. You can also specify an explicit list for client-trusted certificates.
-
-*NOTES:*
-
-* External certification authority (CA) section will be visible only to an Admin role user.
-* All trusted certificate information will be retrieved from the certificate itself, so the user doesn't have to manually add info such as CN, issuer, etc.
-* Only the public portion of a user certificate should be added to the explicit trust list. Private keys are not required and should be excluded from this process.
-
-[.task]
-==== Setting up your custom certs
-
-To set up your custom certs:
-
-[.procedure]
-. Open Console, and go to *Manage > Authentication > System certificates*.
-
-. Open the *CA certificate* card.
-
-.. Under *CA certificate*, upload CA certificate to trust.
-+
-Once this configuration is enabled, users must copy their keys (both public and private) to the host they're using to run commands with docker or kubectl.
-Though the path can be referenced in each command, it's usually simpler to place them in the default directory that docker looks in for certificates (~/.docker).
-+
-Each user certificate used with Prisma Cloud must have the user's CN embedded in the Subject field of the certificate.
-You can validate these settings by running the following command against the certificate:
-
-  $ openssl x509 -in .docker/cert.pem -text | grep Subj
-  Subject: CN=username
-+
-Finally, Docker requires that the CA certificate used to sign the server certificate on the nodes Prisma Cloud is protecting must also be in the ~/.docker folder, in a file called ca.pem.
-Because the 'server' certificate used in this deployment model is still generated by Prisma Cloud, this means that on each host where you're running docker or kubectl commands, you must also add the CA certificate to this folder.
-
-. You can also choose to set *Explicit certificate trust list* to *ON* (this configuration is optional)
-+
-An explicit certificate trust list allows you to create a list of explicitly trusted custom certificates.
-A typical use case of this feature would be when you have multiple certificates issued to a given user, but only want specific ones to be available for use with Prisma Cloud.
-By adding an explicit trust list, you can control what certificates can be used, as Prisma Cloud compares any certificates presented to it against the allowed trusted certificates list.
-This way, a user using a certificate not in the explicitly allowed list will not be able to use the certificate with Prisma Cloud, even if it was issued by a trusted CA.
-Note that this feature is valid only when a custom CA is configured.
-When enabled, this feature allows users to add new certificates to a table by uploading public certificates in PEM format.
-
-. Click *Add certificate*, copy the PEM-formatted public certificate which was issued by the trusted CA, then click *Add*.
-+
-When a custom certificate is provided to Prisma Cloud, it first checks the certificate against this list.
-If the certificate is matched to an entry in the list, then the previously existing flow continues.
-If the certificate is not in the trusted list, then the authentication fails with an error 'Certificate not in certificate trust list configured in Prisma Cloud'.
-+
-image::runtime-security/client-cert-editing.png[width=800]
-
-
 [.task]
-=== Certificate-based authentication to Console
+=== Certificate-based Authentication to Console
 
 This feature allows the Console to verify the client's CA certificate when accessing the Console. Use certificates from an implicitly trusted CA for securing the TLS connection.
 To enable this feature, follow the steps below:

docs/en/enterprise-edition/content-collections/runtime-security/configure/customize-terminal-output.adoc

@@ -22,60 +22,7 @@ Enhanced terminal output is available for rules created under:
 
 * *Defend > Vulnerabilities > Policy*
 * *Defend > Compliance > Policy*
-* *Defend > Access* (Docker Engine and Kubernetes access control rules).
-
-
-[.task]
-=== Specifying a custom message
-
-This procedure shows you how to create an access control rule that blocks all users from running the `container_create` operation.
-You will configure the rule to emit the following custom message when an action is blocked:
-
- Contact [email protected] to get additional privileges
-
-Although this procedure is specific to access control rules, the process for configuring custom messages for vulnerability and compliance rules is the same.
-
-[.procedure]
-. Open Console.
-
-. Go to *Defend > Access > Docker*, then click *New Docker rule*.
-
-. In the new rule dialog, enter the following information:
-
-.. In *Rule name*, enter a name.
-
-.. Set *Effect* to *Deny*.
-
-.. In *Show*, uncheck *All* to deselect all actions.
-
-.. In *Actions*, check *container_create*.
-+
-image::runtime-security/customize-terminal-output-765462.png[width=550]
-
-.. Click on the *Advanced* tab.
-
-.. In *Custom message for blocked requests*, enter *Contact [email protected] to get additional privileges*.
-
-.. Click *Save*.
-
-. Test your setup by running a command that violates your access control rule.
-
-.. Install your client certs.
-+
-For more information, see
-xref:../access-control/rbac.adoc#configuring-docker-client-variables[Configure Docker client variables].
-
-.. Try to run a container on a host protected by Prisma Cloud:
-+
-[source,console]
-----
-$ docker --tlsverify -H  <HOST>:9998 run ubuntu:latest
-docker: Error response from daemon: [Prisma Cloud] The command container_create denied for user aqsa by rule Block create. Contact [email protected] to get additional privileges.
-See 'docker run --help'.
-----
-+
-Where `<HOST>` is the hostname or IP address for a host running Defender.
-
+* *Defend > Access* (Kubernetes access control rules).
 
 [.task]
 === Output itemized list of compliance issues

docs/en/enterprise-edition/content-collections/runtime-security/deployment-patterns/caps.adoc

@@ -33,9 +33,6 @@ For audits: if you must retain all audits, consider configuring Console to send
 |xref:../runtime-defense/image-analysis-sandbox.adoc[Image sandbox analysis reports]
 |5000 scan reports or 500 MB (whichever limit is reached first)
 
-|xref:../access-control/rbac.adoc[Access audits]
-|100K audits or 50 MB (whichever limit is reached first)
-
 |xref:../audit/kubernetes-auditing.adoc[Kubernetes audits]
 |100K audits or 50 MB (whichever limit is reached first)
 

docs/en/enterprise-edition/content-collections/runtime-security/install/deploy-defender/container/container.adoc

@@ -61,8 +61,6 @@ If you select Console's IP address, and Console's IP address changes, your Defen
 
 . Under *Advanced Settings*, you can enter the following additional network configurations.
 
-.. Select the xref:../../../access-control/rbac.adoc#_defender_listener_type[listener type]. The default setting is *None*.
-
 .. Set *Assign globally unique names to Hosts* to *ON* when you have multiple hosts that can have the same hostname.
 +
 [NOTE]

docs/en/enterprise-edition/content-collections/runtime-security/secrets/secrets-manager.adoc

@@ -17,8 +17,7 @@ It undermines the principal benefit of a secrets store, which is managing all se
 === Theory of operation
 
 When a user or orchestrator starts a container, Defender injects the secrets you specify into the container.
-In order for secret injection to work, all Docker commands must be routed through Defender, so be sure to
-xref:../access-control/rbac.adoc#authentication-and-identity[download your client certs and setup your environment variables].
+In order for secret injection to work, all Docker commands must be routed through Defender. Refer to xref:inject-secrets.adoc[Inject Secrets into Containers].
 
 There are several moving parts in the solution: