All Projects → bloomberg → vault-auth-spire

bloomberg / vault-auth-spire

Licence: Apache-2.0 license
vault-auth-spire is an authentication plugin for Hashicorp Vault which allows logging into Vault using a Spire provided SVID.

Programming Languages

go
31211 projects - #10 most used programming language
Makefile
30231 projects

Projects that are alternatives of or similar to vault-auth-spire

spire-tpm-plugin
Provides agent and server plugins for SPIRE to allow TPM 2-based node attestation.
Stars: ✭ 45 (+21.62%)
Mutual labels:  spiffe, spire
kubernetes-flexvolume-vault-plugin
A kubernetes flexvolume plugin that injects vault tokens at pod creation
Stars: ✭ 16 (-56.76%)
Mutual labels:  vault
vault-monkey
Extract secrets from your vault in a multi-machine cluster environment.
Stars: ✭ 12 (-67.57%)
Mutual labels:  vault
ssh-crypt
🔒 Share AES-256 encrypted vault file with your teammates using only ssh authorized_keys!
Stars: ✭ 17 (-54.05%)
Mutual labels:  vault
casdoor-go-sdk
Go client SDK for Casdoor
Stars: ✭ 37 (+0%)
Mutual labels:  authn
vault-formula
docs.saltstack.com/en/latest/topics/development/conventions/formulas.html
Stars: ✭ 15 (-59.46%)
Mutual labels:  vault
vauth
VMware vSphere VM Identity Platform
Stars: ✭ 32 (-13.51%)
Mutual labels:  vault
vault-consul-docker
HashiCorp Vault with Consul backend in Docker
Stars: ✭ 20 (-45.95%)
Mutual labels:  vault
ghost
A simple, server/less, single-api, multi-backend, ghostly secret-store/key-store for your passwords, ssh-keys and cloud credentials. Ghost isn't real, it's just in your head.
Stars: ✭ 36 (-2.7%)
Mutual labels:  vault
obsidian-publish-mkdocs
A Template to Publish Obsidian/Foam Notes on Github Pages (uses MkDocs)
Stars: ✭ 219 (+491.89%)
Mutual labels:  vault
marathon-vault-plugin
Marathon plugin which injects Vault secrets via environment variables
Stars: ✭ 30 (-18.92%)
Mutual labels:  vault
stork
Retrieve tokens from Vault for your EC2 instances.
Stars: ✭ 12 (-67.57%)
Mutual labels:  vault
testing.cloudposse.co
Example Terraform Reference Architecture that implements a Geodesic Module for an Automated Testing Organization in AWS
Stars: ✭ 22 (-40.54%)
Mutual labels:  vault
vault
Vault - cross-platform GPG KV store for teams made easy
Stars: ✭ 35 (-5.41%)
Mutual labels:  vault
vault-consul-docker
Vault + Consul + Docker
Stars: ✭ 75 (+102.7%)
Mutual labels:  vault
hookpick
A tool to manage some operational concepts of Hashicorp Vault
Stars: ✭ 83 (+124.32%)
Mutual labels:  vault
vault-ec2auth
A simple agent to authenticate an AWS EC2 instance against Hashicorp Vault
Stars: ✭ 12 (-67.57%)
Mutual labels:  vault
vagrant-vault-consul-docker-monitoring
No description or website provided.
Stars: ✭ 20 (-45.95%)
Mutual labels:  vault
nomad-box
Nomad Box - Simple Terraform-powered setup to Azure of clustered Consul, Nomad and Traefik Load Balancer that runs Docker/GoLang/Java workloads. NOTE: Only suitable in dev environments at the moment until I learn more Terraform, Consul, Nomad, Vault :P
Stars: ✭ 18 (-51.35%)
Mutual labels:  vault
vaultssh
A Go based Vault client to support ssh sessions, remote commands and scp transfers all in memory
Stars: ✭ 25 (-32.43%)
Mutual labels:  vault

SPIRE Vault Authentication Plugin

SPIRE Vault Authentication Plugin is an authentication plugin for Hashicorp Vault which allows logging into Vault using a SPIRE provided SVID.

Menu

Rationale

This plugin exists to allow SPIRE authenticated workloads to authenticate with Vault using their SPIRE provided SVID, and then interact with Vault as they would if they authenticated with Vault via any other Vault supported authentication mechanism. The intention is to support the following login scenerio

