Skip to content

VaultOperator provides a CRD to interact securely and indirectly with secrets stored in Hashicorp Vault.

License

Notifications You must be signed in to change notification settings

finleap-connect/vaultoperator

Repository files navigation

vault-operator

Build status Coverage Status Go Report Card Go Reference GitHub release

The vault-operator provides several CRDs to interact securely and indirectly with secrets.

Quick start

Add the helm repository to your list of repos:

$ helm repo add finleap-connect https://finleap-connect.github.io/charts/
$ helm repo update

Execute the following to get the complete list of values available:

helm show values finleap-connect/vault-operator --version <VERSION>

Configure at least the following settings within your values.yaml :

# Configure Vault connection
vault:
  addr: "" # Required address of Vault
  tls:
    secretName: "" # Required secret containing CA to access Vault
  credentials:
    secretName: "" # Required secret containing AppRole credentials as fields VAULT_ROLE_ID and VAULT_SECRET_ID, see https://www.vaultproject.io/docs/auth/approle
  namespace: "" # Optional Vault namespace to connect to

# Set which secret engines are allowed to access namespaced
allowedSecretEngines:
  - app

# Set which paths in Vault are allowed to be accessed from any namespace
sharedPaths:
  - shared

Install VaultOperator with the following command:

$ helm install finleap-connect/vault-operator --name myrealease --version <VERSION> --values values.yaml

Details

Currently only stage 1 is implemented, which includes the VaultSecret-CRD.

For future feature and planning refer to DESIGN.md.

VaultSecret

To give indirect control over secrets the VaultSecret can be used. For each field name in a Secret it refers to a location in vault and will pull the data and write it to the secret.

If the data in vault does not exist, it will be created if a generator is provided. Currently several generators are implemented:

  • string generates a random string with length args[0]
  • bytes generates random bytes with length args[0]
  • password special form of string generations where args[0] is the length and is mandatory. args[1] optionally specifies the number of digits and args[2] optionally defines the number of symbols.
  • rsa generates RSA private key with bit size args[0] (encoded as PEM)
  • ecdsa generates EC private key with curve args[0] (encoded as PEM)

Locations in the vault are given by the path and the field within the entry. Optionally the version of the entry may be given. This is only valid if the secret engine of the entry is of the type KV v2. To ensure reproducable deployments, the version number should be set when ever possible.

Furthermore simplified permission control exists. Every VaultSecret can access shared spaces which can be configured via the Helm Chart, but otherwise only namespaced sub-paths are permitted, e.g. VaultSecret in mynamespace can access app/mynamespace.

Example:

apiVersion: vault.finleap.cloud/v1alpha1
kind: VaultSecret
metadata:
  name: myvaultsecret
  namespace: mynamespace
spec:
  secretName: name-of-generated-secret  # optional, default it is the same as the name of the VaultSecret
  secretLabels: # optional, specify labels for the managed secret
    foo: bar
  data: # optional if dataFrom is specified
  - name: something
    generator: # optional
      name: "string"
      args: [16]
    location: # required, if variables and template not provided
      path: app/test/foo
      field: bar
  - name: morecomplex
    variables: # required, if location not provided
    - name: "test"
      location:
        path: app/test/fizz
        field: buzz
        isBinary: 1 # optional
        version: 1 # optional
      generator: # optional same as above
    template: |- # required if location not provided
      asdasd {{.test}}
  dataFrom: # optional if data is specified, gets all fields under a given vault path
  - path: app/test/bar
    version: 1 #optional
    collisionStrategy: "Error" #optional
    # Valid values are:
    # - "Error" (default): Errors if a field on this vault secret already exists on the resulting K8s secret
    # - "Ignore": Value from this vault secret will be ignored if the same field already exists on resulting K8s secret
    # - "Overwrite": Value from this vault secret will override an already existing field on the resulting K8s secret
  - path: app/test/bazz
    version: 1 #optional
    collisionStrategy: "Overwrite" #optional

Special cases

  1. If the VaultSecret only contains a single data element with the name .dockerconfigjson, the created secret will have the type kubernetes.io/dockerconfigjson instead of Opaque.
  2. When using a generator it is not allowed to set a fixed version. Renewal for generated secrets is an ongoing discussion. The generator will only run if the concrete field in the secret does not yet exist in vault.
  3. If dataFrom is used, multiple paths in vault can be specified and all fields of the paths in vault will be joined in one secret. As collisions can occure, it is possible to define the strategy how to handle these. The default strategy is Error.

Development

This project utilizes kubebuilder and therefore please refer to its documentation to understand the scaffolding (there are significant differences to the standard layout).

Prerequisites

The test suite needs the kubebuilder assets. If they are not installed in the default path make sure to set KUBEBUILDER_ASSETS before running tests.