Do you trust your Microservices Identities?

Microservices provide great benefits to development organizations. They enable multiple autonomous development teams to work on the same application, maintaining efficiency, speed, and utilization of modern resources such as open source, containers and programming languages. The Microservice paradigm simplifies application building, debugging, management, deployment, scalability and of course time to market.

In this new world of Microservices, a common practice is to use different forms of microservices identity in order to simplify the provisioning of policies and configurations, these could be routing policies in a services mesh, load-balancing rules, and security policies such as data access and network policies.

With service identity taking such a central role, it is key for security minded organizations to take a closer look at how identities are established in their environment and how secured these identities are.

How are identities established? Can you trust your microservices identities?

The most basic usage of microservice identity is for microservices to identify themselves to other microservices as they communicate with them or when accessing controlled resources. However, how much can we trust such identification? When a solution in penetrated, what would prevent malicious software from posing as legitimate service? The answer is – authentication. Authentication is a must have security mechanism for any identity based operational model.

For authentication to be trustworthy, it must be based on something that can’t be copied or faked – a secret that nobody else can obtain. Traditional authentication methods use private keys, passwords, Java Web Tokens (JWT) or similar tokens. These models have two fundamental security problems that must be addressed.

The “Chicken and Egg” problem of Identity Establishment

As described above, services authenticate each other using secrets. However, how does a service get that secret in the first place? We refer to this as the “chicken & egg” problem because a service needs a secret to be authenticated, and it needs to be authenticated to obtain the secret.

This “chicken and egg” problem is even more significant in highly dynamic microservice environment because services go up and down constantly, auto-scale, and may run on different nodes. These services don’t share any common security protocols or infrastructures. Using environment attributes such as service name, node name and other attributes cannot be considered secure because any malicious software has access to this information, yet they are used due to lack of a better option.

Protecting secrets after they are distributed

Since service authentication may be required at any time during the service life-cycle, the service must be able to protect its secrets after they have been obtained, regardless of how the secrets where distributed. For interoperability reasons, communicating services use standard security protocols and algorithms implementations. These implementations are often open source. They require secrets to be present in memory while they are used.

When service software or device are compromised, these secrets can be easily stolen from the memory because the attackers know what to look for. This problem of protecting secrets in-use is one of the most complicated problems in cryptography.

Proposed solution for secured identity authentication in microservices

Learning from the user authentication experience, we know that legacy secret-based authentications such as passwords were replaced by multi-factor authentications or stronger bio-metric type of authentications. It is no more just about “what you have” (your token”) it is also about “what you are” (your retinal scan, fingerprint, etc..)

Cyber Armor brings this very same principle into the service authentication space. It adds a “what you are” factor on top of the regular “what you have” model, thus creating multi-factor microservice identity authentication.

Cyber Armor uses Cryptographic Code Signature for service authentication. This approach is similar to bio-metric authentication using human DNA and is therefore called code-DNA. Our patented technology is designed to verify the cryptographic signature of the service during its execution in memory. This signature uniquely identifies each software service. When applied to both communicating sides, it provides the necessary authentication factor for access policy validation.

Hope you found our content interesting. We always appreciate getting feedback and discussing our ideas, please feel free to drop us a line, we make sure to answer everyone. [email protected]

‍