Skip to content

Automates provisioning and generation of secrets in HashiCorp Vault and provides them to your apps. Application secrets will never be stored in Kubernetes secrets or in ETCD. This significantly mitigates a lot of attack vectors including attacks on Kubernetes, or its control plane.

License

youniqx/heist

Repository files navigation

Heist

A Kubernetes Operator which takes care of provisioning and managing Secrets in Vault for your Applications. It allows you to define secrets and Vault functionality required by your application directly in your Helm chart! Heist enables declarative configuration of Vault Secrets, thus reduces the overhead to setup an application's secrets. This improves the overall security by discouraging reuse of Engines or Secrets.

It has been designed with Security by Design from the ground up, to make securely managing your applications secrets as easy as possible, while still allowing full hands-off automation right out of the box!

Concepts

Heist is meant to fully automate HashiCorp Vault secret and engine management for an application. It works according to these principles and features:

  • Applications can define secrets and secret engines they require in Kubernetes Custom Kubernetes Resources.
  • Heist integrates and utilizes existing environment and acts as a bridge between Kubernetes and HashiCorp Vault.
  • Heist provisions those secrets and secret engines in HashiCorp Vault. Heist currently supports these HashiCorp Vault engine types:
    • KV Engines
    • Transit Engines
    • PKI
  • Heist sets up Vault policies and roles for the applications to access those secrets and secret engines with their Kubernetes service account.
  • To ensure security and separation of access, Heist expects each Deployment, StatefulSet, etc., to have its own, unique service account.
  • It is possible to define dedicated secrets and secret engines for deployments reducing the overhead to setup an environment. This removes the need to reuse secret engines or even secrets for multiple purposes.
  • Heist isolates things based on their namespace and relies on HashiCorp Vault's authentication and authorization mechanisms to grant access to secrets. Additionally, two namespaces cannot share secrets or secret engines.
  • Heist can encrypt static secrets using a Transit Engine so that they can be securely stored and managed in git. Heist can also auto generate unique, secure random secret values generated by HashiCorp Vault.
  • Heist comes with an agent injector similar to the Vault Agent Injector that automatically handles injecting the secrets defined in the CRDs. This makes consuming any secrets easy and transparent for the application itself.

Roadmap

  • Dynamic secret provisioning

Getting Started

We have the following documentation to get you started with Heist:

CRD Documentation

To get an overview of the full CRD specification and descriptions of each property you can use docs.crds.dev.

Additionally, we also have usage guides:

Differences to existing projects

Bank-Vaults

Banzaicloud's Bank-Vaults helps you setup & maintain vault instances. Heist is primarily intended to manage and provision vault objects (secrets, PKIs, engines, ... ) with Kubernetes resources. Heist also allows you to store transit encrypted secrets in resources directly, which allows you to version the secrets with Git.

Vault Agent Sidecar injection

The official Vault Kubernetes injector can be used to expose vault secrets as files inside a container. It does this by adding another container to the pod that needs the secret and mounts a shared volume in both where the secrets will be stored temporarily. Heist has this functionality too, but also maintains, generates, decrypts already encrypted secrets, and provides access control to vault secrets and other Vault objects.

Contributing

We welcome contributions of any kind! A good starting point for your first pull request is our contribution documentation.

About

Automates provisioning and generation of secrets in HashiCorp Vault and provides them to your apps. Application secrets will never be stored in Kubernetes secrets or in ETCD. This significantly mitigates a lot of attack vectors including attacks on Kubernetes, or its control plane.

Topics

Resources

License

Stars

Watchers

Forks

Languages