Banzai Cloud Logo Close
Home Products Benefits Blog Company Contact
Sign in
Author Nandor Kracser

Bank-Vaults feature updates

One of the key open-source project of the Banzai Cloud Pipeline platform is Bank-Vaults - the Vault swiss-army knife for Kubernetes (and not just). As part of the Pipeline platform we have our own feature requirements however the pretty large community around Bank-Vaults has their own use cases and requirements. While we receive lots of external contributions (thank you) we try to find time to work on our community driven features as well.

While there are lots more, these were the most sought after features of the last few weeks - and we made some time between two Pipeline releases to implement them.

The Ingress resource gets configured

The most frequently asked feature we received for Bank-Vaults Kubernetes Vault operator was to create an Ingress resource automatically for the provisioned Vault instance’s Service. This has been implemented for and tested with NGiNX, Traefik and HAProxy proxy Ingress controllers (support means that the relevant TLS marking and optional skip-verify annotations are added to these Ingress resources if Vault TLS is enabled, since not all of them supports mounting a custom CA certificate).

The relevant (minimum) part from the full CRD descriptor to request an Ingress for the Vault service is:

 1  # Request an Ingress controller with the default configuration
 2  ingress:
 3    # Specify Ingress object annotations here, if TLS is enabled (which is by default)
 4    # the operator will add NGINX, Traefik and HAProxy Ingress compatible annotations
 5    # to support TLS backends
 6    annotations: {}
 7    # Override the default Ingress specification here
 8    # This follows the same format as the standard Kubernetes Ingress
 9    # See:
10    spec: {}

Audit devices and outputs getting configured

Vault Audit Devices are also a community requested feature that we found really useful from DevOps point of view; from the official Vault documentation:

Audit devices are the components in Vault that keep a detailed log of all requests and response to Vault. Because every operation with Vault is an API request/response, the audit log contains every authenticated interaction with Vault, including errors.

Creating an S3 fully working example sounded very feasible, but for this reason we had to touch a few components in the Bank-Vaults stack to make this fully work.

First The Vault Operator had to be extended with the capability to configure the fluentd sidecar container through the CRD.

Secondly, we gave support for Audit Devices by extending bank-vaults configurer to configure Vault via the audit: block in the configurer YAML file (called externalConfig: in the Vault CRD).

Vault Operator

The relevant part from the full CRD descriptor is:

 2  fluentdEnabled: true
 4  # Use a custom fluentd image which has the S3 plugin installed
 5  fluentdImage: banzaicloud/fluentd-s3:latest
 7  fluentdConfig: |
 8    <source>
 9      @type tail
10      format json
11      keep_time_key true
12      time_format %iso8601
13      path /vault/logs/vault.log
14      pos_file /vault/logs/vault.log.pos
15      tag s3.vault.audit
16    </source>
17    <match s3.*.*>
18      @type s3
20      aws_key_id "#{ENV['AWS_ACCESS_KEY_ID']}"
21      aws_sec_key "#{ENV['AWS_SECRET_ACCESS_KEY']}"
22      s3_bucket bank-vaults
23      s3_region eu-west-1
24      path logs/
26      time_slice_format %Y%m%d%H
27      time_slice_wait 10m
28      utc
29    </match>
31  # Pass secret to bank-vaults environment variables.
32  # kubectl create secret generic aws-access-key \
33  # --from-literal=aws-access-key-id=$AWS_ACCESS_KEY_ID \
34  # --from-literal=aws-secret-access-key=$AWS_SECRET_ACCESS_KEY
35  envsConfig:
36    - name: AWS_ACCESS_KEY_ID
37      valueFrom:
38        secretKeyRef:
39          name: aws-access-key
40          key: aws-access-key-id
42      valueFrom:
43        secretKeyRef:
44          name: aws-access-key
45          key: aws-secret-access-key
47  # Tell the bank-vaults configurer to configure Vault to use a file based audit device
48  externalConfig:
49    audit:
50      - type: file
51        description: "File based audit logging device"
52        options:
53          file_path: /vault/logs/vault.log
54          mode: "0640"

Inserting “Startup” secrets into Vault

In certain situations it is nice to have some secrets that are not-really secrets, but you are using the secrets source as the single source of truth for all of your configurations; we had this discussed in the following community feature request.

Startup Secrets

The relevant (minimum) part from the full CRD descriptor to request Bank-Vaults to write some “secrets” to Vault during the configuration phase (bootstrap) is:

 1  externalConfig:
 2    # Allows writing some secrets to Vault (useful for development purposes).
 3    # See for more information.
 4    startupSecrets:
 5      - type: kv
 6        path: secret/data/config
 7        data:
 8          data:
 9            my-config-url: https://localhost:1234
10            flags: "-d -z -c"

Operator sync period configuration

One of our users created a new TLS secret with an existing name, and it was overwritten (see issue here). Scenarios like this can make a service using SSL unreachable, however it’s a valid scenario to change and/or recycle old TLS certificates. We added a new feature into the operator to resync in every minute (configurable), so if resources are deleted (for example TLS certificates) they will be recreated relatively quickly. Also creating a new resource with an existing name it will not overwrite the old one by default.

In the making

Also based on ideas from the community, we are planning to extend the Vault secrets webhook with sourcing environment variables based on other sources and add regional fallback support to the Vault unsealing and configuration feature of Bank-Vaults. If you are willing to collaborate, have additional feature requests or need help - as always - please feel free to get in touch.

Thank you.

About Pipeline

Banzai Cloud’s Pipeline provides a platform which allows enterprises to develop, deploy and scale container-based applications. It leverages best-of-breed cloud components, such as Kubernetes, to create a highly productive, yet flexible environment for developers and operations teams alike. Strong security measures—multiple authentication backends, fine-grained authorization, dynamic secret management, automated secure communications between components using TLS, vulnerability scans, static code analysis, CI/CD, etc.—are a tier zero feature of the Pipeline platform, which we strive to automate and enable for all enterprises.

If you’re interested in our technology and open source projects, follow us on GitHub, LinkedIn or Twitter:



comments powered by Disqus