Blocked containers
Prisma Cloud’s runtime defense system compares the state of a running container to the predictive model created for it during its learning period.
When abnormal activity is detected, such as executing an unknown process, Prisma Cloud can:
- Raise an alert by generating an audit. Audits are shown underMonitor > Events > Container Audits. If you have an alert channel configured, such as email or Slack, audits are forwarded there too. Alert is the default action.
- Block the container by stopping it altogether. To enable blocking, create a new runtime rule.
- Prevent just the discrete process or file system write (not the entire container). To enable prevent, create a new runtime rule.
Blocking action
Blocking stops potentially compromised containers from running in your environment.
Prisma Cloud blocks containers under the following conditions:
- A container violates its runtime model, and you’ve installed a runtime rule with the action set to block. For example, if an attacker infiltrates a container and tries to run a port scan using nc, then the container would be blocked if nc weren’t a known, whitelisted process.
- A newly started container violates a vulnerability or compliance rule, and those rules have the action set to block. Prisma Cloud scans all images before they run, to enforce policies about what’s allowed to execute in your environment. For example, you policy might call for blocking any container with critical severity vulnerabilities.
Runtime rules can be created under Defend > Runtime > Container Policy.
Vulnerability rules can be created under Defend > Vulnerabilities > Policy, and compliance rules can be created under Defend > Compliance > Policy.
Viewing blocked containers
Blocking immediately stops a container, taking it out of service.
Blocked containers are never restarted.
To see a list of blocked containers, go to the container audits page under
Monitor > Events > Container Audits
.
When a container is stopped, Prisma Cloud takes no further action to keep it stopped.
Orchestrators, such as Kubernetes and Docker Swarm, start a fresh container in the blocked container’s place.
Orchestrators have their own mechanism for maintaining a set point, so they ignore the restart policy defined in the image’s Dockerfile.
There is an exception when you run containers in a Docker-only environment (no orchestrator) and Prisma Cloud blocks a container.
In this case, Prisma Cloud must take additional action to keep the container blocked.
To prevent the container from automatically restarting, Prisma Cloud modifies the container’s restart policy to always unless stopped.
If you want to unblock a container, connect to the node with the blocked container, and manually modify the container’s Docker configuration.
Blocked container artifacts
Forensic investigators can inspect a blocked container’s artifacts to determine why it was stopped.
You can capture all of the container’s contents, including its file system data, with the docker export command.
Go to the node with the blocked container and run:
$docker export [container_id] > /path/filename.tar
