Hashicorp Vault Plugin for XL Release

[ Github All Releases ]()

Overview

The HashiCorp Vault plugin is an XL Release plugin to retrieve secrets from a Vault Server for use in your tasks and automations. These secrets include static and dynamic username and password fields from the Secrets Engine of your choice.

NOTE: This is community plugin is meant to prove the concept of using Vault with XL Release. As such, there are optimizations that should be made, which includes a reduction in the liberal logging that may include secrets. You are advised to look through the code and documentation for TODO and TBD comments of what should be evaluated.

Requirements

XL Release: version 9.5+
Plugin Testing requirements
- Gradle
- Docker
- XL CLI 9.5 or higher

Installation

This documentation assumes gradle 6.0.1. See gradle/wrappter/gradle-wrapper.properties for the actual version.

Import the jar file into your %XLRELEASE_INSTALLATION%/plugins/__local__ folder, or from the XL Release web UI as a new plugin. Adding the plugin requires a server restart.

Authentication

Vault permits several types of authentication as outlined in the Hashicorp Vault Authentication documentation. This plugin implements a subset of the authentication options, namely token. Others will should be added as demanded.

Define the server configuration of URL plus token.

Configuration

Secrets Engine V1

Secrets Engine V2

Dynamic Secrets

MySQL Secrets Engine

AWS Secrets Engine

Plugin build mechanics

Testing the plugin

It is convenient to test the plugin against local resources during active development. This section describes the process to start containers, configure the vault server, and run blueprints to test.

Starting the containers on Docker

Start your containers for XLR and Vault with the runDockerCompose gradle goal:

./gradlew runDockerCompose

Stop your test with the stopDockerCompose gradle goal:

./gradlew stopDockerCompose

These two URLs are defined by the contents in your src/test/resources/docker/docker-compose.yml file:

XLR: http://localhost:15516
Vault: http://localhost:15200

You may wish to follow the logs of the xlr container with the next command, as the default XLR container is named xlr:

docker logs -t -f xlr

The runDockerCompose assets are located in src/test/resources/docker primarily as the docker-compose.yml file.

Setting up Vault

Once your containers are running, you have to configure Vault. Assuming you persist your files to disk and do not delete the volume mount, you can restart your containers and use the previous keys and tokens.

Navigate to the Vault URL and configure your number of keys and how many are needed to unseal. We recommend 3 and 2, respectively. Save your keys and master token. You may also configure the Vault sever from the CLI (that is an exercise for the reader). If you preserve your directory structure, your keys and token values will persist on each runDockerCompose invocation, but you will have to unseal the server.

Once you setup Vault from the UI (or CLI), execute these commands to set up your initial secrets engines for testing. The secrets engine creation is a one-time process for each persisted run when you persist your volume mount.

We are creating secrets engines for tests with these names:

kv: A version 1 Secrets Engine
kv2: A version 2 Secrets Engine

vault login  s.ZT3LhH70qS2hOTjZ1w37TFxz # This value is specific to your instance
vault secrets enable -path=kv kv
vault secrets enable -version=2 -path=kv2 kv
vault secrets list

The commands above will configure secrets engines for the supplied XLR Template.

Update src/test/resources/ascode/xebialabs/secrets.xvals

Update your secrets to use the token in your XLR configuration from your vault server.

The vault token generated for your server (vault_Server_vault_test_token). This default value will not work until you update the token for your system
The name of a secret value for your testing (vault_CreateSecret_Create_Secret_value). The default is "test-password-123"
The XLR admin user password for scripts (xlrelease_Release_vault_test_scriptUserPassword). The default is "admin"

Testing with as-code

This repository includes "as-code" files to help you get started with a testing environment.

See the readme in the ascode folder for more details on the different models, but the punchline is to run this command:

xl apply --config blueprints.yaml -f xebialabs.yaml

The file blueprints.yaml contains a blueprints definition for the local XLR server so you don't have to modify your current configuration.

The imported template are at the Vault folder as "vault-test."

xebialabs-community / xlr-hashicorp-vault-plugin

readme