Hashicorp Vault - ghdrako/doc_snipets GitHub Wiki

Java driver

Core components of Vault are:

  1. Storage Backends (which holds all the hashed secrets. Note: Hashicorp Consul is Hashicorp’s supported Storage Backend which has got HA solution)
  2. Secret Engines (Few commonly used secret engines are Key/Value (KV), PKI Certificates, SSH Keys, Active Directory)
  3. Authentication Methods (Few commonly used Auth Methods are userpass (username/password), github (github tokens), Token, LDAP, Okta, K8s)
  4. Audit Devices (Types of Audit devices are File, Syslog, Sockets. Please note when auditing is enabled, Vault requires at least one audit device to write the logs, otherwise Vault will not process any of its request.)

Notes

vault read auth/token/lookup-self -field=policies  # listuje polisy ktore posiadasz
vault list secrets/<path>/
Zwroci Error listing  Cod 404 - jak nie ma wsciezce zadnego sekretu mimo ze do sciezki mam uprawnienia. W GUI nie pokazuje takiej sciezki tez.

SHow user politics

vault read auth/token/lookup-self -field=policies

Namespace

Mozna podac -ns=<namespace> przy kazdym poleceniu lub zmienia srodowiskowa VAULT_NAMESPACE=<namespace> i dla calej sesji bedzie

vault login -method=ldap -ns=<namespace> username=<uname>  # logujac sie ldapem generuje sie token waazny 30 dni - mozna go uzyc do logowania
vault login token=<token>
vault kv put -ns <namespace> <path to secret> @plik.json

Create path

export VAULT_CERT=/opt/vault/TLS/ca.pem
export VAULT_ADDR='https://<ip>:8200
export PATH=$PATH:/usr/local/bin

vault login -method=userpass username=<user>

# add secrets from command line
vault write /secrets/<path> <key1>=<value1> 
                            <key2>=<value2>

# add secrets from json file:
Vault kv put  <path to secret> @plik.json

cat data.json
{
"key1":"value1",
"key2":"value2"
}

$ echo $MY_TOKEN | vault write consul/config/access token=-

vault kv list sectets/<path>
vault read /secrets/<path>
vault kv get <path to secret> 

# need admin rights
vault read auth/ldap/groups/test_acp_ad

vault read auth/token/lookup-self -field=policies


https://<ivault ip or url>:8200  logowanie ldap

Authorisation auth methods

vault auth enable userpass
  • GitHub auth method
vault login -method=github token=<token>

An "AppRole" represents a set of Vault policies and login constraints that must be met to receive a token with those policies. The scope can be as narrow or broad as desired. An AppRole can be created for a particular machine, or even a particular user on that machine, or a service spread across machines. The credentials required for successful login depend upon the constraints set on the AppRole associated with the credentials.

vault write auth/approle/login \    
role_id=db02de05-fa39-4855-059b-67221c5c2f63 \    
secret_id=6a174c20-f6de-a53c-74d2-6018fcceff64

The default path is /approle. The default endpoint is auth/approle/login.

$ curl \    --request POST \    
--data '{"role_id":"988a9df-...","secret_id":"37b74931..."}' \    
http://127.0.0.1:8200/v1/auth/approle/login

The response will contain the token at auth.client_token.

Tokens

Tokens can be used directly or auth methods can be used to dynamically generate tokens based on external identities.

Token Types

  • service tokens and
  • batch tokens

App Role https://www.vaultproject.io/docs/auth/approle

An "AppRole" represents a set of Vault policies and login constraints that must be met to receive a token with those policies. The credentials required for successful login depend upon the constraints set on the AppRole associated with the credentials.

Approle - represent endpoint in valut secret path, from which we can get role_id and generate secret_id

Joining two information role_id and secret_id we can get generatated token (with ttl). This token is using to access application secrets

A common solution, to deliver those values to the client securely, involves three personas instead of two:

  • admin,
  • app, and
  • trusted entity. The trusted entity delivers the RoleID and SecretID to the client by separate means.

Example

auth/<approle_name>    - endpoint path - login endpoint

# loging to approle using role_id and secret_id 
vault write auth/approle/login \
    role_id=db02de05-fa39-4855-059b-67221c5c2f63 \
    secret_id=6a174c20-f6de-a53c-74d2-6018fcceff64

# as output we get token 
Key                Value
---                -----
token              65b74ffd-842c-fd43-1386-f7d7006e520a
token_accessor     3c29bc22-5c72-11a6-f778-2bc8f48cea0e
token_duration     20m0s
token_renewable    true
token_policies     [default]

