azuresecrets

README

Vault Plugin: Azure Secrets Backend

This is a standalone backend plugin for use with Hashicorp Vault. This plugin generates revocable, time-limited Service Principals for Microsoft Azure.

Please note: We take Vault's security and our users' trust very seriously. If you believe you have found a security issue in Vault, please responsibly disclose by contacting us at security@hashicorp.com.

Quick Links

• Vault Website
• Azure Secrets Docs
• Vault Github Project

Getting Started

This is a Vault plugin and is meant to work with Vault. This guide assumes you have already installed Vault and have a basic understanding of how Vault works.

Otherwise, first read this guide on how to get started with Vault.

To learn specifically about how plugins work, see documentation on Vault plugins.

Usage

Please see documentation for the plugin on the Vault website.

This plugin is currently built into Vault and by default is accessed at azure. To enable this in a running Vault server:

$ vault secrets enable azure
Success! Enabled the azure secrets engine at: azure/

Developing

If you wish to work on this plugin, you'll first need Go installed on your machine (version 1.17+ is required).

For local dev first make sure Go is properly installed, including setting up a GOPATH. Next, clone this repository into $GOPATH/src/github.com/hashicorp/vault-plugin-secrets-azure. You can then download any required build tools by bootstrapping your environment:

$ make bootstrap

To compile a development version of this plugin, run make or make dev. This will put the plugin binary in the bin and $GOPATH/bin folders. dev mode will only generate the binary for your platform and is faster:

$ make
$ make dev

Put the plugin binary into a location of your choice. This directory will be specified as the plugin_directory in the Vault config used to start the server.

plugin_directory = "path/to/plugin/directory"

Start a Vault server with this config file:

$ vault server -config=path/to/config.json ...
...

Once the server is started, register the plugin in the Vault server's plugin catalog:

$ vault plugin register \
        -sha256=<SHA256 Hex value of the plugin binary> \
        -command="vault-plugin-secrets-azure" \
        secret \
        azure
...
Success! Data written to: sys/plugins/catalog/azure

Note you should generate a new sha256 checksum if you have made changes to the plugin. Example using openssl:

openssl dgst -sha256 $GOPATH/vault-plugin-secrets-azure
...
SHA256(.../go/bin/vault-plugin-secrets-azure)= 896c13c0f5305daed381952a128322e02bc28a57d0c862a78cbc2ea66e8c6fa1

Enable the plugin backend using the secrets enable plugin command:

$ vault secrets enable -plugin-name='azure' plugin
...

Successfully enabled 'plugin' at 'azure'!

Azure Environment Setup

A Terraform configuration is included in this repository that automates provisioning of Azure resources necessary to configure the secrets engine. By default, the resources are created in westus2. See variables.tf for the available variables.

Before applying the Terraform configuration, you'll need to:

1. Authenticate the Terraform provider to Azure

The Terraform configuration will create:

• An app registration with necessary API permissions
• A service principal with necessary role assignments

To provision the Azure resources, run the following:

$ make setup-env   

The local_environment_setup.sh file will be created in the bootstrap/terraform directory as a result of running make setup-env. This file contains environment variables needed to configure the secrets engine. The values can also be accessed via terraform output.

Once you're finished with plugin development, you can run the following to destroy the Azure resources:

$ make teardown-env   

Configure Plugin

A scripted configuration of the plugin is provided in this repository. You can use the script or manually configure the secrets engine using documentation.

To apply the scripted configuration, first source the environment variables generated by the Azure environment setup:

$ source ./bootstrap/terraform/local_environment_setup.sh

Next, run the make configure target to register, enable, and configure the plugin with your local Vault instance. You can specify the plugin name, plugin directory, and mount path. Default values from the Makefile will be used if arguments aren't provided.

$ PLUGIN_NAME=vault-plugin-secrets-azure \
  PLUGIN_DIR=$GOPATH/vault-plugins \
  PLUGIN_PATH=local-secrets-azure \
  make configure

