All Projects → oulman → tfvaultenv

oulman / tfvaultenv

Licence: Apache-2.0 license
A utility for configuring Terraform provider environment variables from HashiCorp Vault secrets

Programming Languages

go
31211 projects - #10 most used programming language

Projects that are alternatives of or similar to tfvaultenv

Ops Cli
Ops - cli wrapper for Terraform, Ansible, Helmfile and SSH for cloud automation
Stars: ✭ 152 (+230.43%)
Mutual labels:  vault
Operator
🔐 HashiCorp Vault Operator for Kubernetes
Stars: ✭ 178 (+286.96%)
Mutual labels:  vault
Vsh
vsh - HashiCorp Vault interactive shell and cli tool
Stars: ✭ 209 (+354.35%)
Mutual labels:  vault
Cault
docker compose for consul and vault official images
Stars: ✭ 157 (+241.3%)
Mutual labels:  vault
Oboe
🗄 A simple tool to convert an Obsidian vault into a static directory of HTML files.
Stars: ✭ 168 (+265.22%)
Mutual labels:  vault
Ansible Vault
🔑 Ansible role for Hashicorp Vault
Stars: ✭ 189 (+310.87%)
Mutual labels:  vault
Gradle Aem Plugin
Swiss army knife for Adobe Experience Manager related automation. Environment setup & incremental AEM application build which takes seconds, not minutes.
Stars: ✭ 145 (+215.22%)
Mutual labels:  vault
Vault Secrets Gen
A Vault secrets plugin for generating high entropy passwords and passphrases.
Stars: ✭ 238 (+417.39%)
Mutual labels:  vault
Helm Secrets
Successor of zendesk/helm-secrets - A helm plugin that help manage secrets with Git workflow and store them anywhere
Stars: ✭ 165 (+258.7%)
Mutual labels:  vault
K8s Gitops
GitOps principles to define kubernetes cluster state via code. Community around [email protected] is on discord: https://discord.gg/7PbmHRK
Stars: ✭ 192 (+317.39%)
Mutual labels:  vault
Vault Ethereum
A plugin that turns Vault into an Ethereum wallet.
Stars: ✭ 159 (+245.65%)
Mutual labels:  vault
Awesome Vault Tools
Awesome tools around HashiCorp Vault
Stars: ✭ 167 (+263.04%)
Mutual labels:  vault
Goldfish
A HashiCorp Vault UI written with VueJS and Vault native Go API
Stars: ✭ 2,174 (+4626.09%)
Mutual labels:  vault
Hashi Helper
Disaster Recovery and Configuration Management for Consul and Vault
Stars: ✭ 155 (+236.96%)
Mutual labels:  vault
Spring Cloud Vault
Configuration Integration with HashiCorp Vault
Stars: ✭ 210 (+356.52%)
Mutual labels:  vault
Vault Kubernetes Workshop
Steps and scripts for running @HashiCorp Vault on @GoogleCloudPlatform Kubernetes
Stars: ✭ 147 (+219.57%)
Mutual labels:  vault
Spring Vault
Provides familiar Spring abstractions for HashiCorp Vault
Stars: ✭ 179 (+289.13%)
Mutual labels:  vault
Terraform Provider Vault
Terraform Vault provider
Stars: ✭ 244 (+430.43%)
Mutual labels:  vault
Serverless Vault With Cloud Run
Guide to running Vault on Cloud Run
Stars: ✭ 225 (+389.13%)
Mutual labels:  vault
Hashicorp Vault Plugin
Jenkins plugin to populate environment variables from secrets stored in HashiCorp's Vault.
Stars: ✭ 191 (+315.22%)
Mutual labels:  vault

tfvaultenv

Overview

tfvaultenv reads secrets from HashiCorp Vault and outputs environment variables for various Terraform providers with those secrets.

This project is a work in progress and additional Secrets Engines, Providers, and features are planned. Please see the project roadmap for more details.

Currently supported are:

Secrets Engines

Terraform Providers

Installation

  • Download the release for your platform from Releases
  • untar or unzip the file and move tfvaultenv into your $PATH
  • Create a .tfvaultenv.config.hcl file in your Terraform project. (see Configuration below and the examples directory)

Configuration

The configuration is written in HCL and the default name is .tfvaultenv.config.hcl. Unless overridden, tfvaultenv will look in the current working directory for the config file. You can optionally set the --config and --configdepth arguments to change the config file name or search up to N parent directories. This is useful in nested Terraform directory structure scenarios.

Configuration is set in blocks representing supported secrets engines and authentication methods.

Secrets Engines

Currently all secrets engines use the same Vault client and because of that tfvaultenv only supports a single Vault backend configured via VAULT_ADDR environment variables. A feature is planned to be able to support multiple Vault backends and Namespaces.

AWS

Example
aws "sts" {
   method = "assumed_role"
   role = "rolename"
   role_arn = "arn:aws:iam::00000000000:role/TerraformRole"
   extra_env_vars = {
       "AWS_DEFAULT_REGION" = "us-east-2"
   }
   ttl = 900
}
Arguments
  • method: (Required) Name of the AWS Secrets Engine Method Currently only assumed_role is supported
  • role: (Required) AWS Secrets Engine role name
  • role_arn: (Optional) Role ARN to assume when method is set to assumed_role
  • extra_env_vars: (Optional) Map of additional environment variables to set
  • mount: (Optional) Path to the mounted AWS secrets engine. Default: aws
  • ttl: (Optional) TTL to set on the token or iam_user

