Scale Security While Innovating Microservices Fast
Learn how to scale your applications' security in a cloud-native, microservices architecture by establishing a chain of trust.
Join the DZone community and get the full member experience.Join For Free
CISOs are notoriously risk-averse and compliance-focused, providing policies for IT and App Dev to enforce. In contrast, serving business outcomes, app dev leaders want to eliminate DevOps friction wherever possible in continuous integration and development of applications within a cloud-native, microservices architecture. What approach satisfies those conflicting demands while accomplishing the end goal: scale security?
Establishing a Chain of Trust to Scale Security
As the foundation of information security, 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 Management for the Enterprise
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.
For a broader look at security, read the 5 fundamentals of information security every cloud platform should provide.
Published at DZone with permission of Doug Paris White, DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.