How to Secure a Public Cloud with DevSecOps

TL;DR

Secure public cloud environments by decentralizing security alongside infrastructure and operations, while giving DevOps teams self-service controls with built-in auditability. Begin with established recommendations, adopt only observable, actionable, and enforceable policies, provide compliance services before introducing those policies, and create an exception process before enforcement. Use corporate authentication, group-based authorization, and short-lived credentials to limit damage when credentials are compromised.

Transcript

So let me figure this one out. Okay. So three years back, uh, we decided to migrate from our on-prem, uh, infrastructure to the public cloud. So today we are going to share with you our experiences that we gathered during our journey from moving to, uh, our private data centers into the public cloud. So multiple things were happening at the same ti... Read More

Key Insights

• Cloud migration changes the security operating model because infrastructure and production responsibilities move from centralized IT toward decentralized DevOps teams. Release cycles accelerate, developers become involved in production, and changes occur at the speed of APIs or code, while centralized security practices may remain tied to private data centers.
• DevSecOps is the proposed method for decentralizing and democratizing security alongside infrastructure and operations. Its purpose is to let teams secure public cloud environments without turning security reviews and controls into impediments that slow or obstruct the broader migration process.
• Established cloud security recommendations provide a pragmatic starting point for policy development. The organization began with CIS recommendations because they were already known and tested, instead of attempting to define every possible security requirement before taking any practical action.
• A valid security policy is observable, actionable, and enforceable. Requirements lacking these qualities are treated as recommendations rather than policies, because teams must be able to detect relevant conditions, take corrective action, and consistently apply the required control.
• Policy rollout depends on operational support and exceptions. A policy should not be introduced until services help operators and developers comply, and it should not be enforced until an exception process exists for legitimate business reasons that prevent universal application.
• A cloud security maturity framework can progress through crawl, walk, and run stages. Initial controls cover access, roles, IAM rules, and configuration, later controls address assets and the service life cycle, and the developing end state makes activities traceable for audits.
• Corporate single sign-on extends the corporate access-control boundary into the public cloud. Corporate credentials authenticate users, while Active Directory lists and groups authorize access, reducing reliance on independently created cloud identities that may operate without adequate organizational awareness.
• Short-lived credentials reduce the blast radius of credential loss. KeyMaster authenticates users through corporate credentials and multifactor authentication, then issues temporary X.509 certificates or OpenID Connect tokens for up to twenty-four hours, with a sixteen-hour default and shorter configurable lifetimes.

Questions & Answers

Q: How can organizations secure a public cloud migration?

Organizations can secure a public cloud migration by decentralizing security in parallel with infrastructure and operations. They should begin with established recommendations, obtain agreement from security leaders across business units, and build a staged maturity framework. Every policy should be observable, actionable, and enforceable. Teams should receive services that enable compliance before a policy is introduced, and an exception process should exist before enforcement begins.

Q: Why does centralized security struggle in a DevOps cloud environment?

Centralized security can struggle because public cloud operations are decentralized, release cycles are faster, developers work directly with production environments, and changes move at the speed of APIs or code. Security practices inherited from slowly changing private data centers may not fit that operating model. The resulting mismatch can make security an obstacle unless security capabilities and responsibilities are distributed to the DevOps teams operating the environment.

Q: What makes a cloud security requirement an enforceable policy?

A cloud security requirement becomes a policy when it is observable, actionable, and enforceable. Observability allows the organization to identify whether the relevant condition exists. Actionability means operators or developers can respond to it. Enforceability means the organization can apply the requirement consistently. If those qualities are absent, the requirement remains a recommendation rather than a policy within the security maturity framework.

Q: When should a new cloud security policy be introduced and enforced?

A new cloud security policy should be introduced only after services are available to help operators and developers comply with it. Enforcement should begin only after an exception process has been created. This sequence recognizes that legitimate business reasons can require exceptions and prevents blind enforcement. It also ensures teams have practical tools for satisfying a requirement before they are held accountable for following it.

Q: How does corporate single sign-on improve public cloud access control?

Corporate single sign-on funnels normal access to cloud environments and assets through the existing corporate identity boundary. Corporate credentials handle authentication, while Active Directory lists and corporate groups provide authorization. This approach avoids depending on separate public cloud identities for everyday access. IAM users and root credentials may remain for emergency use, but their use triggers an alert and is limited to break-glass scenarios.

Q: How does KeyMaster provide temporary cloud credentials?

KeyMaster authenticates users with corporate credentials and multifactor authentication through VIP or a YubiKey. It then generates temporary credentials suited to the use case, including X.509 certificates and OpenID Connect tokens. The default lifetime is sixteen hours, it can be configured as short as a few seconds, and it cannot exceed twenty-four hours. Users employ these credentials to access other services.

Q: Why are ephemeral credentials preferred for cloud operators and developers?

Ephemeral credentials are preferred because their limited lifetime reduces the possible damage when a credential is lost or compromised. Operators and developers access the environment through credentials obtained using their corporate identity, rather than permanent keys. Those credentials are valid for restricted periods, no longer than twenty-four hours. The design assumes compromise can occur and focuses on containing its blast radius.

Q: How should cloud security maturity develop over time?

Cloud security maturity should develop through a crawl, walk, run sequence. The first stage covers foundational controls such as standard environment access, roles, IAM rules, asset configuration, and asset identification. Later stages expand into instances, load balancers, and security across development, deployment, and operations. The developing end state makes security activities traceable during audits through services and resources built into the framework.

Summary & Key Takeaways

• Moving from private data centers to the public cloud created a mismatch: infrastructure, operations, and production access became decentralized and faster, while security remained centralized and tied to older practices. The proposed response was DevSecOps, which distributes security responsibilities and capabilities without making security an obstacle to the cloud migration process.

• The organization formed a cross-business security group and built a maturity framework using established cloud security recommendations. Policies had to be observable, actionable, and enforceable. Supporting services had to exist before policies were introduced, and an exception process had to be available before enforcement so legitimate business requirements could be handled safely.

• Security services were designed for DevOps, delivered mainly through self-service, and equipped with auditable processes. Corporate single sign-on extended the existing access boundary into the cloud, while KeyMaster issued temporary certificates or tokens. Corporate groups supported authorization, and emergency credentials generated alerts whenever they were used.

• Access control was treated as the outer ring of cloud defense because public cloud environments expose multiple entry corridors. The organization used corporate credentials for authentication and Active Directory groups for authorization. Permanent IAM users and root credentials were limited to emergency scenarios, while normal operator and developer access relied on credentials lasting no more than twenty-four hours.

• The maturity framework followed a crawl, walk, run progression. It began with environment access, roles, IAM rules, and configuration, then expanded to assets such as instances and load balancers. It subsequently addressed security throughout development, deployment, and operations, with the long-term objective of making activities traceable and auditable across the framework.