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. 

WTcN4CWyBOGLtlwST GphGeXUtK0yf 9vuOuh17sEU9GmiDVzrslz7vNGx8pF3J61gnGAnslh6ozPIA9tWTKle6ZThT1wYIwKWIP99tA1KCuoXMSBFycAsYHjwvakPFsKkK WHn3

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:

jmckXwQ Qk i4NEpPZeoVFP3Tk WeCZnwV92RrmBRtAHKbzf9LAdffZfn5hfSDkaPJR6I9MmXo N6fv0RNeYx8Dpvige70gAKNHhic RDkj3Qluec7auBU19Fma5LR7Uv3ZtWU4d

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.

F3a0qNZn6NR7RPCEGeRvJUf 32 HyN6kW37m9aOGaYH  tux boixz1bDGAWLiGOBswbovPDN2CdGukDxleXrEV8ONo8mAJdwXDLe0kXaweVSnWTvVvjHezMXcH6UfWv6rNAbqeQ

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: