We had quite a few Bank-Vaults releases recently where new features arrived in the webhook and operator. This is no coincidence, rather, these features were developed and implemented with the help of the community that has grown up around the project over the past two years. In this blog post, we would like to highlight and discuss some of these improvements (though, this is not an exhaustive list). Docker image registry changes ghcr.

Distributed applications Distributed applications have many definitions, but typically they are defined as applications that run on a network of multiple computers. Nowadays, that might well mean an application that runs on multiple Kubernetes clusters that are distributed over a large geographical area. Since such clusters are distributed, they have many benefits - like high-availability, speed, resiliency - but it can make developing, operating, and testing such applications tedious. The Multi-DC feature of Bank-Vaults is just such a distributed application; its testing was not automated and required us to manually test each time an important PR went into master.

Applications running in Kubernetes Pods are authenticated against the Kubernetes API with their corresponding ServiceAccount tokens. These JWT tokens are usually mounted into containers as files. JWT tokens are signed by the Kubernetes cluster’s private key, and can be validated only with the TokenReview API. This API is not widely recognized and, to access it, external systems must first authenticate against Kubernetes to review ServiceAccounts. This configuration and access review process is considerably more complex than necessary, not to mention that it leaves out widely accepted standards like OIDC.

Bank-Vaults already supports multiple KMS alternatives for encrypting and storing unseal-keys and root-tokens. However, during bootstrapping and configuring sometimes you need to source other secrets to configure Vault securely. In this post you will learn how to do that with the help of the valuable contributions of Pato Arvizu. Thank you! For those unfamiliar with Bank-Vaults, let’s do a quick recap. Bank-Vaults is a Vault Swiss Army knife, which makes enterprise-grade security attainable on Kubernetes.

From the beginning, Bank-Vaults has been one of the core building blocks of Pipeline - Banzai Cloud’s container management platform for hybrid clouds. Today we are happy to announce the release of Bank-Vaults 1.0. Additionally, we have taken the step of adding Bank-Vaults support for hardware security modules, usually abbreviated as HSMs. Bank-Vaults 1.0 Bank-Vaults was first released two years ago as a Vault operator for Kubernetes, a CLI tool and a Go library.

One of the most popular feature of Bank-Vaults, the Vault swiss-army knife for Kubernetes is the secret injection webhook. With the growing popularity of Istio, recently the most requested feature was to support for running Bank-Vaults alongside Istio. We are big fans of Istio (a year ago we open sourced an Istio operator) and we have built an automated and operationalized service mesh, Banzai Cloud Backyards. As both components (Bank-Vaults and Backyards (now Cisco Service Mesh Manager)) are part of our hybrid cloud container management platform, Pipeline, we went ahead and made them work together smoothly.

Readers of this blog may remember a post we made in January about Bank-Vaults that touched on the topic of disaster recovery with multi datacenter replication. In that post we dicussed replication, mostly in the context of it being used as a form of hot backup. Today we’ll be exploring cold backups, another but equally important form of disaster recovery. Why we use Velero We use a toolset for Kubernetes disaster recovery called Velero.

In today’s post, we’ll be discussing multi-datacenter Vault clusters that span multiple regions. Most enterprises follow different replication strategies to provide scalable and highly-available services. One common replication/disaster recovery strategy for distributed applications is to have a hot standby replica of the very same deployment already setup in a secondary data center. When a catastrophic event occurs in the primary data center, all traffic is then redirected to the secondary datacenter.

A key part of the Banzai Cloud Pipeline platform, has always been our strong focus on security. We incorporated Vault into our architecture early on in the design process, and we have developed a number of support components to be easily used with Kubernetes. We love what Vault enables us to do, but, as with many things security-related, strengthening one part of our system exposed a weakness elsewhere. For us, that weakness was K8s secrets, which is the standard way in which applications consume secrets and credentials on Kubernetes.

One of the Pipeline platform’s key open-source component is Bank-Vaults - the Vault swiss-army knife for Kubernetes. Feature requirements are a big part of the Pipeline platform, but a community has also built up around Bank-Vaults, and now it has its own use cases and requirements. We’ve received a lot of these external contributions and feature requests since our last blog update, which was about Bank-Vaults 0.4.7 in February. We’d like to walk you through some of these festures as 0.

The following is a guest blog post from Jürgen Weber, Bank-Vaults user and contributor extraordinaire. Here at hipages, we have a legacy approach to how we keep and maintain our ‘secrets’. The login details for some of our primary application resources are easy to obtain and with this carries great risk.. So to solve this we decided to embark on a ‘secrets’ project and implement Hashicorps Vault. As a part of this project, we looked at a variety of solutions.

One of the Banzai Cloud Pipeline platform’s key open-source projects is Bank-Vaults - the Vault swiss-army knife (and more) for Kubernetes. Feature requirements are part of the Pipeline platform, and the relatively large community around Bank-Vaults also has its own use cases and requirements. We’ve received lots of external contributions (thank you!), and we continue to find time to work on our community-driven features. While there have been many besides, these are the most sought-after features of the last few weeks.