Azure

Example
azure "sub1" {
   role = "sub1-rw"
   extra_env_vars = {
       "ARM_TENANT_ID" = "194dd302-295b-4993-b29e-2ca2d37b9031"
       "ARM_SUBSCRIPTION_ID" = "9b9c4322-74a2-474e-ad94-c5e6890713c9"
   }
}
Arguments
  • role: (Required) Azure Secrets Engine role name
  • extra_env_vars: (Optional) Map of additional environment variables to set
  • mount: (Optional) Path to the mounted Azure secrets engine. Default: azure

Active Directory

Example
ad "vsphere" {
   role = "rolename"
   target_provider = "vsphere"
   extra_env_vars = {
       "VSPHERE_SERVER" = "vcenter.example.com"
   }
}
ad "generic" {
   role = "tf-svc"
   target_provider = "generic"
   username_env_var = "TF_VAR_AD_USERNAME"
   password_env_var = "TF_VAR_AD_PASSWORD"
}
Arguments
  • role: (Required) Name of the Vault Active Directory Secrets Engine role name
  • target_provider: (Required) Name of the Terraform provider to generate environment variables for
  • extra_env_vars: (Optional) Map of additional environment variables to set
  • username_env_var: (Optional/Required for generic provider) Environment variable to set to username
  • password_env_var: (Optional/Required for generic provider) Environment variable to set to password
  • path: (Optional) Path to the mounted AD secrets engine. Default: ad

Kv2 Secret

Example
kv_secret "infoblox" {
   path = "infoblox/terraform"
   target_provider = "infoblox"
   attribute_map = {
       "ib_user"     = "username"
       "ib_password" = "password"
   }
   extra_env_vars = {
       "FOO" = "bar"
   }
}
Arguments
  • path: (Required) Path to the secret under the secrets engine mount
  • mount: (Optional) Mount name of the secrets engine. Default: "secrets"
  • attribute_map: (Optional) Map of kv2 secret attribute names to provider values. Defaults to username and password
  • target_provider: (Required) Name of the Terraform provider to generate environment variables for
  • extra_env_vars: (Optional) Map of additional environment variables to set
  • expand_env_vars: (Optional) Perform shell expansion of variables in the string. This only applies to values in extra_env_vars

Kv2 Secret (Generic)

You can use the "generic" target_provider when tfvaultenv doesnt directly support your Terraform provider.

Example
kv_secret "generic" {
   path = "teams/ops/db/pgsql"
   target_provider = "generic"
   attribute_map = {
       "PGUSER" = "psql_user"
       "PGPASSWORD" = "psql_pass"
   }
   extra_env_vars = {
       "PGHOST" = "foo.bar.com"
       "PGPORT" = "12345"
   } 
}
Arguments
  • path: (Required) Path to the secret under the secrets engine mount
  • mount: (Optional) Mount name of the secrets engine. Default: "secrets"
  • attribute_map: (Optional) Map of kv2 secret attribute names to environment vasriable keys.
  • target_provider: (Required) generic
  • extra_env_vars: (Optional) Map of additional environment variables to set
  • expand_env_vars: (Optional) Perform shell expansion of variables in the string. This only applies to values in extra_env_vars

Auth Methods

By default tfvaultenv creates an implicit auth method that supports token based authentication in the form of VAULT_TOKEN, ~/.vault-token, and token helpers. Supported auth methods such as JWT (see below) can be used and can override token auth by configuring a priority of 1 or above. Auth methods can be conditionally activated using when {} blocks based on environment variables or other supported conditions. When multiple auth methods are defined you can specify priorities to ensure that the preferred fallback auth method is used.

Common arguments

  • method: (Required) Name of the Vault authentication method
  • path: (Required) Path to the auth engine mount
  • priority: (Required) Priority - set > 0 to override implicit token based auth
  • when: (Optional) Conditional block methods to determine if the auth method should be used. Currently only env_present is supported.
  • export_vault_token: (Optional) Print the token to the VAULT_TOKEN environment variable.

JWT

auth "gitlab" {
  method = "jwt"
  path = "gitlab"
  priority = 100

  jwt {
    role = env("VAULT_ROLE")
    token = env("CI_JOB_JWT")
  }

  when {
    env_present = "CI_JOB_JWT"
  }
}
Arguments
  • role: (Required) Name of the JWT auth engine role
  • token: (Required) JWT token to pass to Vault API

Usage

Setting environment variables

$ export `tfvaultenv get`
$ env | grep AWS_
AWS_ACCESS_KEY_ID=ASIA<SNIP>
AWS_ACCESS_SECRET_KEY=nJJFD/<SNIP>
AWS_ACCESS_SESSION_TOKEN=<SNIP>

Printing to stdout

$ tfvaultenv get
AWS_ACCESS_KEY_ID=ASIA<SNIP>
AWS_ACCESS_SECRET_KEY=nJJFD/<SNIP>
AWS_ACCESS_SESSION_TOKEN=<SNIP>

Specifying an alternate configuration file

$ tfvaultenv get --config /path/to/config.hcl
Note that the project description data, including the texts, logos, images, and/or trademarks, for each open source project belongs to its rightful owner. If you wish to add or remove any projects, please contact us at [email protected].