Identity-based Security and Low-trust Networks

At its core, the move to cloud is often described as a shift in operating model for infrastructure. As we transition to cloud, we move from a relatively static world of dedicated servers, static IP addresses, and a clear network perimeter to the cloud model, which has dynamic pools of compute capacity provisioned on demand, dynamic IP addresses, and no clear perimeter.

For security teams, this model requires a fundamentally different approach: instead of focusing on a secure network perimeter and the assumption of network trust, the focus is to acknowledge that the network in cloud is inherently "low trust" and move to the idea of securing infrastructure and application services themselves. Many of our users leverage HashiCorp Vault to authenticate the identity of operators or applications against a trusted source of identity and then leverage that authentication to control access to data, systems, and secrets.

This document focuses on identity and how it is leveraged for controlling access to systems and secrets.

Managing access to secrets in a hybrid world consists of two primary user types: humans and machines. Managing secrets for humans can be a fairly straightforward experience, even with the most powerful management systems and APIs. Those systems simply need to permit or restrict access to create or manage secrets, or manage others who may have access, based on the identity (or identities) the user logged in with.

Machines, however, are a different issue, as they can include servers, virtual machines, applications, microservices, scripts, and more, all potentially needing access to different systems and secrets. When it comes to managing secrets with machines, the dynamic nature of HashiCorp Vault comes to the forefront. The ability to create dynamic secrets per service has several benefits — secrets can be short lived, specific secrets can be revoked in the event of a breach, and all actions are audited per secret. Each service is given access to secrets based on their identity and the policy associated with it. With Vault, whether a user is looking to create and distribute organizational secrets and access or applications are looking to retrieve new database credentials every 15 minutes, centrally managing this access based on trusted identities is critical.

In Vault 0.9 (both Enterprise and OSS), Vault introduced a new means of managing access to secrets with our new Identity system. This system allows Vault to understand the identity of individual users and machines across different authentication methods. There are two fundamental components of the Identity system: entities and groups.

Identity Entities

Identity Entities (or just Entities) are aggregated external identities that represent users and applications within Vault as a single, common identity. Entities make it easier for teams and organizations to identify who someone is across a multitude of providers. Once the various authentication methods are associated to one entity, it is easier to apply policy to that one entity rather than per authentication method.

In the image below, think of Alex as the primary account holder who has accounts in different clouds and systems. Vault can recognize Alex's different credentials and identities as one, whether he was using LDAP, Azure, or Google Cloud credentials; Vault still sees it as Alex.

Identity Groups

Identity Groups build on the concept Entities, in that Vaut allows teams to create and manage logical groupings of entities. Groups that can be based on organizations or teams within companies and can be used to assign policies and metadata, making user management dramatically simpler, especially for automating workflows by using Identity Groups to quickly and easily grant access to secrets and functionality within Vault.

Identity and Access Management in Vault

With Identity and Access Management (IAM) in Vault, users and organizations can map global access and policies to Vault Identity Entities and Groups. For example, let's say Alex is running an application in a Kubernetes container on Google Cloud that gets deployed from GitHub, connects to a database in Azure, and replicates to AWS. Alex can integrate his different cloud identities into an "Alex" entity and centrally create policies granting and restricting access to secrets for the different components to connect securely to one another, all within one workflow and API.

Full Identity documentation is available here

At HashiCorp, we believe in the principle of workflows over technologies. With Vault, this means we have taken the approach that Vault should be able to work with any authentication method or secrets engine. While Vault is actively working to integrate major identity providers, we have also created a secure plugin mechanism that enables easier and faster integration with any identity provider or Secrets engine or system through a custom plugin system.

Plugins allow teams and organizations to securely author and extend Vault Enterprise and Vault Open Source to support custom integrations for Identity authentication and Secrets engines. These can either be developed by the user themselves or shared and integrated with or from other developers. Using a plugin is simple and requires no source code changes and provides a unique "plug and play" architecture for common security management tasks.

For more details on creating and using plugins see: HashiCorp Vault plugins documentation

In Vault 0.10, we announced the native integration of Azure Active Directory (AAD) as a new identity provider and authentication method. Users can now directly integrate Azure AD identities with ease. Vault is continuing to build upon our relationship with different cloud partners to integrate the different cloud identity platforms, along with other identity platforms, such as Okta.

Vault supports the following identity providers and platforms natively:

• Google Cloud
• Microsoft Azure
• AWS
• Kubernetes
• GitHub
• Okta
• Centrify

Vault is actively working with other identity providers to expand the ways users can integrate with these providers and will be releasing additional native integration in the coming months. In addition to the identity providers listed above, Vault also includes the following authentication methods:

• AppRole
• LDAP
• RADIUS
• TLS Certificates
• Tokens
• Username & Password

The combination of multiple authentication sources and a variety of secrets engines available can provide for controlled access within a wide range of implementations.

Consider the following example use cases all made possible by Vault:

• A development team can leverage GitHub credentials to obtain short lived SSH credentials, allowing remote access to Linux servers.
• A Database administrator can obtain a set of read-only database credentials good for four hours, with multi-factor authentication enforced via the combination of their LDAP credentials and a one-time password generated by Google Authenticator application on their phone.
• A web developer group in Active Directory can obtain limited access to an AWS S3 bucket via AWS credentials only good for one hour.
• An organization would like to require either Okta or OpenLDAP authentication to obtain Google Compute Platform credentials good for seven days.
• After being acquired, employees from the company need to access secrets of the parent company leveraging the smaller company's directory server.

Vault has been successful in altering the market's perception of managing secrets across multiple platforms and identity providers. Security in a dynamic world is a dramatic shift from that of the common approaches of the static world. Instead of wrapping security around static servers and applications, it's dynamically woven between the different components and tightly coupled with trusted identities and policies. With Vault, organizations can leverage any trusted source of identity to enforce access to systems and secrets.