IBM Vault Associate

Vault never stores a secret in the clear. You follow how the encryption barrier works, how initialization produces keys, what sealing and unsealing mean in practice, and which environment variables a client needs.

• The encryption barrier and the storage backend
• Initialization, root token and key shares
• Shamir’s secret sharing in outline
• Sealing and unsealing a server
• Auto-unseal as an alternative
• Client settings: VAULT_ADDR, VAULT_TOKEN and VAULT_NAMESPACE

You build A freshly initialized server that you seal and unseal, with its keys handled sensibly.

Every action in Vault is taken with a token. You compare service and batch tokens, learn how TTLs and the token tree behave, handle root tokens with care and know what accessors and orphan tokens are for.

• Service tokens and batch tokens compared
• TTL, max TTL and renewal
• Periodic and orphan tokens
• Parent and child tokens and revocation
• Token accessors and what they allow
• Root tokens: generate, use, revoke

You build A set of tokens for different workloads, each with a deliberate type and lifetime.

A lease ties a secret to a lifetime. You read lease IDs, renew what is still needed, revoke what is not, and see how leases connect tokens and dynamic credentials so a leak ends on its own.

• What a lease is and where it comes from
• Reading a lease ID
• Renewing leases and the limits on renewal
• Revoking one lease or a whole prefix
• Leases and dynamic secrets together
• Choosing lifetimes that fit the workload

You build A short-lived credential that is renewed, then revoked, with each step observed.

Policies are Vault’s whole access model. You read and write path-and-capability rules, use wildcards and templating carefully, understand the default and root policies, and test what a token can actually do.

• Anatomy of a policy: path and capabilities
• Capabilities: create, read, update, delete, list, deny
• Wildcards and the plus and star matchers
• Templated policies using identity values
• The default policy and the root policy
• Testing what a token can do
• Writing policy from a requirement

You build Three least-privilege policies for different applications, tested against real tokens.

People and machines should prove themselves in different ways. You separate human from system auth methods, configure several through the CLI, API and UI, and use identities and groups to attach policy to who someone is.

• Human methods: username and password, LDAP and OIDC
• System methods: AppRole, Kubernetes and cloud identity
• Choosing a method for a use case
• Enabling and configuring a method
• Identity entities and aliases
• Internal and external groups

You build Two auth methods, one for people and one for an application, mapped to policies through groups.

Engines are the part of Vault that holds or creates secrets. You enable and tune them, use versioned key-value storage, generate credentials on demand, and wrap a secret for single-use hand-off.

• Enabling an engine at a path
• Key-value storage and versioning
• Dynamic database and cloud credentials
• The cubbyhole and response wrapping
• Choosing between an engine’s static and dynamic modes
• Tuning, disabling and moving engines

You build A key-value store and a dynamic database credential, both used by a small application.

Applications should not hold encryption keys. You use the Transit engine to encrypt and decrypt data without ever seeing the key, rotate keys, rewrap old ciphertext and sign or verify data.

• Why applications should not manage keys
• Creating a named encryption key
• Encrypting and decrypting data
• Rotating a key and rewrapping ciphertext
• Minimum decryption version and retiring old keys
• Signing and verifying with Transit

You build An application path that stores only ciphertext, with a key rotation carried out.

Where Vault runs decides how it fails. You compare storage backends, understand active and standby nodes, choose unseal strategies, and learn what performance and disaster recovery replication each protect against.

• Integrated storage and external storage backends
• Cluster strategy and node roles
• Active and standby nodes
• Shamir unseal against auto-unseal
• Performance replication in outline
• Disaster recovery replication in outline

You build A deployment diagram for a Vault cluster, with the failure each part is meant to survive.

Applications should not each learn Vault’s API. You use Vault Agent to authenticate and render secrets for a process, and Vault Secrets Operator to sync them into Kubernetes, and you choose between them for a given workload.

• The problem with applications calling Vault directly
• Vault Agent: auto-auth and templates
• Caching tokens and secrets locally
• Vault Secrets Operator in Kubernetes
• Choosing between Agent and the Operator
• Rotating a secret without restarting everything

You build An application that receives rendered secrets and picks up a rotation without code changes.

Take an application that keeps passwords in a config file and move it fully onto Vault. You choose an auth method, write the policy, issue dynamic credentials, encrypt its data and deliver secrets without a human in the loop.

• Auditing the application’s secrets
• Choosing auth and writing policy
• Replacing static credentials with dynamic ones
• Encrypting application data with Transit
• Delivering secrets with Agent
• Reviewing the result for leftover risk

You build A small application running with no static secrets of its own.