• Secret engines are Vault components, which store, generate, encrypt data
• Many secrets engines can be enabled and used as needed
• Secret engines or enabled and isolated at a path
• all the interactions with the secret engines are done directly with the path itself

• Components that perform authentication to vault itself, in order for the users to access the data from the vault
• authentication methods are responsible for assigning identity and policies to a user
• multiple authentication methods can be enabled depending on your use case. For example, git, hub, username, password, LDAP all at the same time. Once authenticated volt will issue at client, token used to make subsequent vault requests. For example, if a user log-in with the github account, vault will issue a client token upon authenticating. This token will further be used to read or write the data in the vault.
• default method for authentication is tokens

• Authenticating - tied to multiple identity sources or its own
• Authorizing - to dictate what an user or application can do with vault
• Auditing - logs of all the interactions involved
• Distributed - we can use disaster recovery or data replication to distribute the secrets across multiple data centers or cloud environments
• Scalable - we can use features like read replicas
• Entensible - we can use plugins to extend the functionality of vault platform

• Vault uses an encryption key to encrypt given data, vault uses a master key to encrypt or decrypt the encryption key, which in turn used for encrypting or decrypting the secrets, once the vault node acquires the master key, it is stored in memoryonce the vault node acquires the master key, it is stored in memory, note that the master key is not persisted anywhere, note that the master key is not persisted anywhere

Command to initialise the vault: vault operator init

• vault gets initialized with sealed state, no operation can be performed when the vault is in sealed state, except status check,
• vault can be manually sealed as well from the ui or cli, when sealed, vault throws away the master key
• in order to unseal the vault again, the node has to generate the master key gain
• options for unsealing vault
  • Key Sharding (default) - master key is sharded in to multiple pieces, shared with multiple people in the organization
  • Cloud Auto Unseal - when user does not want manual unsealing
  • Transit Unseal - new feature, using a separate vault cluster to unseal our vault

Once all 3 shards are entered, Vault is able to construct the master key and unseal the vault.

Note: the unsealing keys generated should be kept secret, which will be used while unsealing the vault.

• Uses key management service instead of key shards in order to encrypt the master key