Adapt to the Cloud Operating Model Part 2: The Critical Role of Identity
This is the second blog post in our Adapt to the Cloud Operating Model series.
Identity is at the heart of any organization; it forms the foundation for a productive and secure workforce, and it enables digital teams to build lasting and scalable customer experiences. In the cloud, identity isn’t just about people—it covers the full spectrum of people, process, and technology. As such, identity plays a key role in the evolution towards the Cloud Operating Model.
For many organizations, DevOps programs are an agent of change:
- Technology changes: Dynamic cloud infrastructure environments made up of ephemeral resources constantly spinning up and down changes the surface area.
- Processes change: Streamlined software delivery pipelines and automated infrastructure provisioning changes the workflows.
- People change: Teams collaborating to design secure automation at scale changes individual and collective roles and responsibilities.
The change brought upon an organization has a significant impact, and requires careful attention to ensure things don’t go off the rails. We concluded the previous post in this series by looking at the balance between security and productivity within mature DevOps programs. With velocity as the business driver, how can you move fast without breaking things? As it turns out, identity is the key.
DevSecOps: The security in DevOps programs
At the risk of further confusing terminology, DevSecOps refers to the practice of making security part of your DevOps programs—not an afterthought. Amidst all of this change, new considerations appear that must be addressed early and often. From an infrastructure operations perspective, a changing surface area means that the controls need to be able to adapt to dynamic resources. Security is hard enough when you know where things are, but it gets much harder when you don’t.
Parallels can be made to the rapid shift to remote work amidst the current pandemic. Organizations have been forced to enable their workforce to be productive from any location on any device. People are no longer working from the fixed confines of the office. While enabling productivity, there can be no compromise on security as people are accessing sensitive company resources and data as part of their day-to-day jobs. The Zero Trust security model that has risen in favor over the past few years has now become table stakes to ensure that only the right people have the right levels of access at the right time.
Where organizations often struggle with DevOps programs is the natural conflict between security and productivity. Finding the right balance is hard. When security blocks productivity, it’s bad for the business outcome of velocity. On the flipside, when productivity moves too fast for security, it’s also bad for the business outcome of velocity, but for different reasons.
The 2019 edition of the annual State of DevOps Report commissioned by Puppet, Splunk, and CircleCI focused on security, and their key takeaway was glaring.
“For most companies we’ve spent time with though, integrating security into the software delivery lifecycle is an unrealized ideal, and an obstacle to furthering their DevOps evolution.”—State of DevOps Report 2019
The business outcome of velocity isn’t limited to pace. The change across the organization introduces difficult challenges with regards to speed, scale, and complexity. Practitioners who are on the hook for this change may find themselves uttering the following statements:
- Speed: “Look, we just can’t keep up with the pace of the business unless we make some compromises here and there.”
- Scale: “We’re operating distributed cloud systems at a crazy scale right now—things are bound to fall through the cracks.”
- Complexity: “I mean, we’re still trying to figure out how to even just observe all of our cloud resources, let alone protect them.”
These statements aren’t uttered out of indifference, but out of desperation. And exacerbating this challenge is how damaging a seemingly minor slipup can be. The recent $80m Capital One settlement that led to 100 million customer data records to be leaked originated from a single errant wildcard on an S3 bucket’s IAM policy.
This is why it’s critical for organizations to adopt a culture of secure automation as they build out their DevOps programs, bringing together Infrastructure as Code with Policy as Code.
Shift left: Bring security closer to the people
We’ve all seen enough sci-fi movies to know the dangers of machines taking over if the right guardrails aren’t put in place. While not directed towards a dystopian future, the same principle applies to DevOps automation. Automation is designed for speed per the demands of the business, but any exposure area only compounds risk as you scale. Continuous innovation drives the need for continuous delivery; continuous delivery drives the need for continuous security.
But it’s important for security to be an enabler, not a blocker, so when and where security is applied makes all the difference. The term Shift Left means placing security checkpoints and controls early and often in the development process—as-in, when the humans are still involved. This applies equally to software developers writing application code as it does to operations engineers writing infrastructure code.
Shift Left doesn’t simply mean placing more responsibility on the developers. Quite the contrary. The intention of DevOps programs is to streamline operations so developers can ship software faster and more effectively. Similarly, DevSecOps is meant to streamline security controls and checkpoints towards the same outcome.
Where identity and access management factors in
A fundamental aspect to any system is identity and access management (IAM). Systems that power software applications consist of a number of automation tools and infrastructure, with a consistent need for IAM functionality:
- Provisioning and deprovisioning accounts: Systems have user accounts— human and services—that need to be managed across their lifecycle.
- Performing authentication and authorization: Users need to log in to systems to perform tasks, which require strict contextual access controls given the sensitive nature of the resources.
- Issuing credentials for apps, APIs, and systems: Contextual access decisions need credentials to match, which range from passwords to keys to certificates.
- Brokering secure connections to resources: Credentials are used to establish secure connections with target resources across a range of protocols, including HTTPS and SSH.
- Enforcing security policies: The principle of least privilege dictates that policies should be clear about who can access which systems and when, and what they can do. In order to be effective, policies must be adhered to in practice, which requires a series of enforcement points.
- Logging and auditing user behavior: Policy adherence must be proven to achieve compliance, which means you also need a clear record of what actions users performed throughout your automation processes.
When we overlay these functions across our view of automation processes, we uncover a number of key questions regarding IAM that need to be answered:
Shift identity left
As a critical function across the software development and infrastructure provisioning lifecycle, it reasons that IAM follows the same Shift Left principles. Enter Shift Identity Left—making IAM part of your automation, not an afterthought.
This is especially important when looking at the attributes of the Cloud Operating Model—elastic scale multi-cloud deployments, ephemeral resources that spin up and down, and automated delivery and provisioning. With dynamic environments, you simply can’t bolt on access management after the fact like you may have used to when the server fleets were fixed and static. Instead, you have to bake identity in.
When you make identity part of your automation, you can effectively implement the right guardrails to avoid the dangers of configuration drift and credential sprawl as you automate and scale. The gains are as clear as the outcomes:
- Identity-first access: With identity as the foundation, you can clearly specify, enforce, and audit who can access which resources under what conditions, what they can do, and what they did do. This will improve your security posture and help your compliance initiatives.
- Zero Trust architecture: Dynamic environments need dynamic controls, but imagine spending a ton of effort making a contextual access decision, only to hand someone a static, shared credential. That would be a wasted effort, as you’re still subject to the risk of credential sprawl. Wherever possible, match contextual access with one-time credentials.
- Automated lifecycle management: The other side of the Zero Trust coin is ensuring that accounts are up-to-date with your system of record, and any joiner, mover, or leaver scenarios are applied across dynamic environments in near real-time. Baking identity into automation means you won’t have to worry about cleanup or drift.
What’s next?
Now that we have a perspective on the Cloud Operating Model, and the critical role of identity, our next post in this series will put this into practice. As with any major initiative, it’s a journey that’s best taken in stride. To close this series, I’ll be sharing our experience working with numerous Okta customers who have gone through this journey. Stay tuned!
To learn more about the Cloud Operating Model and DevOps, check out the following resources:
