* WIP * WIP - Secure Intro Guide * WIP secure intro guide * WIP Secure Intro Guide * WIP Secure Intro Guide * WIP Secure Intro Guide
3.7 KiB
layout | page_title | sidebar_current | description |
---|---|---|---|
guides | Secure Introduction of Vault Clients - Guides | guides-identity-secure-intro | This introductory guide walk through the mechanism of Vault clients to authenticate with Vault. There are two approaches at a high-level: platform integration, and trusted orchestrator. |
Secure Introduction of Vault Clients
A secret is something that will elevate the risk if exposed to unauthorized entities and results in undesired consequences (e.g. unauthorized data access); therefore, only the trusted entities should have an access to your secrets.
If you can securely get the first secret from an originator to a consumer, all subsequent secrets transmitted between this originator and consumer can be authenticated with the trust established by the successful distribution and user of that first secret.
The Vault authentication process verifies the secret consumer's identity and then generate a token to associate with that identity. Tokens are the core method for authentication within Vault which means that the secret consumer must first acquire a valid token.
Challenge
How does a secret consumer (an application or machine) prove that it is the legitimate recipient for a secret so that it can acquire a token?
How can you avoid persisting raw token values during our secure introduction?
Secure Introduction Approach
Vault's auth methods perform authentication of its client and assigning a set of policies which defines the permitted operations for the client.
There are two basic patterns to securely authenticate a secret consumer: platform integration and trusted orchestrator.
Platform Integration
In the Platform Integration model, Vault trusts the underlying platform (e.g. AWS, Azure, GCP) which assigns an identifier to its cloud resources (e.g. an IAM token, instance ID, JWT). The Vault client (secret consumer) authenticates with Vault using its platform provided identifier. Once its identity was successfully validated against the platform, Vault returns an initial token to the client with a set of configured policies attached.
Use Case
When the client app is running on a VM hosted on a supported cloud platform, you can leverage the corresponding auth method to authenticate with Vault.
Reference Materials:
Trusted Orchestrator
In the Trusted Orchestrator model, you have an orchestrator which is already authenticated against Vault with privileged permissions. The orchestrator launches new applications and inject a mechanism they can use to authenticate (e.g. AppRole, PKI cert, token, etc) with Vault.
Use Case
When you are using an orchestrator tool such as Chef to launch applications, this model can be applied regardless of where the applications are running.
Reference Materials:
Next steps
Read the reference materials listed for secure introduction model best suited for your use case.