IAM In A Box

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 costs and services to ensure trust.

The ideal of portable containers is diminished if external IAM services are needed to establish identity trust and strong access control. Containers become ‘bound’ to the environment of the IAM system where they operate. If you want to move them to a different cluster or cloud to gain efficiency, improve security, or improve performance, there is a inherent cost and entirely 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, portability is enhanced with 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 because they operate in the same IAM virtual network.?

A New Generation of Workload IAM

Containerized IAM 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 frequent use case is the various cloud infrastructure and architectures that must interoperate after a merger or acquisition. It is not uncommon for business to operate in very different IT environments. So the complexity of integrating business applications from a merger or acquisition is lengthy and costly. Another event can be a change in cloud vendors due to a competitive award process (common in government organizations) where an incumbent cloud provider loses the contract to 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 specific business applications (containers) from one cloud to another to gain important business advantages (after, all, that is the whole point of the merger or acquisition).

Traditionally, the migration from cloud IAM services between clouds can take weeks or months of developer time and may require changes to code, testing, issue resolution, and repeated cycles. With an “IAM in a box” approach, there is still some work to be done, but it is much simpler and easier than before. And the SEE? protocol for data security is an added advantage. Also, it' probable that the total ownership costs are reduce when the “IAM in a box” approach is used because cloud service spend is much less than before.

Another important advantage is deployment and maintenance. All the complicated external IAM services are replaced 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.

If this sounds interesting, you (your DevOps, actually) can try this IAM In A Box solution for free on AWS Marketplace for as long as you need.

More and more we see cloud native solutions overcoming some of the shortcomings of the first generation of the cloud era and a new generation of cloud native solutions are emerging and maturing to increase the value of digital transformation for the modern enterprise.

This article first appeared on the hopr.co blog at https://hopr.co/blog.