$> vault write auth/spire/login jwt="<jwt svid>"
$> vault write auth/spire/login -client-cert=svid.0.pem  -client-key=svid.0.key" <-- TLS connection using X509-SVID

where the SVID contains a valid SpiffeID which is used to determine which policies to apply during the Vault session.

Currently the plugin is coded to accept X509-SVID documents via the non-TLS method but that is just for speed of development purposes - it will not be true in a released version. See #12 for a discussion on accepting X509-SVIDs.

During the login process the provided SVID will be verified against CA trust bundles known to the plugin. The SVID must have been generated using one of the known CA trust bundles. As per the rules in Spiffe regarding trust domains and bundles, each trust domain known to the plugin will use 1 or more public CAs to verify SVIDs generated in that domain. The vault-auth-spire plugin supports the configuration of multiple trust domains, each with 1 or more root or intermediate CAs used to verify the SVIDs. This use of 1 or more CAs allows the plugin to support CA rotation.

The plugin uses Trust Sources to manage from where it receives trusted CAs. There are two types of trust sources: read from file and pushed from SPIRE. The trust sources are configured in the plugin settings and will be used to acquire trust CAs. The plugin can simultaneously acquire trust CAs from file and SPIRE.

Trust Sources

A Trust Source provides a way for vault-auth-spire to acquire trust CAs. There are two types of trust sources: from file and SPIRE. Both types of trust sources can be used at the same time.

File Trust Source

When using a File Trust Source one needs to map a Trust Domain to one or more files containing the trusted CAs for that domain. This information is provided to the plugin via its settings file.

{
  "trustsource": {
    "file": {
      "domains": {
        "spiffe://some.domain.com": ["/path/to/ca/for/domain.crt", "/path/to/secondary/ca/for/domain.crt"],
        "spiffe://some.otherdomain.com": ["/path/to/ca/for/otherdomain.crt"]
      }
    }
  }
}

Each domain can be provided with one or more trusted CA files and each CA file can contain one or more actual certificates. The full set of certificates found across all files will be used to verify SVIDs claiming to be within the configured domain. This structure allows the plugin to fully support certificate rotation.

SPIRE Trust Source

This is still under development and some details are unknown at this time

When using the SPIRE Trust Source one needs to provide enough information for the plugin to connect to SPIRE and retreive its known trust CAs. The information is provided to the plugin via its settings file

{
  "trustsource": {
    "spire": ...unknown at the moment...
  }
}

Current ideas for this trust source include

  1. Support connecting to multiple SPIRE instances (agents or servers) to allow for broad authentication, particularly where different systems are using the same Vault instance.
  2. Support saving the SPIRE provided CAs to disk so they can be used if the plugin is unable to connect to a SPIRE instance. This will help limit the blast radius of a failing SPIRE connection.

Quick Start

Building

The plugin can be built using standard go commands or simply by using the provided Makefile.

$> make build
GOOS=linux GOARCH=amd64 go build -o vault-auth-spire cmd/plugin/vault-auth-spire.go

Installation

The plugin is installed and registered just like any other Vault plugin. It should be placed in the appropriate plugin directory and registered in the catalog. When registering the plugin it is necessary to provide the location of the plugin settings file.

$> vault write sys/plugins/catalog/auth/spire \
    sha_256="$(shasum -a 256 '/path/to/plugin/vault-auth-spire' | cut -d' ' -f1)" \
    command="vault-auth-spire" \
    args="--settings-file=/path/to/settings/vault-auth-spire-settings.json"

Before usage all plugins need to be enabled

$> vault auth enable \
    -path="spire" \
    -plugin-name="spire" plugin

Contributions

We ❤️ contributions.

Have you had a good experience with this project? Why not share some love and contribute code, or just let us know about any issues you had with it?

We welcome issue reports here; be sure to choose the proper issue template for your issue, so that we can be sure you're providing the necessary information.

Before sending a Pull Request, please make sure you read our Contribution Guidelines.

License

Please read the LICENSE file.

Code of Conduct

This project has adopted a Code of Conduct. If you have any concerns about the Code, or behavior which you have experienced in the project, please contact us at [email protected].

Security Vulnerability Reporting

If you believe you have identified a security vulnerability in this project, please send email to the project team at [email protected], detailing the suspected issue and any methods you've found to reproduce it.

Please do NOT open an issue in the GitHub repository, as we'd prefer to keep vulnerability reports private until we've had an opportunity to review and address them.

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].