jpapazian2000

Goal:

1. Leverage jwt auth backend in vault to optimize vault client counting
2. Optimise access to secrets via templated policies

Context:

Applications running accross multiple namespaces in k8s-like environments.

ie: app1 in dev, int and prod namespaces. Each pod of these application will by default consume a vault client when connecting to vault.

jpapazian2000

SSH CA use-case with Vault

In this scenario we are going to set up Vault to sign SSH keys using an internal CA. We will configure the SSH secrets engine and create a CA within Vault. We will then configure an SSH server to trust the CA key we just created. Finally we will attempt to SSH using a private key, and a public key signed by Vault SSH CA.

Prerequisites

• This guide assumes you have already provisioned a Vault server, SSH host using OpenSSH server, and a SSH client machine.
• The client system must be able to reach the Vault server and the OpenSSH server.
• We will refer to these systems respectively as:
• VAULT_SERVER

jpapazian2000

HashiCorp Vault as a KMS for Ceph

The following readme guides you thru the steps to set up a minimal demo using a local Vault and a 1 node Rook/Ceph cluster hosted in Minikube

Install and start minikube

$ minikube start (ou minikube start --driver=virtualbox)

When installing rook for the first time, make sure we have a raw device on the minikube host (https://rook.io/docs/rook/v1.3/ceph-quickstart.html)