Seven Microservices Identity Questions To Secure Your Data

As I noted in my last blog post, containers, which are now pervasive in enterprises, are ephemeral, and microservices frameworks like Kubernetes treat them as such.

Data security is a complex subject, and, unfortunately, microservices only add to the complexity. I frequently try to untangle the threads of knotty issues by asking questions. So, in this and my next few blogs, I will share some questions you might want to ask as you go about securing your data in a microservices environment. I’ll use the following perspectives as lenses:

• Identity
• Software integrity and pedigree
• Data security
• Network security
• Trust

Today, I’ll share some thoughts and questions about identity.

Identity is important, because it is how a microservice, or whatever controls access to the microservice, determines whether an entity (human/thing/service) has a right to access the microservice and data and at what level (authorization). As such, managing identity is a foundational component for proper data security. Identity in a data security context is comprised of three main components:

1. Authentication: Who are you and how do you prove who you are?
2. Authorization: What are you allowed to do?
3. Auditing: Creating an immutable record of what an entity does, when it was done, and under what context.

And now some questions.

Authentication

1. What are the categories of things your microservices need to identify? The different entities that need to access the data via microservices are people; services, such as software applications; and things, such as a client or a server. Which of these will your system need to deal with?
2. How will identities be managed? Will each microservice manage its own identities (lift and shifted applications)? Will it leverage identities from an IDP? If so, do you manage the IDP, or do you allow your customers to integrate their own IDPs (OIDC, LDAP, etc.), or will your framework provide and manage identities? So, I’m suggesting three categories: one in which you have no control over the identity, but you have to understand it, personalize it, and manage it; another in which you have your own identity service that you are managing; and, a third in which, inside your microservices and as part of your framework, you are standing up and managing your own identities internally.
3. How do you ensure that identities are authentic? That is, how do you ensure the identity is who or what it purports to be? How do you determine it is authentic? Are there multiple challenges against that identity overtime (MFA, continuous authentication, etc...)?

Authorization

1. Once the identity is authenticated, what will authorize its access privileges? Will each microservice be identity aware from some centralized authorization service? Will the service itself decide whether or not it should do things for a given identity? Will there instead be a centralized authorization service that overlays a service mesh network and removes the microservice from this process altogether? If so, which service will you use? Who will manage policies and how are those policies harmonized across many microservices?
2. How granular will the authorization process be? Will access be attribute based? For example, this user, with these conditions, at this time, in this geography is allowed to do this thing. Or will it be role-based access, where, based on a role (for example administrative vs. user), an identity will be given certain permissions. Which authorization model will you use?

Logging

1. How will we audit all this? The last critical piece to put in place is auditing, which is necessary to identify current and future vulnerabilities. The authentication needs to be audited when you create a user, when a user logs in, and so forth. The authorization should also be recorded in a log that can’t be modified.

Where Questions?
We also need to ask:

1. Where in the stack will you do the authorization? This is very important. In a non-micro-service environment, your monolithic application will have your database, your application log, your web server, and everything else it needs to make identity authorization decisions in its business logic, and all of this will be local to the application. In a microservices environment, you divide everything in that monolithic application into individual, bespoke microservices. And authorization is one of those things that’s really important to get right.
   You might have 20 different microservices, and each of these microservices might need to be identity aware to function (or not) for the requesting identity. Does each microservice need to be able to read the identity and make a determination? Or, does it need to call a centralized authorization service to get a yes-no answer? Or, is there a network higher up in the stack that does that all for you? That’s why overlay services, such as Istio, look so useful today.
   So, the where question has to do with both where you make and where you enforce your authorization decisions.

This is a lot of questions. And when I consider all these moving parts, it feels like I’m playing 4-D chess in my brain. But I’ve always found a good place to start is to get the questions down on paper and address them one by one.

Please leave a comment below and follow us on Twitter, LinkedIn, and Facebook, @solcates.