Role-based access control for Docker Engine
Prisma Cloud lets you control access to Docker commands based on group membership.
Prisma Cloud lets you:
- Secure access to remote Docker Engine instances.
- Control access to Docker commands on a user-by-user basis.
After integrating Prisma Cloud with Active Directory, OpenLDAP, or SAML, you could create a group called Dev Team.
Then in Console, you could grant all users in Dev Team permission to remotely run any Docker commands on hosts in the development environment, but deny permission to create, start, or stop containers on hosts in the production environment.
The groups specification is not applicable for Prisma Cloud Enterprise (SAAS) Console.
Securing remote access
The following diagram shows how Docker commands are routed from a user’s workstation over the network to a host protected by Defender:
The Docker client securely transmits the command over the network to Defender using the Transport Layer Security (TLS) protocol.
Defender acts as a proxy to the Docker daemon.
If the installed policy permits the command to be executed, it is forwarded to the Docker daemon over the UNIX socket.
The UNIX socket is created when the Docker daemon first starts, and it exposes a REST API through which Docker commands can be run.
Controlling access to resources
The following sequence diagram shows how users gain access to Docker resources, and how your access policies are enforced.
In this flow, it is assumed that:
- User Bruce has been added to the AD group Prisma Cloud Devs.
- You have already configured your access policy rules in the Prisma Cloud Console.
- Bruce logs into Console with his LDAP credentials. He’s directed to the single page user view.
- From the single page user view, he copies a command that installs certs on his machine. These certs identify him as Bruce. Group memberships for the user are embedded in the certificate.
- Bruce runs the install command on his machine. It copies the certs into the $HOME/.docker directory. He can now use TLS to communicate securely with hosts that run Defender.
- Bruce runs a Docker command on DevHostA (protected by Defender) from his local machine. He specifies the hostname for DevHostA and the port number where Defender listens. By default, Defender listens for TLS traffic on port 9998.
- Defender acts as a gateway to the Docker daemon. It uses the certificate to determine the user’s identity and group memberships. Defender allows or blocks the command, depending on the access policies specified in Console.
- In this case, Bruce has the right permissions to run this docker command. The command is forwarded to the docker daemon.
- The response from the Docker daemon is routed back to Bruce through Defender.
Note that Defender does not talk to the identity provider (IdP).
Instead, it relies on the user certificate generated from the initial authentication flow, when the user first tries to log into Console.
The validity period for the certificate is controlled by the IdP, which embeds the login expiration into its response.
Setting Defender’s listener type
To enforce role-based access control, Defender’s listener type must be set to TCP.