Vault on Red Hat Demo Platform (RHDP)
Red Hat's OpenShift is a distribution of the Kubernetes platform that provides a number of usability and security enhancements.
The Red Hat Demo Platform (RHDP) is a way for Red Hat employees and official Red Hat partners to deploy and demo Red Hat products for specific use cases alongside Red Hat partner technology. Visit the Red Hat website for demos and workshops.
In this tutorial, you will login to an OpenShift cluster and configure the authentication between Vault and the cluster. You will then deploy two web applications; One that authenticates and requests secrets directly from the Vault server. The other will utilize deployment annotations that enable it to remain Vault unaware.
Upon completion of this tutorial, you will gain a better understanding of how Vault is deployed on Red Hat OpenShift and how Vault integrates with applications running in OpenShift clusters.
Note
The RHDP system is only available for Red Hat/HashiCorp employees and official Red Hat partners. Please contact technologypartners@hashicorp.com for further information and access to the system.
Prerequisites
Please make sure your system and network can make external ssh connections.
Once the workshop admin spins up the cluster, you'd be provided with an access URL with username and password.
Upon login, users will receive credentials similar to what's shown below.
Example output:
Upon completion of the last step, you are connected to the bastion running RHEL. Confirm that OpenShift environment is running and the Vault namespace has been created and Vault pods are successfully running.
Output:
Retrieve the web application and additional configuration by cloning the learn-vault-kubernetes repository from GitHub.
Change the working directory to
learn-vault-kubernetes/openshift
.Note
This tutorial assumes that the remainder of commands are executed within this directory.
Configure the Vault Kubernetes authentication
Vault provides a Kubernetes authentication method that enables clients to authenticate with Vault within an OpenShift cluster. This authentication method configuration requires the location of the Kubernetes API, which is available in environment variables within the pod.
Set the current project to Vault
Your system prompt is replaced with a new prompt
/ #
. Commands issued at this prompt are executed on theopenshift-helm-charts-vault-0
container.Start an interactive shell session on the
openshift-helm-charts-vault-0
pod.Your system prompt is replaced with a new prompt
/ #
. Commands issued at this prompt are executed on theopenshift-helm-charts-vault-0
container.Enable the Kubernetes authentication method.
Configure the Kubernetes authentication method to use the location of the Kubernetes host. It will automatically use the pod's own identity to authenticate with Kubernetes when querying the token review API.
Note
For the best compatibility with recent Kubernetes versions, ensure you are using Vault v1.9.3 or greater.Output:
The authentication method is now configured.
Exit the
openshift-helm-charts-vault-0
pod.
Deployment: Request secrets directly from Vault
Applications on pods can directly communicate with Vault to authenticate and request secrets. An application needs:
- a service account
- a Vault secret
- a Vault policy to read the secret
- a Kubernetes authentication role
Create the service account
Display the service account defined in
service-account-webapp.yml
.This definition of the service account creates the account with the name
webapp
.Apply the service account.
Get all the service accounts.
The
webapp
service account is displayed.
Create the secret
Start an interactive shell session on the
openshift-helm-charts-vault-0
pod.Your system prompt is replaced with a new prompt
/ #
. Commands issued at this prompt are executed on theopenshift-helm-charts-vault-0
container.Create a secret at path
secret/webapp/config
with ausername
andpassword
.Output:
Read the secret at path
secret/webapp/config
.The secret with the username and password is displayed.
Define the read policy
Write out the policy named
webapp
that enables theread
capability for secrets at pathsecret/data/webapp/config
.Output:
The policy
webapp
is used in the Kubernetes authentication role definition.
Create a Kubernetes authentication role
Create a Kubernetes authentication role, named
webapp
, that connects the Kubernetes service account name andwebapp
policy.Output:
The role connects the Kubernetes service account,
webapp
, the namespace,vault
, with the Vault policy,webapp
. The tokens returned are valid for 24 hours.Exit the
openshift-helm-charts-vault-0
pod.
Deploy the application
Examine the webapp deployment defined in
deployment-webapp-rhdp.yml
.The deployment deploys a pod with a web application running under the
webapp
service account that talks directly to the Vault service created by the Vault Helm charthttp://openshift-helm-charts-vault:8200
.deployment-webapp-rhdp.ymlApply the webapp deployment.
Display all the pods within the vault namespace.
Wait until the
webapp
pod is running and ready (1/1
).This web application runs an HTTP service that listens on port 8080.
Perform a
curl
request athttp://localhost:8080
on thewebapp
pod.Output:
The web application running on port 8080 in the webapp pod:
- authenticates with the Kubernetes service account token
- receives a Vault token with the read capability at the
secret/data/webapp/config
path - retrieves the secrets from
secret/data/webapp/config
path - displays the secrets as JSON
Deployment: Secrets through Annotations
Applications on pods can remain Vault unaware if they provide deployment annotations that the Vault Agent Injector detects. This injector service leverages the Kubernetes mutating admission webhook to intercept pods that define specific annotations and inject a Vault Agent container to manage these secrets. An application needs:
- a service account
- a Vault secret
- a Vault policy to read the secret
- a Kubernetes authentication role
- a deployment with Vault Agent Injector annotations
Create the service account
Display the service account defined in
service-account-issues.yml
.This definition of the service account creates the account with the name
issues
.Apply the service account.
Get all the service accounts.
The
issues
service account is displayed.
Create the secret
Start an interactive shell session on the
openshift-helm-charts-vault-0
pod.Your system prompt is replaced with a new prompt
/ #
. Commands issued at this prompt are executed on theopenshift-helm-charts-vault-0
container.Create a secret at path
secret/issues/config
with ausername
andpassword
.Output:
Get the secret at path
secret/issues/config
.The secret with the username and password is displayed.
Define the read policy
Write out the policy named
issues
that enables theread
capability for secrets at pathsecret/data/issues/config
.Output:
The policy
issues
is used in the Kubernetes authentication role definition.
Create a Kubernetes authentication role
Create a Kubernetes authentication role, named
issues
, that connects the Kubernetes service account name andissues
policy.Output:
The role connects the Kubernetes service account,
issues
, the namespace,vault
, with the Vault policy,issues
. The tokens returned are valid for 24 hours.Exit the
openshift-helm-charts-vault-0
pod.
Deploy the application
Examine the issues deployment defined in
deployment-issues.yml
.The Vault Agent Injector service reads the metadata annotations prefixed with
vault.hashicorp.com
.agent-inject
enables the Vault Agent injector servicerole
is the Vault Kubernetes authentication roleagent-inject-secret-FILEPATH
prefixes the path of the file,issues-config.txt
written to the/vault/secrets
directory. The value is the path to the Vault secret.agent-inject-template-FILEPATH
formats the secret with a provided template.
deployment-issues.yamlApply the issues deployment.
Display all the pods within the vault namespace.
Display the logs of the
vault-agent
container in theissues
pod.Output:
Display the secret written to the
issues
container.Output:
The secrets are rendered in a PostgreSQL connection string is present on the container.
Conclusion
Congratulations on finishing the tutorial!
In this lesson, you learned how to:
- Access the RHDP system and log into the OpenShift cluster
- Verify Vault is running on the OpenShift cluster
- Enable and configure Kubernetes auth method
- Deploy a web application that reads secrets directly from Vault
- Leverage Vault Agent Injector to manage secrets while keeping the application Vault unaware
Next steps
Learn more about the Vault Helm chart by reading the documentation or exploring the project source code.
Additional suggested reading:
- The blog post announcing the Injecting Vault Secrets into Kubernetes Pods via a Sidecar
- Documentation for Vault Agent Injector service.
- Repo for vault-hello-world