In our previous blog, we outlined the following three categories of container security:
- Image assurance
- Infrastructure security
- Runtime security
In this article we dive deeper into the rich capabilities in our HyTrust Cloud Control (HTCC) product version 6.0 for securing the deployment of containers in a Kubernetes environment. Deployment Control is all about securing ‘what’ images can be deployed in a Kubernetes cluster, while Access Control is about ‘who’ can perform what operations.
HTCC 6.0 Secures the Continuous Deployment (CD) Phase as Follows:
- Prevent/limit deployment of images from public registries.
- Only allow images to be deployed from select approved private registries.
- Restrict images with vulnerabilities from being deployed. This provides the flexibility to define fine grained rules to suit different needs:
- Thresholds based on CVE severity levels – e.g, a stringent production environment processing PCI information may not want to allow images that has any critical/high/medium severity CVEs, whereas the requirements for a developer/test environment could be a bit more lenient.
- Ability to whitelist certain CVEs when suitable mitigations are in place. This way such images with whitelisted CVE(s) can be allowed to be deployed.
- Ability to blacklist CVEs that can compromise the overall security posture – e.g, the Spectre/Meltdown CVE could be configured as a blacklisted CVE, in which case any image with this CVE would be categorically denied.
- Support notion of image whitelist and blacklist based on various image attributes. Such whitelisting/blacklisting could be done based on the following:
- Version of image – e.g, only allow version 8.0 of Tomcat to be deployed and not the earlier versions.
- Repository – e.g, do not allow images from repository named abc.
- Image content – e.g, deny images that allow SSH access.
- Image integrity/trust – e.g, only allow properly signed images to be deployed.
In HTCC 6.0, Deployment Control policies for the above are described as YAML documents called Trust Manifests. Such Trust Manifests can be easily defined using an intuitive UI or directly thru a editor such as vi.
Trust Manifests can be applied to one or more clusters or namespaces within a cluster.
Depending on the nature of the workloads one could define different suitable fine-grained Trust Manifests and apply them to the appropriate clusters/namespaces.
HTCC 6.0 provides rich dashboards and insights around following:
- Deployment violations and trends.
- Top offending images
- Drifts in runtime posture of containers etc.