By Shashank Chandramohan, Sr Customer Success Engineer
In the Code Build Deploy & Run (CBDR) framework, securing the Deploy Lifecycle can help you prevent privileged containers, poisoned pipelines, compliance violations, and exposed branches before deploying your workloads.
This blog discusses how you can utilize Prisma Cloud’s Compute Workload Protection functionality to secure resources within your Deploy Lifecycle after the initial setup. You can leverage knowledge in the next steps after installing Defenders, creating policies and rules.
First, we will explore the radar section and discuss the environment before moving on to the best practices and recommendations for Defenders.
Navigate to Radars > Cloud.
This gives you a holistic view of where and what type of cloud accounts you have (Cloud Discovery must be enabled at the time of onboarding). This is a general overview of the number of resources you have in the cloud platform and how many resources have defense coverage along with the number of resources and the types of resources that are not defended.
The sidebar also contains the vulnerabilities for impacted resources and compliance information. Now you have a complete picture of your environment and its state.
Once you have installed Defenders and have a fair idea about your environment with the help of Radar view you can start managing Defenders under Manage > Defenders. Here you can gain visibility on all the Defenders installed and their statuses. Make sure the Defender status is “connected”. Insights are also provided into how long defenders have been connected or disconnected.
You can filter down specific Defenders using the filter feature. Some common use cases are to see which Defenders use old certificates or to list out all Defenders that need to be upgraded. This would help you filter the defenders that only need upgrades.
The best practice is to upgrade the Defenders to the latest version as Prisma cloud supports up to n-2 versions where “n” is the latest version and “-2” is the previous two versions.
Prisma Cloud can scan container images in public and private repositories on public and private registries. When configuring Prisma Cloud to scan a registry, you can select the scope of Defenders used for performing the scan job.
Registry Scan Behavior
Prisma Console controls the registry scan with assigned Defenders. The Console scans one registry at a time. If multiple registries are configured to scan, the Prisma Cloud console will scan one registry until complete before moving on to the following registry. This registry scanning behavior is not configurable.
Compute Vulnerability Policy
Having clear visibility into which vulnerabilities to focus on is crucial to identify four items:
1) The criticality of the alarm
2) The owners of an image resource
3) The actual image resource that is triggering the vulnerability alarm and
4) If there is a fix for the vulnerability.
Without measurability, vulnerability is impossible to manage correctly. In addition, scanning images in the CI/CD pipeline is crucial in preventing further vulnerabilities from polluting the environment. It is a good practice to solve vulnerabilities based on the severity level. First solving the most critical vulnerabilities followed by high, medium and low. The results can also show if the same package is triggering alarms across multiple images. Therefore updating one package across multiple images could reduce the vulnerabilities significantly.
It is vital to know who the owners are for cloud resources. Many customers have no visibility into these resources because they do not have an enforcement of tags in their environment. If ownership is not clear, it will become challenging to efficiently manage the environment. Also, tags can be utilized to define scopes in Prisma Cloud in order to block vulnerabilities from polluting the environment.
It is also crucial to have an alerting-to-blocking strategy– review which images and packages are triggering alarms. If the alarms are not being addressed, those issues can be determined if the blocking for that image is a go or no-go for specific business issues.
When defining scopes, having one for alerting only and one for blocking only is important. When converting images to blocking mode causes an outage, you can easily move the image back to the scope of alerting and triage the situation later. Once the image has been moved to blocking mode, the CI pipeline scanning is critical in keeping the environment unpolluted.
The Center for Internet Security (CIS) publishes recommendations for best practices that should be adhered to when setting up machine images, servers, and containers. For convenience, you can access this information within the compliance tab.
- Compliance Explorer: shows all non-compliance critical and high alerts
- Clicking on compliance check will show resources that are not compliant
- Container level view shows each container in the environment -- name, image, host, cluster, compliance heat map
- Open up to see the best practices within compliance -- make sure to check the version number for compliance
- Check compliance standard vendor with description in Prisma Compliance Container View
- Compliance vendors will show audits, remediation, etc.
The Trusted Images feature controls developer access to a specific registry, images or layers. Trusted Images ensure that developers are using verified or approved sources for their images and provide a straightforward way to implement the best practices for container security.
It is recommended to specify the images it trusts. Declare trust using objects called Trust Groups. Trust Groups collect related registries, repositories, and images in a single entity. For writing policy rules, it’s recommended to use registries or repositories for the trusted groups, if they are an organization’s golden standard images.
As a best practice, the default rule, Default - alert all should be maintained, and it should be the last rule in your policy as a “catchall” rule. The default rule matches all clusters and hosts (*). It will alert the images that aren’t captured by any other rule in your policy.
Assuming the default rule is in place, the policy is evaluated as follows:
- A rule is matched: The rule is evaluated.
- A rule is matched, but no trust group is matched: The image is considered untrusted. Prisma Cloud takes the same action as if it were explicitly denied.
- No rule match is found: The default rule is evaluated, and an alert is raised for the image that was started. The default rule is always matched because the cluster and hostname are set to a wildcard
- Admission Control - Prisma Cloud provides a dynamic admission controller for Kubernetes and OpenShift that is built on the Open Policy Agent (OPA). In Console, you can manage and compose rules in Rego, which is OPA’s native query language. Rules can allow or deny (alert or block) pods. Console pushes your policies to Defender, which enforces them. Decisions made by the system are logged.
- Once the admission webhook configuration YAML is applied and rules are created, an audit will be created if there are any violations based on your rules. You can monitor this under monitor>events>admission audits. Click on an audit to get more details and it will also hold the cluster information
- You can also integrate this audit into our alerts integration tool. As soon as the alert is created, you will be notified via the alert provider you select.
- Kubernetes auditing - The Kubernetes auditing system records the activities of users, administrators, and other components that have affected the cluster. Prisma Cloud can ingest, analyze, and alert on security-relevant events. Write custom rules or leverage Prisma Cloud Labs' prewritten rules to assess the incoming audit stream and surface suspicious activity.
- Once you have created the rules you can monitor the audits under Monitor > Events > Select Kube Audits. You can filter based on alert techniques and export it as a CSV. Click on an audit to get more details about the cluster, IP, time stamp etc.
By deploying Prisma Cloud’s defenders you gain continuous scanning with a single pane of glass. An overview of the runtime environments, resources, and firewalling make it simple to create reports and integrate new technologies into your stack with a peace of mind. Once the Defenders setup is completed, one can protect their environment by creating vulnerability, Compliance policies and creating alerts for the same. Furthermore, using trusted images gives a simple approach to put the best practices for container security into reality while ensuring that developers are utilizing approved sources for their images. Lastly, establish and monitor access control measures for cloud workloads and cloud native applications.