HashiCorp Vault Intermediate CA Setup with Cert-Manager and Microsoft Root CA

In this post, we’ll explore how to set up HashiCorp Vault as an Intermediate Certificate Authority (CA) on a Kubernetes cluster, using a Microsoft CA as the Root CA. We’ll then integrate this setup with cert-manager, a powerful Kubernetes add-on for automating the management and issuance of TLS certificates.

The following is an architecture diagram for the use case I’ve built.

• A Microsoft Windows server is used as the Root CA of the environment.
• A Kubernetes cluster hosting shared/common services, including HashiCorp Vault. This is a cluster that can serve many other purposes/solutions, consumed by other clusters. The Vault server is deployed on this cluster and serves as an intermediate CA server, under the Microsoft Root CA server.
• A second Kubernetes cluster hosting the application(s). Cert-Manager is deployed on this cluster, integrated with Vault, and handles the management and issuance of TLS certificates against Vault using the ClusterIssuer resource. A web application, exposed via ingress, is running on this cluster. The ingress resource consumes its TLS certificate from Vault.

Prerequisites

• Atleast one running Kubernetes cluster. To follow along, you will need two Kubernetes clusters, one serving as the shared services cluster and the other as the workload/application cluster.
• Access to a Microsoft Root Certificate Authority (CA).
• The Helm CLI installed.
• Clone my GitHub repository. This repository contains all involved manifests, files and configurations needed.

Setting Up HashiCorp Vault as Intermediate CA

Deploy Initialize and Configure Vault

Install the Vault CLI. In the following example, Linux Ubuntu is used. If you are using a different operating system, refer to these instructions.

Is your TKG cluster name too long, or is it your DHCP Server…?

Recently, when working on a TKGm implementation project, I initially ran into an issue that seemed very odd, as I hadn’t encountered such behavior in any other implementation before.

The issue was that a workload cluster deployment hung after deploying the first control plane node. Until then, everything seemed just fine; as the cluster deployment had successfully initialized, NSX ALB had successfully allocated a control plane VIP. After that, however, the deployment had completely hung and seemed like it wouldn’t proceed.

Kubernetes Data Protection: Getting Started with Kasten (K10)

In a recent Kubernetes project I was involved in, our team had to conduct an in-depth proof of concept for several Kubernetes data protection solutions. The main highlights of the PoC covered data protection for stateful applications and databases, disaster recovery, and application mobility, including relocating applications across Kubernetes clusters and even different types of Kubernetes clusters (for example, from TKG on-premise to AWS EKS, etc.).

One of the solutions we evaluated was Kasten (K10), a data management platform for Kubernetes, which is now a part of Veeam. The implementation of Kasten was one of the smoothest we have ever experienced in terms of ease of use, stability, and general clarity around getting things done, as everything is very well documented, which certainly cannot be taken for granted these days. :)

Production-Grade Multi-Cluster TAP Installation Guide

• Introduction
• Prerequisites
• Prepare your Workstation
• Relocate TAP Images to your Private Registry
• Install TAP
  • View Cluster
    • Set up the Installation Namespace
    • Issue a TLS Certificate for TAP GUI
    • Set up a Database for TAP GUI
    • Set up the TAP GUI Catalog Git Repository
    • Set up RBAC for the Metadata Store
    • Set up an Authentication Provider for TAP GUI
    • Set up RBAC for the Build, Run and Iterate Clusters
    • Set an Ingress Domain, TAP GUI Hostname and CA Certificate
    • Deploy the TAP Package
  • Build Cluster
    • Set up the Installation Namespace
    • Set up Metadata Store Authentication and CA Certificate
    • Prepare a Sample Source Code Git Repository
    • Update the TAP Values File
    • Deploy the TAP Package
    • Deploy the TBS Full Dependencies Package
    • Set up the Developer Namespace and Deploy a Workload
  • Run Cluster
    • Set up the Installation Namespace
    • Update the TAP Values File
    • Deploy the TAP Package
    • Set up the Developer Namespace and Deploy a Workload
  • Iterate Cluster
    • Set up the Installation Namespace
    • Update the TAP Values File
    • Deploy the TAP Package
    • Deploy the TBS Full Dependencies Package
    • Set up the Developer Namespace and Deploy a Workload
    • Iterate on your Application
• Wrap Up

Introduction

Since my previous posts on TAP Overview and Backstage, I have been diving deeper into TAP, trying to establish the practices around it.

VMware Tanzu Application Platform Overview

In the first part of this series, I described what Backstage is and some of the advantages it aims to solve. VMware uses Backstage to enable its Tanzu Application Platform (TAP). Before we can understand how, however, we need to understand what TAP is and what it aims to do.

So, what exactly is the Tanzu Application Platform?

TAP is a robust application development platform entirely focused on the developer experience. It provides a rich set of developer tools in a centralized user interface. It is the latest innovation in this space from VMware. It is a true game-changer, building upon community-adopted tooling and the existing products within the Tanzu Advanced Suite to offer a next-gen PaaS solution that aims to solve the same challenges the traditional PaaS systems solve, as well as the issues they introduced.