Shift Identity Left: Secure DevOps Automation with Okta

To keep up with the rapid pace of innovation, organizations of all kinds and sizes are adopting DevOps practices to better automate the delivery and operations of software in the cloud.

A cultural phenomenon that impacts people and process as much as it does technology, DevOps brings teams together with the goal of removing barriers – the development teams responsible for building and shipping code, and the operations teams responsible for deploying and operating critical infrastructure. Together, these teams form the backbone of any technology company, which if you haven’t heard, is every company.

Building a Culture of Automation

DevOps isn’t just something you put a stamp on and call done; it’s an ongoing cross-functional effort. The rise of Infrastructure as a Service across AWS, GCP, and Azure has paved the way for the on-demand consumption model, but it takes a company-wide initiative to put DevOps into practice.

For development teams, this means applying automation across the entire software development lifecycle (SDLC) through event-driven workflows and CI/CD pipelines. The act of checking in code triggers a series of events that eventually leads to the delivery of new software. The underlying methods are designed for high velocity, where rapid iteration can occur across development, staging, and production environments.

Similarly, operations teams apply automation by declaring “infrastructure as code”, where cloud environments can be spun up on-demand and configured for elasticity. The ability to create and destroy resources to match the workload enables organizations to dynamically adjust to their environments, accounting for spikes and troughs in an automated fashion where the spend is directly attributed to consumption.

This level of streamlined automation is incredibly powerful, but with great power comes great responsibility.

Security Can’t Be an Afterthought

With such high-velocity environments, the surface area is ever-changing, potentially opening up an organization to extreme risk. The last thing you want to do when adopting the cloud is open yourself up to attack, but all too often security is an afterthought towards automation design.

Application developers who don’t treat security as a first-class citizen may not be incentivized to run code through the proper testing cycles. Infrastructure engineers who don’t treat security as a first-class citizen may not be incentivized to wrap controls around the services they deploy.

Without the right security culture instilled in the people and processes, the power of the technology can be dangerous. To get this right, Security teams and processes need to be instilled into the fabric of your DevOps culture.

DevSecOps - “Shift Left” Security

A common term that is used to describe bringing security into the fold is to “shift left”. Considering that software development and infrastructure operations is a continuous cycle, then you want to bring security as close to the design phase as possible. Essentially, if you’re going to automate any part of the process, it’s best to bake security into it. That may sound obvious on the surface, yet it’s so easy and tempting to ignore in the name of speed.

For Development teams, this means running tests and vulnerability scans the moment it’s checked in, only kicking off CI/CD pipelines when all tests have passed. As software is packaged, container or VM, it’s crucial to inspect before delivery.

For Operations teams, this means injecting controls and policies into your automation code. A common method is for your configuration management service – whether it be Chef, Puppet, Ansible, Terraform, or SaltStack – to bake in the administrative accounts and credentials into the code so that they’re pushed down to the machines.

Now, wait a second – if that last practice triggered your security senses, it should have. The traditional methods of injecting identity & access controls into your infrastructure automation pose their own set of risks.

Zero Trust Breaks Tradition

The reason traditional methods are so incredibly dangerous is because of the severe privileges tied to those accounts and credentials. Year after year, the most common source of breaches is credential misuse, which is only exacerbated by the forms of automation DevOps practices put forth. Teams go to great lengths to protect credentials such as SSH Keys through vaulting services or rotation policies, but these practices are counter to the spirit of DevOps as they require a lot of manual lifting to get right.

At Okta, we believe in a better approach closely tied to Identity that doesn’t rely on “protecting the keys”. Zero Trust has emerged as the dominant security architecture for the cloud, and its core principles better support automated DevOps environments. By removing trust from static credentials, controls are rightfully pushed to the endpoints where access is only granted once a request has been fully authenticated and authorized. A proper Zero Trust system such as the Okta Identity Cloud is capable of making that smart, contextual access decision, and then minting a short-lived credential on-demand to match.

When systems and services are automated at scale in the cloud, the last thing you want is static credentials laying around that grant administrative access to your critical infrastructure.

Introducing Okta Advanced Server Access

With Okta Advanced Server Access, you get the best of both worlds – the ability to inject identity and access controls into your DevOps automation without the risk surface area associated with static credentials.

The way it works is by extending the Okta Identity Cloud to the machine level, where local Linux and Windows user and group accounts are sourced and managed by Okta. Instead of injecting accounts and credentials into your DevOps automation code, you inject a simple Server Agent install script. When the Server Agent starts up, it calls out to the Okta API for the list of users and groups who belong to that specific server, and creates the accounts locally.

The install script also configures the machine to accept client certificates signed by Okta as a valid authentication mechanism, replacing the traditional SSH Key or RDP Password credential. Okta will mint a short-lived, tightly scoped client certificate on demand, only once a request has been fully authenticated and authorized. Because the certificates expire in minutes, there’s no need to store them in a vault, rotate them, or revoke them.

With a modern approach to infrastructure access that supports your DevOps automation, security is no longer an afterthought, but rather part of the process. You can streamline the automation of elastic infrastructure with assurances that you are not exposing yourself to credential theft or misuse, meeting security policy without slowing down the business. That’s a secure DevOps culture in action.

Learn more

To learn more about Okta Advanced Server Access, check out our whitepaper The 8 Principles of Modern Infrastructure Access.