Register an approle auth backend using a self-chosen name (e.g. Jenkins). This approle is identified by a role-id and secured with a secret_id. If you have both of those values you can ask Vault for a token that can be used to access vault. When registering the approle backend you can set a couple of different parameters:

  • How long should the secret_id live (can be indefinite)
  • how often can one use a token that is obtained via this backend
  • which IP addresses can obtain a token using role-id and secret-id?

Take token to authenticate in Vault

$ vault write auth/approle/login \
    role_id=db02de05-fa39-4855-059b-67221c5c2f63 \
    secret_id=6a174c20-f6de-a53c-74d2-6018fcceff64

Key                Value
---                -----
token              65b74ffd-842c-fd43-1386-f7d7006e520a
token_accessor     3c29bc22-5c72-11a6-f778-2bc8f48cea0e
token_duration     20m0s
token_renewable    true
token_policies     [default]

curl \
    --request POST \
    --data '{"role_id":"988a9df-...","secret_id":"37b74931..."}' \
    http://127.0.0.1:8200/v1/auth/approle/login
{
  "auth": {
    "renewable": true,
    "lease_duration": 2764800,
    "metadata": {},
    "policies": ["default", "dev-policy", "test-policy"],
    "accessor": "5d7fb475-07cb-4060-c2de-1ca3fcbf0c56",
    "client_token": "98a4c7ab-b1fe-361b-ba0b-e307aacfd587"
  }
}

Using AppRole

https://www.vaultproject.io/docs/auth/approle

  1. Enable AppRole auth method
$ vault auth enable approle
  1. Create role
  • First, create a policy named jenkins with following definition.
# Read-only permission on secrets stored at 'secret/data/mysql/webapp'
path "secret/data/mysql/webapp" {
  capabilities = [ "read" ]
}


vault policy write jenkins -<<EOF
# Read-only permission on secrets stored at 'secret/data/mysql/webapp'
path "secret/data/mysql/webapp" {
  capabilities = [ "read" ]
}
EOF
  • Creates a approle named jenkins with jenkins policy attached. The generated token's time-to-live (TTL) is set to 1 hour and can be renewed for up to 4 hours of its first creation
$ vault write auth/approle/role/jenkins token_policies="jenkins" \
    token_ttl=1h \ 
    token_max_ttl=4h

$ vault write auth/approle/role/my-role \
    secret_id_ttl=10m \
    token_num_uses=10 \
    token_ttl=20m \
    token_max_ttl=30m \
    secret_id_num_uses=40


vault write auth/approle/role/<ROLE_NAME> [parameters]

To attach multiple policies, pass the policy names as a comma separated string: token_policies="jenkins,anotherpolicy"

  1. Read role_id
$ vault read auth/approle/role/jenkins               # read role
$ vault read auth/approle/role/jenkins/role-id
$ vault read auth/approle/role/my-role/role-id       # Get a RoleID of the AppRole -wyswietli cos typu "675a50e7-cfe0-be76-e35f-49ec009731ea"
  1. Generate secret_id
$ vault write -force auth/approle/role/jenkins/secret-id
$ vault write -f auth/approle/role/my-role/secret-id # Get a SecretID of the AppRole - w odpowiedzi vault wyswietli secret-id typu "ed0a642f-2acf-c2da-232f-1b21300d5f29"
  1. login, use the auth/approle/login endpoint by passing the RoleID and SecretID.
$ vault write auth/approle/login role_id="675a50e7-cfe0-be76-e35f-49ec009731ea" \
    secret_id="ed0a642f-2acf-c2da-232f-1b21300d5f29"

Vault returns a client token with default and jenkins policies attached.

Store the generated token value in an environment variable named, APP_TOKEN.

Example:

$ export APP_TOKEN="s.ncEw5bAZJqvGJgl8pBDM0C5h"
  1. Read secrets using the AppRole token
$ VAULT_TOKEN=$APP_TOKEN vault kv get secret/mysql/webapp
# licznik uzyc secret_id - moze byc np 1 i nie da sie uzyc kolejny raz
$role_id=$(vault read auth/approle/role/<approle name>/role-id)
$secret_id=$(vault write -force auth/approle/role/<approle name>/secret-id)
vault write auth/approle/login role_id="$role_id" secret_id="$secret_id"

Lita przypisanych polityk do usera/approli

vault read auth/token/lookup-self -field=policies

HCL

