How to Scale Security with a Hardware Chain of Trust
CISOs are notoriously risk-averse and compliance-focused, providing policies for IT and development teams to enforce. By contrast, in the name of serving business outcomes, App Dev leaders want to eliminate DevOps friction wherever possible. What approach satisfies those conflicting demands while accomplishing the end goal: at-scale security?
Establishing a Chain of Trust
A hardware-rooted chain of trust verifies the integrity of every relevant component in the cloud platform, giving you security automation that flexibly integrates into the DevOps pipeline. A true chain of trust would start in the host chip firmware and build up through the container engine and orchestration system, securing all critical data and workloads during an application’s lifecycle.
Hardware is the ideal foundation because it is rooted in silicon, making it difficult for hackers to alter.
The chain of trust would be built from this root using the measure-and-verify security model, with each component measuring, verifying and launching the next level. This process would extend to the container engine, creating a trust boundary, with measurements stored in a Trusted Platform Module (TPM) on the host.
So far, so good — but now you must extend this process beyond the host trust boundary to the container orchestration level. You must continue to scale security.
Attestation software on a different server can verify current measurements against known good values. The container orchestrator communicates with the attestation server to verify the integrity of worker hosts, which in turn set up and manage the containers deployed on them. All communication beyond the host trust boundary is encrypted, resulting in a highly automated, trusted container system.
How to Scale Security with a Chain of Trust
What do you get with a fully implemented chain of trust?
- Enhanced transparency and scalability: Because a chain of trust facilitates automated security, DevOps teams are free to work at unimpeded velocity. They only need to manage the security policies against which the trusted container system evaluates its measurements.
- Geographical workload policy verification: Smart container orchestration limits movement to approved locations only.
- Container integrity assurance: When containers are moved, the attestor checks to ensure that no tampering occurred during the process. The system verifies that the moved container is the same as the originally created container.
- Security for sensitive data: Encrypted containers can only be decrypted on approved servers, protecting data in transit from exposure and misuse.
- Simplified compliance controls and reporting: A metadata audit trail provides visibility and audit-able evidence that critical container workloads are running on trusted servers.
The chain of trust architecture is designed to meet the urgent need for both security and rapid innovation. Security officers can formulate security policies that are automatically applied to every container being created or moved. Beyond maintaining the policies themselves in a manifest, each step in the sequence is automated, enabling DevOps teams to quickly build and deploy applications without manually managing security.
As your team evaluates cloud platforms, ask vendors to explain how they establish and maintain trust in the technology that will host your organization’s applications. It helps to have clear expectations going in.
Feature image via Pixabay.
The Cloud Native Computing Foundation, which runs KubeCon + CloudNativeCon, is a sponsor of The New Stack.