kubevaulter

Warning: This project is in alpha phase and breaking changes are usual.

Kubevaulter are helper tools to handle secrets stored in vault inside your kubernetes cluster.

Authentication

For authentication against vault, kubevaulter-init uses the Kubernetes service account token mounted by default into each pod by Kubernetes automatically. The token should reside under /var/run/secrets/kubernetes.io/serviceaccount/token and is signed by the Kubernetes signing CA

Prerequisites

To use these tools vault must be correctly configured and
reachable from within the kubernetes cluster. kubernetes must support RBAC

Kubernetes with RBAC

and the api-server must be started with the flags --authorization-mode=RBAC and --service-account-lookup.

Also the correct service accounts and clusterRoles and RoleBindings must exist

Kubernetes ClusterRole

This ClusterRole should exist by default, if not it has to be created.

- apiVersion: rbac.authorization.k8s.io/v1
  kind: ClusterRole
  metadata:
    annotations:
      rbac.authorization.kubernetes.io/autoupdate: "true"
    creationTimestamp: null
    labels:
      kubernetes.io/bootstrapping: rbac-defaults
    name: system:auth-delegator
  rules:
  - apiGroups:
    - authentication.k8s.io
    resources:
    - tokenreviews
    verbs:
    - create
  - apiGroups:
    - authorization.k8s.io
    resources:
    - subjectaccessreviews
    verbs:
    - create

Create Service Accounts

One service account need to exist with which vault authenticates against the kubernetes api.

apiVersion: v1
kind: ServiceAccount
metadata:
 name: vault-auth

For each pod that accesses secrets in vault, a service account should exist to authenticate against vault. This can also be the default namespace service account, depending on the needs.

Create Role Binding

apiVersion: rbac.authorization.k8s.io/v1beta1
kind: ClusterRoleBinding
metadata:
 name: role-tokenreview-binding
 namespace: default
roleRef:
 apiGroup: rbac.authorization.k8s.io
 kind: ClusterRole
 name: system:auth-delegator
subjects:
- kind: ServiceAccount
 name: vault-auth
 namespace: default

Vault

To use authentication via service account tokens, the Kubernetes Auth Backend must be enabled and configured correctly. Also policies must exist to manage access of the role to vault secret paths

Enable Kubernetes Auth in Vault

$ vault auth-enable kubernetes
Successfully enabled 'kubernetes' at 'kubernetes'!

Create Role

vault write auth/kubernetes/role/DEMO \
    bound_service_account_names=DEMO-SA\
    bound_service_account_namespaces=DEMO-NS \
    policies=DEMO-POLICY \
    ttl=1h

Example Policy

path "secret/*" {
  capabilities = ["create"]
}

path "secret/foo" {
  capabilities = ["read"]
}

path "auth/token/lookup-self" {
  capabilities = ["read"]
}

General Kubevaulter Config

To configure Kubevaulter, a config file called config in yaml, toml or json format must exist in . or ./config folder of the containers. The location could be overwritten by specifying the environment variable KV_ the general config looks like this

logging:
  logLevel: "debug" #defaults to "info"
  logFormat: "json" #default to "text"
  
vault:
  endpointUrl: "http://localhost:8200"
  secretBackend: "demo-secret" # defaults to "secret" 
  role: "DEMO"
  jwtPath:  "/var/run/secrets/kubernetes.io/serviceaccount/token"  # defaults to "/var/run/secrets/kubernetes.io/serviceaccount/token" 
  failOnEmptySecret: true
  authPath: auth/foo/login # defaults to auth/kubernetes/login
  caCert:

Available tools

• kubevaulter-init an init container to render vault secrets into templates from specific path in the pod filesystem
• kubevaulter-recursive an init container to recursively traverse through a folder structure and rendereing templates with secret values from vault
• kubevaulter-generator creates random strings and stores them in specified vault paths
• kubevaulter-executor executing applications inside the container while providing secret values from vault as parameters to this application