W przypadku Vaulta język HCL wykorzystywany jest do opisu polityk ACL (ACL policies). Przy pomocy tych polityk opisywane są ścieżki oraz prawa do tych ścieżek.Przedstawiona przykładowa polityka definiuje prawa (capabilities) do tworzenia, odczytywania, aktualizacji, kasowania i listowania sekretów w ścieżce secrets/prod/app/newapp/* oraz listowania zawartości ścieżki secrets/prod/app/newapp2:

path "secrets/prod/app/newapp/*" {  
capabilities = ["create", "read", "update", "delete", "list"]
}
path "secrets/prod/app/newapp2/" {  
capabilities = ["list"]
}
--

Powyższa polityka daje również prawa do tworzenia podścieżek w ścieżce secrets/prod/app/newapp/ . Jak widać należy wyspecyfikować każdą ścieżkę z osobna. W tabeli zestawiono mapowanie praw do odpowiadających im wywołań http.

Capability Associated HTTP verbs
create POST/PUT
read GET
update POST/PUT
delete DELETE
list LIST

Szczegółowe omówienie każdego z praw znajduje się policies, a szczegółowe omówienie składni polityk policy-syntax.

vault read auth/approle_path/role/approle_name/role-id
vault read auth/approle/role/<nazwa_roli>/role-id # wyswietlenie role-id
vault write -force auth/approle/role/<nazwa_roli>/secret-id # generuje token secret id
vault write auth/approle/login role_id="" secret_id=""  # logujemy sie role-id i secret-id z poprzednich uprawnien

VAULT_SKIP_VERIFY=TRUE
-tls-skip-verify

https://github.com/hashicorp/vault/issues/14316

Install and start Vault

vault status -tls-skip-verify # Displays the details about your Vault cluster
# initialize a vault 
vault operator init
vault operator init -key-shares=3 -key-threshold=2 # initialize Vault server with 3 unseal keys out of which 2 should be used to unseal the vault.
# unseal 
vault operator unseal <unseal key> -tls-skip-verify
vault operator seal -tls-skip-verify
# login
vault auth list -tls-skip-verify # lists the various auth methods enabled in the vault server/cluster
vault auth enable -tls-skip-verify userpass # enable userpass as the authentication method
vault auth enable -tls-skip-verify kubernetes # enable K8s as the authentication method
vault login # login into Vault using root token, which is the default option
vault login -method=userpass username=my-username
vault login -method=github -path=github-prod
# Renew Token
vault token renew <Token>
# Policy
vault policy list -tls-skip-verify # list all policies created in the existing vault cluster
vault policy read -tls-skip-verify <policy_name> # show the details of policy
vault token create -policy=<existing_policy_name> -tls-skip-verify # create a new token with permission assigned as in the policy associated
vault policy write -tls-skip-verify <policy_name> <policy-file.hcl> # create a new policy with required capabilities against required secret paths
vault write -tls-skip-verify auth/github/map/teams/<github_team_name> value=<policy_name> # Map the users/teams of that GitHub organization to policies in Vault
# Secrets
vault kv get <Path to the secret> # print the key/value details stored in the given path if you have proper rights
vault kv get -tls-skip-verify — field=value secret/test/test # print the value of the mentioned key alone in the mentioned key path
vault kv put secret/test/test key=value # add a new kv pair in the existing path
vault kv put -tls-skip-verify -mount=secret hello foo=world excited=yes
vault kv put -tls-skip-verify -mount=secret /ala/hello foo=world excited=yes 
==== Secret Path ====
secret/data/ala/hello
vault kv get -tls-skip-verify -mount=secret hello
vault kv enable-versioning <Path to the secret> # enable versioning of the K=V stored in the given path
vault kv put <Path to the secret> same_key=new_vaule # add a new value for the existing key
vault kv get -version=<version_number> <Path to the secret>
vault kv delete secret/creds # Delete the latest version of the key “creds”
vault kv delete -versions=2 secret/creds # To [K/V Version 2] Delete version 2 of key “creds”
# Audit
vault audit list # List all audit devices enabled in your vault server
vault audit enable file file_path=/tmp/my-file.txt #To Enable the audit device “file” enabled at “file/”
vault secrets enable <aws/azure/mongodbatlas/gcp>
vault secrets enable database

Secret engine

GCP

Databases

Integration with db (postgres)

Kubernetes auth method

Recomended Patterns

https://developer.hashicorp.com/vault/tutorials/recommended-patterns/pattern-approle?in=vault%2Frecommended-patterns#approle-in-a-ci-pipeline-with-wrapped-secretids

⚠️ **GitHub.com Fallback** ⚠️