• HashiCorp Developer

  • HashiCorp Cloud Platform
  • Terraform
  • Packer
  • Consul
  • Vault
  • Boundary
  • Nomad
  • Waypoint
  • Vagrant
Consul
  • Install
  • Tutorials
  • Documentation
  • API
  • CLI
  • Try Cloud(opens in new tab)
  • Sign up
Consul Home

Documentation

Skip to main contentOverview
  • What is Consul?



    • Overview
    • Architecture
      • Consul Clients Outside Kubernetes
      • Consul Servers Outside Kubernetes
      • Single Consul Datacenter in Multiple Kubernetes Clusters
      • Consul Enterprise
        • Overview
        • Systems Integration
          • Overview
          • Bootstrap Token
          • Enterprise License
          • Gossip Encryption Key
          • Partition Token
          • Replication Token
          • Server TLS
          • Service Mesh Certificates
          • Snapshot Agent Config
          • Webhook Certificates
        • WAN Federation
    • Service Sync
    • Annotations and Labels
    • Consul DNS
    • Compatibility Matrix
    • Helm Chart Configuration
    • Consul K8s CLI Reference

  • HCP Consul


  • Resources

  • Tutorial Library
  • Certifications
  • Community Forum
    (opens in new tab)
  • Support
    (opens in new tab)
  • GitHub
    (opens in new tab)
  1. Developer
  2. Consul
  3. Documentation
  4. Kubernetes
  5. Deployment Configurations
  6. Vault as Secrets Backend
  7. Data Integration
  • Consul
  • v1.13.x
  • v1.12.x
  • v1.11.x
  • v1.10.x
  • v1.9.x
  • v1.8.x

»Vault as the Secrets Backend - Data Integration

This topic describes how to configure Vault and Consul in order to share secrets for use within Consul.

Prerequisites

Before you set up the data integration between Vault and Consul on Kubernetes, read and complete the steps in the Systems Integration section of Vault as a Secrets Backend.

General integration steps

For each secret you want to store in Vault, you must complete two multi-step procedures.

Complete the following steps once:

  1. Store the secret in Vault.
  2. Create a Vault policy that authorizes the desired level of access to the secret.

Repeat the following steps for each datacenter in the cluster:

  1. Create Vault Kubernetes auth roles that link the policy to each Consul on Kubernetes service account that requires access.
  2. Update the Consul on Kubernetes Helm chart.

Secrets-to-service account mapping

At the most basic level, the goal of this configuration is to authorize a Consul on Kubernetes service account to access a secret in Vault.

The following table associates Vault secrets and the Consul on Kubernetes service accounts that require access. (NOTE: Consul components refers to all other services and jobs that are not Consul servers or clients. It includes things like terminating gateways, ingress gateways, etc.)

Primary datacenter

SecretService Account ForConfigurable Role in Consul k8s Helm
ACL Bootstrap tokenConsul server-acl-init jobglobal.secretsBackend.vault.manageSystemACLsRole
ACL Partition tokenConsul server-acl-init jobglobal.secretsBackend.vault.manageSystemACLsRole
ACL Replication tokenConsul server-acl-init jobglobal.secretsBackend.vault.manageSystemACLsRole
Enterprise licenseConsul servers
Consul clients
global.secretsBackend.vault.consulServerRole
global.secretsBackend.vault.consulClientRole
Gossip encryption keyConsul servers
Consul clients
global.secretsBackend.vault.consulServerRole
global.secretsBackend.vault.consulClientRole
Snapshot Agent configConsul serversglobal.secretsBackend.vault.consulServerRole
Server TLS credentialsConsul servers
Consul clients
Consul components
global.secretsBackend.vault.consulServerRole
global.secretsBackend.vault.consulClientRole
global.secretsBackend.vault.consulCARole
Service Mesh and Consul client TLS credentialsConsul serversglobal.secretsBackend.vault.consulServerRole
Webhook TLS certificates for controller and connect injectConsul controllers
Consul connect inject
global.secretsBackend.vault.controllerRole
global.secretsBackend.vault.connectInjectRole

