Machine-to-Machine authentications:
- TLS
- AppRole
- Cloud Based
- Tokens
- Kubernetes
- Radios
Human Auth methods:
- OKTA
- LDAP
- Userpass
- Github
- OICD
Since tokens are the default auth method in Vault and cannot be disabled
The AWS auth method provides an automated mechanism to retrieve a Vault Token for IAM principals and AWS EC2 instances. It does not require manual first deploying or provisioning security sensitive credentials by operator under many circunstances
All auth methods have the auth/<TYPE> mountpoint. Eg: auth/userpass.
When an auth method is disabled, all users authenticated via that method are automatically logged out.
- From 200 questions:
" How do you configure GitHub engineering team authentication to be granted the default and application policies?
vault write auth/github/map/teams/emgineering value=default,applications"
This policy allows a user to generate dynamic credentials on database
path "database/creds/read_only_role"{
capabilities = ["read"]
}deny capabilitie takes precedence over an allow policy and is the default policy.
Backend functions are available in /sys path.
In a policy, allowed_parameters can limitate the parameters that are accepted in a engine. Also, you can determine the required parameters with required_parameters attribute and probit parameters with denied_parameters
Vault always initialize with two policies:
- default
- root
To create a token without the default policy:
vault token create -no-default-policy
Policy with a list capabilitie must end with a slash.
The sudo capability allows access to paths that are root-protected
200 Questions
39. You have a requirement to enable and manage authentication methods broadly across vault. How do you define the policy?
# Manage auth methods broadly across Vault
path "auth/*"
{
capabilities = ["create", "read", "update", "delete", "list", "sudo"]
}
40. You have a requirement to create, update, and delete auth methods. How do you define the policy?
# Create, update, and delete auth methods
path "sys/auth/*"
{
capabilities = ["create", "update", "delete", "sudo"]
}
This command create a token with the policy "pol" and with a use limit of 10 times.
vault token create -policy=pol -use-limit=10
vault token lookup s.nNeZ6nayuFPACxuO7dqQEJGPrO
Key Value
--- -----
accessor mfvaVMFcTvHYTeqlRvadSOn
creation_time 1604610457
creation_ttl 768h
display_name token
entity_id n/a
expire_time 2021-09-26T18:51:37.4126772-05:00
explicit_max_ttl 0s
id s.nNeZ6nayuFPACxuO7dqQEJGPrO
issue_time 2021-09-26T18:51:37.4126772-05:00
meta <nil>
num_uses 10
orphan false
path auth/token/create
policies [default pol]
renewable true
ttl 767h59m59s
type service
In periodic tokens the period is explicit on token lookup
Batch Tokens:
- Are lightweight and scalable
- have no storage cost for token creating
- Are used for ephemeral, high-performance workloads
- Can be used to encrypting data
- Require no storage on disk to track
- Are not renewable
- Cant be root or create new tokens
Service Tokens
Are the most commum Vault tokens, they support all features and are more expensive than batch tokens to create and track.
To renew a token is necessary: token id or token accessor;
Child tokens are revoked when their parents are.
max_ttl defines the timeframe for wich the token can be renewd
ttl defines when the token will expire and be revoked
For day-to-day operations, the root token should be deleted after configuring other auth methods which will be used by admins and Vault clients.
In situations that a token must not to be deleted: root or sudo users can generate a periodic token (with ttl but no max_ttl).
authentication ok -> user receive a token associated with a policy (authorization workflow) -> this token perform all the new operations
To renew a token:
vault token renew
Token Acessors:
- Look up tokens properties
- look up a tokens capabilities on a path
- renew token
- revoke token
Default max_ttl is 32 days (768h), it can be changed in vault configuration file
To increment the lease id:
vault lease renew -increment=<value in sec>
The kv enable-versioning command turns on versioning for an existing non-versioned key/value secrets engine (K/V Version 1) at its path.
ProTip: You can use vault secrets list -detailed to see what version the KV store is using. Look under the Options header.
* map[] = v1
* map[version:2] = v2
To delete permanently a secret v2:
vault kv metadata delete <path>
AD secret engine can rotate AD passwords dynamically.
To revoke a dynamic secret from vault after it was removed mannually:
vault lease revoke -force -prefix <lease_path>
By default, Vault server initialize the "cubbyhole" KV, but in the dev mode it initilize "cubbyhole" and "secrets"
The worflow: Write > plan > apply
To get detailed information about the secret engines:
vault secrets list -detailed
To revoke all the tokens generateds in github auth:
vault token revoke -mode path auth/github
WALs -> Write-Ahead Log
To consult secrets in a KVv2 engine:
$ curl
--header "X-Vault-Token: <TOKEN>"
https://127.0.0.1:8200/v1/secret/data/path/mysecret
You can sent data by API using a file, it should contains a cleartext in this case.
Automatic unseal methods:
- Transit
- AWS KMS
- HSM
- Azure KMS
The operator step-down forces the Vault server at the given address to step down from active duty. While the affected node will have a delay before attempting to acquire the leader lock again, if no other Vault nodes acquire the lock beforehand, it is possible for the same node to re-acquire the lock and become active again.
Vault doesn't store the data sent to the secrets engine.
https://www.udemy.com/course/hashicorp-certified-vault-associate-practice-exam/