Human + Machine Identity: A New Frontier for DevOps Automation

(JLStock/Shutterstock)

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.

Pick Your Poison–Machines as Humans or Shared Accounts

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.

How Did We Get Here?

(jijomathaidesigners/Shutterstock)

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.

Gaining Visibility Into Data

Data lives in lots of silos today, and just getting visibility to all of it in one place can be a challenge. Teams have integration fatigue, endlessly setting up point to point integrations across tools or trying to use ETL tools to bring all their data into one place. Adding to the complexity, you need to meet compliance requirements to ensure that Personally Identifiable Information (PII) or business sensitive data does not get exposed.

API interoperability can be a better solution than full integration. A platform that enables you to pull in data from disparate sources as needed, while respecting the identity and permissions of the human viewing that data avoids integration headaches while respecting security requirements.

(rismegist-san/Shutterstock)

When automation runs on behalf of specific humans, you preserve the fidelity of information regarding who pulled in the data from what source. This allows you to continue to manage and respect access to that data outside of its source.

In addition, a platform that provides a full audit trail of all the data that has been retrieved, when it was accessed and by exactly who, gives you the necessary information you need to maintain compliance records.

Automating DevOps Actions

Getting the identity part wrong while automating actions across your DevOps environment has a potentially larger impact than with access to data. There are generally two paths you can go down.

One option is to try to limit access as much as possible and only open up access to systems as necessary. This gives you a smaller attack surface area, but leaves the risk that a now smaller open door still contains the keys to the kingdom.

The other option is to generally trust your people, but have the “human traceability” you need to instantly know who did what across your entire DevOps toolchain. This includes when you have machines doing things on behalf of humans.

An automation platform can go a step further in the trust-based approach by providing guardrails for the actions most commonly taken in your systems. This makes it easy for engineers to stay on a happy path, and avoid accidents. It also makes malicious scenarios more obvious. Bad actors would need to go around automated procedures and their actions would stand out clearly from the noise.

Automating in a Human + Machine World

The net of all of this, is that increasingly you need humans and machines to work in tandem, and the way you handle identity needs to keep pace with this approach.

You want to drive automation where there is repeatability but keep humans involved where there’s no replacement for human judgement. This means that your platform for integration and automation needs to handle the granularity of who has access to what, and flow that through both direct human action and automated action – in the end, also providing you with a complete view across all actions.

This is the new human + machine world, and the innovation around handling identity with automation is just getting started.

About the author: Ed Sawma is VP of Operations at DevOps process automation company Transposit. Ed spent several years as a developer and IT consultant prior to his 15 years at industry-leading technology innovators including Microsoft, Motorola, and most recently Okta, where he supported the growth of Okta’s core products business.

Related Items:

How Modern Data Strategies Underpin the Digital Identity and Authentication Practices Critical to Digital Transformation

AI Powers Mastercard’s New Authentication Process

Machine Learning Used to Reduce Login Hassles