sakiib commented 3 years ago

User should be able to generate SecretProviderClass to use the Secrets Store CSI driver using KubeVault CLI. For example: $ kubectl-vault create secret-provider-class ...
Detailed manifest files can be found here if needed.

Here's the complete step by step manual procedure and we want to automate the Step 3:

Step 1: Enable SecretEngine and Create SecretEngineRole

[DB Admin] Enable a new SecretEngine

apiVersion: engine.kubevault.com/v1alpha1
kind: SecretEngine
metadata:
name: ${db-name} 
namespace: ${db-namespace}
spec:
...
path: k8s.-.${db-ns}.${db-name}

[DB Admin] Create a SecretEngineRole e.g. ElasticsearchRole

apiVersion: engine.kubevault.com/v1alpha1
kind: ElasticsearchRole
metadata:
name: ${db-name}-${db-role-name} # name provided by db admin
namespace: ${db-namespace} # VALIDATE: secretEngine ref is always from the same namespace
spec:
# mutator sets vaultRef and path from secretEngine
secretEngine:
name: ${secret-engine-name}
vaultRef:
name:
namespace:
# path: "your-database-path"

Step 2: Create VaultPolicy & bind it to a ServiceAccount using VaultPolicyBinding

[DB Admin] Create VaultPolicy

apiVersion: policy.kubevault.com/v1alpha1
kind: VaultPolicy
metadata:
name: ${db-name}-${db-role-name}-reader # = ${policy-name}
namespace: ${db-namespace}
spec:
...
policyDocument: |
path "k8s.-.${db-ns}.${db-name}/creds/${db-name}-${db-role-name}" {
  capabilities = ["read"]
}

[User] Create ServiceAccount

apiVersion: v1
kind: ServiceAccount
metadata:
name: test-user-account
namespace: test

[Vault Admin] Create VaultPolicyBinding

apiVersion: policy.kubevault.com/v1alpha1
kind: VaultPolicyBinding
metadata:
name: es-reader-role
namespace: demo
spec:
...
policies:
- ref: es-reader-policy

Step 3: Create SecretProviderClass

[User] Create SecretProviderClass

apiVersion: secrets-store.csi.x-k8s.io/v1alpha1
kind: SecretProviderClass
metadata:
name: vault-db-provider
namespace: test
spec:
provider: vault 
parameters:
vaultAddress: "http://vault.demo:8200"
roleName: "k8s.-.demo.es-reader-role"   
objects: |
  - objectName: "es-username"
    secretPath: "your-database-path/creds/k8s.-.demo.es-superuser-role" 
    secretKey: "username"
  - objectName: "es-password"
    secretPath: "your-database-path/creds/k8s.-.demo.es-superuser-role"
    secretKey: "password"

Step 4: Create a Pod & mount

[User] Create a Pod and mount the dynamically generated Database credentials in it.

apiVersion: v1
kind: Pod
metadata:
name: demo-app
namespace: test
spec:
...
serviceAccountName: test-user-account

Information we may need to generate the SecretProviderClass:

vault namespace for generating vaultAddress
roleName may be generated from VaultPolicyBinding name, e.g. k8s.(clusterName or -).namespace.name
objectName may be kept same as the respective secretKey
secretPath may be generated from SecretEngineRole ElasticsearchRole name, path/creds/name

tamalsaha commented 3 years ago

VaultServer

SecretEngine

-> Enable: /database/config (one-time enable)

/aws/config/root => /k8s.-.{se-type}.se-ns.se-name/config/root

/database/config/:name => /k8s.-.{se-type}.se-ns.se-name/config/database

ElasticsearchRole

https://www.vaultproject.io/api/secret/databases#create-role

api path: /k8s.-.{se-type}.se-ns.se-name/roles/{es-role-cr-name}

Vault Policies

https://www.vaultproject.io/api-docs/system/policies#create-update-acl-policy

metdata.name = replace({se-type}.se-ns.se-name.{es-role-cr-name}, ".", "-")

/sys/policies/acl/:name name = k8s.-.{se-type}.se-ns.se-name.{es-role-cr-name}

PolicyBinding

https://www.vaultproject.io/docs/auth/kubernetes#configuration

metadata.name: replace({se-type}.se-ns.se-name.{secret-role-binding-cr-name}, ".", "-")

vault write auth/kubernetes/role/demo \
    bound_service_account_names=vault-auth \
    bound_service_account_namespaces=default \
    policies=default \
    ttl=1h

demo = k8s.-.{se-type}.se-ns.se-name.{secret-role-binding-cr-name}