Secondary datacenters

The mapping for secondary data centers is similar with the following differences:

  • There is no use of bootstrap token because ACLs would have been bootstrapped in the primary datacenter.
  • ACL Partition token is mapped to both the server-acl-init job and the partition-init job service accounts.
  • ACL Replication token is mapped to both the server-acl-init job and Consul service accounts.
SecretService Account ForConfigurable Role in Consul k8s Helm
ACL Partition tokenConsul server-acl-init job
Consul partition-init job
global.secretsBackend.vault.manageSystemACLsRole
global.secretsBackend.vault.adminPartitionsRole
ACL Replication tokenConsul server-acl-init job
Consul servers
global.secretsBackend.vault.manageSystemACLsRole
global.secretsBackend.vault.consulServerRole
Enterprise licenseConsul servers
Consul clients
global.secretsBackend.vault.consulServerRole
global.secretsBackend.vault.consulClientRole
Gossip encryption keyConsul servers
Consul clients
global.secretsBackend.vault.consulServerRole
global.secretsBackend.vault.consulClientRole
Snapshot Agent configConsul serversglobal.secretsBackend.vault.consulServerRole
Server TLS credentialsConsul servers
Consul clients
Consul components
global.secretsBackend.vault.consulServerRole
global.secretsBackend.vault.consulClientRole
global.secretsBackend.vault.consulCARole
Service Mesh and Consul client TLS credentialsConsul serversglobal.secretsBackend.vault.consulServerRole
Webhook TLS certificates for controller and connect injectConsul controllers
Consul connect inject
global.secretsBackend.vault.controllerRole
global.secretsBackend.vault.connectInjectRole

Combining policies within roles

Depending upon your needs, a Consul on Kubernetes service account may need to request more than one secret. To request multiple secrets, create one role for the Consul on Kubernetes service account that is mapped to multiple policies associated with the required secrets.

For example, if your Consul on Kubernetes servers need access to Consul Server TLS credentials and an Enterprise license:

  1. Create a policy for each secret.

    1. Consul Server TLS credentials

      ca-policy.hcl
      path "pki/cert/ca" {
        capabilities = ["read"]
      }
      
      $ vault policy write ca-policy ca-policy.hcl
      
    2. Enterprise License

      license-policy.hcl
      path "secret/data/consul/license" {
        capabilities = ["read"]
      }
      
      $ vault policy write license-policy license-policy.hcl
      
  2. Create one role that maps the Consul on Kubernetes service account to the 3 policies.

    $ vault write auth/kubernetes/role/consul-server \
        bound_service_account_names=<Consul server service account> \
        bound_service_account_namespaces=<Consul installation namespace> \
        policies=ca-policy,license-policy \
        ttl=1h
    

Detailed data integration guides

The following secrets can be stored in Vault KV secrets engine, which is meant to handle arbitrary secrets:

  • ACL Bootstrap token
  • ACL Partition token
  • ACL Replication token
  • Enterprise license
  • Gossip encryption key
  • Snapshot Agent config

The following TLS certificates and keys can generated and managed by Vault the Vault PKI Engine, which is meant to handle things like certificate expiration and rotation:

  • Server TLS credentials
  • Service Mesh and Consul client TLS credentials
  • Vault as the Webhook Certificate Provider for Consul Controller and Connect Inject on Kubernetes

Secrets-to-service account mapping

Read through the detailed data integration guides that are pertinent to your environment.

Edit this page on GitHub

On this page

  1. Vault as the Secrets Backend - Data Integration
  2. Prerequisites
  3. General integration steps
  4. Secrets-to-service account mapping
  5. Detailed data integration guides
  6. Secrets-to-service account mapping
Give Feedback(opens in new tab)
  • Certifications
  • System Status
  • Terms of Use
  • Security
  • Privacy
  • Trademark Policy
  • Trade Controls
  • Give Feedback(opens in new tab)