Containerized Identity and Access Management

Containers are a familiar concept to anyone working with cloud technologies. They are the building blocks of modern software architectures using technologies such as Kubernetes, Docker, microservices, serverless and others. They contain the applications and all the related dependent software that run in the cloud. One of the main goals of containers is portability. Portability allows deployment of containers in different environments. 

Almost everything needed to run an app is in the container, but not quite everything. Containers are dependent on a few external services, such as the operating system (OS) used in the environment (e.g., Ubuntu Linux) on which they run and the Identity and Access Management (IAM) system that manages their credentials. The IAM system gives deployed security identity, trust, and access control within their cloud environment (think identity credentials such as a PKI certificate and authentication secrets such as keys and tokens). Credentials are the essential ingredient of trust in digital environments.

In the cloud, each microservice, app, device (workloads) needs identity credentials for trustworthy data sharing, security, and privacy. IAM services such as automated certificates authorities (CAs), cert managers, secrets managers and others provide authentication and authorization for workloads in a specific environment. Sometimes this is as small as a ‘cluster’ or as large as a commercial cloud environment (e.g., AWS, Azure, GCP). Regardless of the size the IAM services must have ‘scope’ for their policies and credential trust by other workloads in the environment. 

The Problem With IAM Services

Herein lies an identity and trust problem that is similar to what humans experience when they travel internationally. They may have identity credentials like a driver’s license that are recognized in their home country, but that credential won’t help them when they meet a customs officer at the border of another country. They need a passport for that. Unfortunately this analogy is not possible in the cloud, and other systems external to the container are needed to ‘transfer’ and ‘broker’ the identity trust of workloads that interact across IAM boundaries. This adds a great deal of complexity and requires additional services and tools to ensure trust.

The portability of containers is constrained by external IAM services. They become ‘bound’ to the environment of the IAM system where they operate and they are less portable than intended. Moving them to a different cluster or cloud requires effort and new identity credentials.

The Solution: Containerized IAM

What if the workloads could hold their own credentials and not be dependent on external services? What if they could be like humans who carry a mobile device with them everywhere and it always had their authentic identity credentials? Workload trust and portability would be much improved. Think of this as being like “IAM in a box.” 

This is now possible with a novel technology that has containerized the IAM services normally provided by the cloud environment, but with higher verifiable identity trust and theft-proof secrets credentials. The container operates as a ‘sidecar’ and attaches to a host workload (the app) so that wherever the workload operates, it carries its own IAM services with it. For containerized workloads it becomes a “Bring Your Own IAM” solution.

Not only is the app container more portable, and more trustworthy than before, but it is also much easier for two workloads in different cloud environments to recognize and trust each other. Just like a passport, their IAM credentials are universally recognized by other trusted workloads. 

A New Generation of Workload IAM

Containerized IAM is like “IAM in a box” and it is a new generation of IAM specifically designed and engineered for the modern challenges of multi-cloud operations. Over 76% of businesses operate in more than one cloud today. And these clouds come in all forms: Hyperscale, Industry, Regional, Edge, Hybrid, On-premise and others. Most utilize the popular Kubernetes container system. And many also use Envoy proxy to manage the complexity of network connectivity for container apps. Envoy performs the important network connection and communication tasks so developers don’t have to build that into each app they deploy as a workload.

At Hopr, we found a way to leverage Kubernetes and Envoy open source technology and add a novel Machine Alias ID (MAID) credential and Synchronous Ephemeral Encryption (SEE™) protocol that gives an Envoy host workload its own IAM capabilities. IAM capabilities for containers and workloads that were previously performed by external services are no longer needed and identity trust is much improved. Not only is the containerized app free to be deployed in any environment, but its identity and secret credentials are much more secure. With a “IAM in a box” approach the identity and secret credentials are under the management of a “sidecar” that rotates the credentials each time a communication session is initiated. Each ‘session’ might have multiple API calls and responses, but they are all protected by SEE™. And, unlike traditional external IAM services, the trustworthiness of each credential is verified at each session to ensure that only trusted workloads are communicating with each other. This adds a high level of endpoint protection to containerized apps that is not possible with traditional IAM services.

A Use Case

An important use case is present in businesses that operate in multiple cloud environments. A recent survey indicated that more than 70% of businesses operate in more than one cloud. Sometimes this is due to the complexity of integrating business applications from a merger or acquisition, or change in cloud vendors due to a competitive award process (common in government organizations) where an incumbent cloud provider loses the competition with a competitor cloud vendor. Whatever the reason, it is very difficult and expensive to integrate all applications across multiple clouds. But it may be important to migrate some of the applications (containers) from one cloud to another to gain important efficiencies and improve performance.

Traditionally, the migration from cloud IAM services between clouds can take weeks of developer time and may require changes to code and further testing. With a “IAM in a box” approach, there is still some work to be done, but it is much simpler and easier and the SEE™ protocol for data security is an added advantage. It is likely that the total ownership costs of containerized applications are also less when the “IAM in a box” approach is used.

Another important advantage is that all the complicated external IAM services are replaces by a simple SaaS solution that is very easy for DevOps to deploy into production. There is less  burden on an organization's busy developer team when a containerized workload migration from one cloud to another is needed. This frees them up for more important tasks.

‍