Human + Machine Identity: A New Frontier for DevOps Automation

Identity has become the front door to all our online experiences, and the security perimeter for all our data. However, there’s been no easy way to handle scenarios that involve a combination of human and machine access.

The problem gets worse when you have a stream of activity spanning a wide array of apps and backend systems. This problem surfaces in two use cases that concern the DevOps toolchain: gaining visibility into data and automating DevOps actions.

If you’re an engineer, how many times has someone left your organization and for months or years there are still Jira entries with their name on them?

If that’s happening, there’s a good chance the reason why is that the person put in place some kind of backend automation using their account, and to fix it would mean rebuilding the integration with a new account. What’s worse, you risk running into the same problem again if you just use another person’s account.

One way to solve this, is to create shared accounts that are for automation purposes. That gets you partially around the problem. In some scenarios it could make sense. Of course, now you have to worry about security around your shared account. You’re probably sharing the credentials to that shared account internally, so now you have multiple people who know the password. And, how do you add two-factor authentication when it’s not an account tied to a human?

Shared accounts also remove any ability to manage permissions or audit access back to a human. This might be fine for a simple data sync using Zapier running between PagerDuty and Jira. But what if it’s for visibility to more sensitive service operations data? Or, automating actions to production systems running in AWS?

What’s mostly missing today across automation and integration platforms is bringing in the best of both worlds. You want to be able to tie everything machines are doing on behalf of humans back to the human. However, the system needs to be flexible to handle end-user lifecycles. All automation should not run exclusively through a single user’s account. You want to have automation that can run as any user’s account, and runs as the right user’s account based on who is driving the action.

Just as the evolution of end-user apps moving to the Internet put user identity front and center, the same evolution of infrastructure now managed via APIs puts machine identity front and center.

And, APIs are now the building blocks of the Internet. APIs are an abstraction of all the underlying infrastructure on which modern apps run.

For human identity, there was an early consolidation around the LDAP protocol, with additional protocols like SAML and OpenID Connect created to handle federated identity across organizations. Cloud-based identity services like Okta and Azure Active Directory make it easier to adopt and use these technologies.

For APIs, OAuth has become the leading protocol for handling authorization for API access. It’s a complex set of specifications for different user and non-user flows, but again, identity vendors simplify things and make OAuth easier to deploy.

Modern protocols give us foundational technology, but they don’t automatically solve the full use case.