At Banzai Cloud we’re building a managed Cloud Native application and devops platform, called Pipeline. Pipeline supercharges the development, deployment and scaling of container-based applications with native support for multi- and hybrid-cloud environments. Pipeline’s built-in CI/CD solution is capable of creating Kubernetes clusters, running and testing builds, packaging and deploying applications as Helm charts, and lots more—all while its secrets are stored and managed by Vault. Note: The Pipeline CI/CD module mentioned in this post is outdated and not available anymore.

Suppose you’re working on a project which is running on Kubernetes - like we usually do - and you would like to test out this project on each and every pull request or commit. You can write many unit and integration tests, but at the end of the day, the proof of the pudding is in the eating. A real test would be to start up the application on the same platform where it will end up being deployed in production (in this case Kubernetes) and exercise it with some real workloads (aka end-to-end tests).

The following is a guest blog post from Robbie Blaine, Site Reliability Engineer at EOH Big Data Lab. Contributions from the community are a key factor in driving our products forward. BIG thanks to all of you who have engaged with us by raising issues, giving feedback, or creating pull requests. Keep them coming, we love them! Automating Vault Deployment and Configuration on OKD with Bank-Vaults Hashicorp Vault is an Encryption-as-a-Service tool that is used to securely store and access secrets.

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, etc.—are a tier zero feature of the Pipeline platform, which we strive to automate and enable for all enterprises.

Two core features of the Pipeline platform are advanced security and observability for all Kubernetes deployments. We make sure that all secrets are securely stored, transported, images scanned, deployments monitored, and logs centrally collected. As you might expect from us, we use the industry standard in security components, such as Vault, Prometheus, Grafana, Fluent and more. This post is about monitoring Vault with Prometheus (on Kubernetes) and displaying metrics on Grafana.

At Banzai Cloud we are building a feature rich enterprise-grade application platform, built for containers on top of Kubernetes, called Pipeline. With Pipeline we provision large, multi-tenant Kubernetes clusters on all major cloud providers such as AWS, GCP, Azure and BYOC, on-premise and hybrid, and deploy all kinds of predefined or ad-hoc workloads to these clusters. For us and our enterprise users, Kubernetes secret management (base 64) was not sufficient, so we chose Vault and added Kubernetes support to manage our secrets.

At Banzai Cloud we are building a feature rich enterprise-grade application platform, built for containers on top of Kubernetes, called Pipeline. With Pipeline we provision large, multi-tenant Kubernetes clusters on all major cloud providers such as AWS, GCP, Azure and BYOC, on-premise and hybrid, and deploy all kinds of predefined or ad-hoc workloads to these clusters. For us and our enterprise users, Kubernetes secret management (Base64) was woefully inadequate, so we chose Vault with native Kubernetes support to manage our secrets.

At Banzai Cloud we’re building a feature rich platform, Pipeline, on top of Kubernetes. With Pipeline we provision large, multi-tenant Kubernetes clusters on all major cloud providers - AWS, GCP, Azure and BYOC - and deploy all kinds of predefined or ad-hoc workloads to these clusters. We wanted to set the industry standard for the way in which our users log in and interact with secure endpoints, and, at the same time, we wanted to provide dynamic secret management for each application we support.

Bank-Vaults is a thick, tricky, shifty right with a fast and intense tube for experienced surfers only, located on Mentawai. Think heavy steel doors, secret unlocking combinations and burly guards with smack-down attitudes. Watch out for clean-up sets. Bank-Vaults is a wrapper for the official Vault client with automatic token renewal, built in Kubernetes support, dynamic database credential management, multiple unseal options, automatic re/configuration and more. At Banzai Cloud, we’ve been building an open source next generation platform as a service, called Pipeline, which is constructed on top of Kubernetes.

This is a copy of a guest post we published on the Hashicorp blog about how we use Vault with Kubernetes. At Banzai Cloud, we’re building a feature rich platform as a service on Kubernetes, called Pipeline. With Pipeline, we provision large, multi-tenant Kubernetes clusters on all major cloud providers, such as AWS, GCP, Azure and BYOC, and deploy all kinds of predefined or ad-hoc workloads to these clusters. We needed a way for our users to log in and interact with protected endpoints and, at the same time, provide dynamic secrets management support, while simultaneously providing native Kubernetes support for all our applications.

Security series: Authentication and authorization of Pipeline users with OAuth2 and Vault Dynamic credentials with Vault using Kubernetes Service Accounts Dynamic SSH with Vault and Pipeline Secure Kubernetes Deployments with Vault and Pipeline Policy enforcement on K8s with Pipeline The Vault swiss-army knife The Banzai Cloud Vault Operator Vault unseal flow with KMS Kubernetes secret management with Pipeline Container vulnerability scans with Pipeline Kubernetes API proxy with Pipeline