Tests

If you are developing this plugin and want to verify it is still functioning (and you haven't broken anything else), we recommend running the tests.

To run the tests, invoke make test:

$ make test

You can also specify a TESTARGS variable to filter tests like so:

$ make test TESTARGS='--run=TestConfig'

Acceptance Tests

This repository contains acceptance tests that interact with real Azure resources. There are acceptance tests written in Go and bats.

Go

To run the Go acceptance tests, run the following:

$ make testacc 

Bats

Acceptance tests requires Azure access, and the following to be installed:

• Docker
• Azure CLI
• Terraform
• bats

You will need to be properly logged in to Azure with your subscription set. See 'Azure Provider: Authenticating using the Azure CLI' for more information.

$ make test-acceptance AZURE_TENANT_ID=<your_tenant_id>

Setting WITH_DEV_PLUGIN= will use the provided builtin plugin. The default behavior is to build and register the plugin from the working directory.

$ make test-acceptance AZURE_TENANT_ID=<your_tenant_id>

Running tests against Vault Enterprise requires a valid license, and specifying an enterprise docker image:

$ make test-acceptance AZURE_TENANT_ID=<your_tenant_id> \
  VAULT_LICENSE=........ \
  VAULT_IMAGE=hashicorp/vault-enterprise:latest

The test-acceptance make target also accepts the following environment based directives:

• TESTS_FILTER: a regex of Bats tests to run, useful when you only want to run a subset of the tests.

Documentation

Index

• Constants
• func Factory(ctx context.Context, conf *logical.BackendConfig) (logical.Backend, error)
• type AzureGroup
• type AzureProvider
• type AzureRole

Constants

const (
	SecretTypeSP       = "service_principal"
	SecretTypeStaticSP = "static_service_principal"
)

Functions

func Factory

func Factory(ctx context.Context, conf *logical.BackendConfig) (logical.Backend, error)

Types

type AzureGroup

type AzureGroup struct {
	GroupName string `json:"group_name"` // e.g. MyGroup
	ObjectID  string `json:"object_id"`  // e.g. 90820a30-352d-400f-89e5-2ca74ac14333
}

AzureGroup is an Azure Active Directory Group (https://docs.microsoft.com/en-us/azure/role-based-access-control/overview). GroupName and ObjectID are both traits of the group. ObjectID is the unique identifier, but GroupName is more useful to a human (though it is not unique).

type AzureProvider

type AzureProvider interface {
	api.ApplicationsClient
	api.GroupsClient
	api.ServicePrincipalClient

	CreateRoleAssignment(
		ctx context.Context,
		scope string,
		roleAssignmentName string,
		parameters armauthorization.RoleAssignmentCreateParameters) (armauthorization.RoleAssignmentsClientCreateResponse, error)
	DeleteRoleAssignmentByID(ctx context.Context, roleID string) (armauthorization.RoleAssignmentsClientDeleteByIDResponse, error)
	ListRoleDefinitions(ctx context.Context, scope string, filter string) (result []*armauthorization.RoleDefinition, err error)
	GetRoleDefinitionByID(ctx context.Context, roleID string) (result armauthorization.RoleDefinitionsClientGetByIDResponse, err error)
}

AzureProvider is an interface to access underlying Azure Client objects and supporting services. Where practical the original function signature is preserved. Client provides higher level operations atop AzureProvider.

type AzureRole

type AzureRole struct {
	RoleName string `json:"role_name"` // e.g. Owner
	RoleID   string `json:"role_id"`   // e.g. /subscriptions/e0a207b2-.../providers/Microsoft.Authorization/roleDefinitions/de139f84-...
	Scope    string `json:"scope"`     // e.g. /subscriptions/e0a207b2-...
}

AzureRole is an Azure Role (https://docs.microsoft.com/en-us/azure/role-based-access-control/overview) applied to a scope. RoleName and RoleID are both traits of the role. RoleID is the unique identifier, but RoleName is more useful to a human (thought it is not unique).