The Top 6 Identity Concerns of CloudOps Teams

You’ve got humans and machines working together, but who’s doing what and when?

Man with question mark for a face in front of a building overlayed with symbols and a fingerprint pattern

Identity has become the front door to all of our online experiences. As apps moved from the contained domain and context of a single workstation to the universally accessible universe of the internet and cloud computing, identity became the security perimeter and the way apps know to serve and tailor the right experience to a user.

In the background, a similar evolution happened in the data center — APIs are now the building blocks of the internet. 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.

There is now a new identity problem emerging. The rise of automation means that there is a new type of identity scenario to consider — machines operating on behalf of humans. When some actions are taken directly as humans, and some by machines acting as humans, you have a complicated identity problem with fragments of actions executed either directly by a human or by a machine.

With all this complexity, here’s a countdown of the top 6 challenges CloudOps, ITOps, and DevOps teams face in this new world of technical operations:

6. OAuth#

Almost no explanation needed. OAuth does a ton to secure access to APIs, but it is a beast of a standard. It contains tons of token types, grant types, and flows. All the building blocks are there for you to handle identity across humans and machines, but if you’re just using open source toolkits you’re on your own trying to sew it all together across hundreds of services or applications.

Platforms that handle OAuth for you, and connect the dots across various access scenarios can make your life a lot simpler.

5. Orphan accounts#

You’re connected with Active Directory, Okta, and the random LDAP server that the last head of ops set up for your backend system service accounts. So why is it that you still have 19 accounts that seem to be doing something but you have no idea who created them or if they’re still around?

4. API keys#

Now, where did I leave my keys?

In all seriousness, API keys are your basic mechanism for granting access to the APIs of the cloud services you use. Manually handling them in code is not a secure practice.

You can use vault technology to manage them for you. That will keep things secure, but it doesn’t always solve your real-world problem of giving access to the person who needs it at the time they need it. Or, in identifying that in one case a machine was acting on behalf of an ops manager, but in another case, the same glue code was acting on behalf of an on-call engineer.

3. User to API to API#

So, you’ve got a Slack bot set up, and you’ve got some glue code the Slack bot calls that executes some automation on your CI/CD pipeline. Great! You’re off to the races!

Just one problem. Once your bot hands off to the glue code, you lose the context of the end-user.

Your glue code calls your other systems with just a generic machine identity. There’s no way to trace it back to the user who was taking action, leaving a question mark for who actually enacted some change in your backend services.

2. Custom glue code#

You solve problems 3, 4, and 5 by writing yet more glue code. Now you have more code to maintain, and it’s code that manages the keys to the kingdom. Your CISO is going to be thrilled with this.

1. Fear of being in the news#

This brings us to the #1 challenge with all these identity issues that operations teams face. You spend each day hoping that today won’t be the day that all these issues bubble up and cause a failed audit. Or, even worse, they cause a security incident that puts your company in the news headlines.

A better way to solve human + machine identity#

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 in order to handle end-user lifecycles. All automation should not run exclusively through a single user’s account. Instead, you want to have automation that can run as any user’s account, but also runs as the right user’s account based on who is driving the action.

Transposit can help. Connect all the systems you use to operate your cloud services to Transposit, and we’ll handle the rest. Any human or machine action is fully traced to its origin. Sign up for a demo and see how!

Get insights from Transposit in your inbox monthly.

Subscribe

< Back to the blog