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 firstname.lastname@example.org.
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.
Please see documentation for the plugin on the Vault website.
This plugin is currently built into Vault and by default is accessed
azure. To enable this in a running Vault server:
$ vault secrets enable azure Success! Enabled the azure secrets engine at: azure/
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
You can then download any required build tools by bootstrapping your
$ make bootstrap
To compile a development version of this plugin, run
This will put the plugin binary in the
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
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 write sys/plugins/catalog/azure \ sha256=<expected SHA256 Hex value of the plugin binary> \ command="vault-plugin-secrets-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 auth plugin backend using the secrets enable plugin command:
$ vault secrets enable -plugin-name='azure' plugin ... Successfully enabled 'plugin' at 'azure'!
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
You can also specify a
TESTARGS variable to filter tests like so:
$ make test TESTARGS='--run=TestConfig'
Acceptance tests requires Azure access, and the following to be installed:
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>
WITH_DEV_PLUGIN=1 will first build the local plugin, and automatically register
it with the test Vault instance.
$ make test-acceptance AZURE_TENANT_ID=<your_tenant_id> WITH_DEV_PLUGIN=1
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
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.
const ( SecretTypeSP = "service_principal" SecretTypeStaticSP = "static_service_principal" )
This section is empty.
type AzureGroup ¶ added in v0.5.2
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).
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).