Kubefirst v1.9 Release Notes

Kubefirst 1.9 - The GitHub Release

The Kubefirst 1.9 Release has been a long-awaited feature set for the Kubefirst project. Kubefirst has leveraged and loved self-hosted GitLab for years. If self-hosting your git provider is part of your strategic vision, you really can’t do any better. However GitHub’s incredible popularity and stronghold in many organizations is undeniable and we’re extremely excited to announce that our same great self-hosted cloud native platform now supports GitHub as a git provider.

We’re extremely pleased with the frictionless experience we were able to accomplish. Adding a second git provider to our fully automated gitops platform provisioner was pretty involved. Here’s some of the fun we got to have with the 1.9 release.

Installing Kubefirst To GitHub

Starting in the 1.9 release, you’ll now be able to run kubefirst init and kubefirst cluster create against a GitHub organization. If a GitHub org is specified, the kubefirst cli will opt out of installing the soft-serve, gitlab, and gitlab-runner applications. It will also add an actions-runner-controller application to the cluster, which is a new addition to the kubefirst ecosystem. actions-runner-controller lets you run GitHub Actions in your self hosted kubernetes cluster.

The GitOps repository that the cli produces for you will be added to your GitHub organization instead of a self-hosted git environment. The gitops repository will still be activated with an Atlantis webhook so that your IAC remains automated, but the automation will run through GitHub Pull Requests rather than GitLab Merge Requests - all with the same great system auditing, change management workflows, and security posture that exists on the GitLab variation of Kubefirst.

The metaphor repositories will also be added to your GitHub org, and the example GitOps delivery automation remains powered by Argo Workflows and gitops-delivered with Argo CD. The real time logs and results of the workflows are streamed back to GitHub through the Actions user interface. It’s a great developer experience.

Metaphor becomes Metaphor Microservices

Metaphor is the unsung hero of the Kubefirst platform. Such a simple concept, a tiny demo app used to showcase how to build and deliver applications using GitOps and how to leverage the Kubefirst platform tools. It demonstrates how we integrated GitLab/GitHub with Argo Workflows, how we leverage External Secrets Operator and Vault for application secrets, how we publish containers and Helm charts, how we make our app publicly accessible using Ingress-Nginx, and how we generate short-lived auto renewable TLS certificates using Cert Manager.

Once it becomes your repository in your ecosystem, you can expand on it as a way to provide best practices examples to your team, test out how a new integration might work in the live kubernetes environment, or test your new CI delivery changes on a real application without impacting your development team at all. We’ve loved having Metaphor available to us operationally for many years at Kubefirst.

One of the most important things we want to provide to our users is a clear set of patterns to follow. In this release, we’ve expanded metaphor to provide some additional examples to anchor onto. Starting in 1.9 your Kubefirst platform will come with metaphor microservices, a suite of 3 repositories which now represent a react frontend, a nodejs backend, and a golang backend, so you can start out with some good examples of how to build and deliver using whichever technology is closest to your environment.

Hashicorp Vault Identity Provider and OIDC Provider

GitLab gave us an OIDC and identity provider story that we were very happy with, but when we introduced GitHub to the Kubefirst platform, we wanted to shift toward a comprehensive access solution for a wide variety of our platform access needs. We experimented and spiked out a lot of different options during this release and are incredibly excited about what Hashicorp Vault brings to the platform.

Now when you install either a GitHub or GitLab flavor of the kubefirst platform, your Vault cluster will be configured as your new self-hosted identity provider, managed through Terraform where you can add your administrators and engineers with a simple automated pull request much the same as previous Kubefirst versions.

These roles will be established in your cloud, your kubernetes cluster, and your new identity provider in Vault. We’ll also configure Vault to host an OIDC provider which will come pre-wired into each of the tools on the Kubefirst platform. It’s an instant and cost-free Vault-powered single sign on implementation. We will be leveraging this new provider in some new ways with our cli to provide you with an extremely frictionless lease-based authentication to cloud and kubernetes resources.

Introducing console to the User Experience

During the installation process, a number of different root level passwords are established that we need to deliver to you with the install. You need to be able to get into vault, gitlab, argocd, all of which require auth. In prior releases, we would end the kubefirst cluster create with a terminal screen that provided you with your new urls, root usernames, and credentials. We didn’t love printing those to screen.

Our credentials contract in 1.9 will work a little differently. You’ll set your initial administrator’s user credentials in a values.yaml or via cli switch, and we’ll pre-onboard that user onto the platform, so you can use whatever your password is when you connect to all of your apps through your new Vault OIDC provider. As an administrator everywhere, you’ll have access to the state bucket in s3 that gets created with the install. The credentials will be stored in a file named .kubefirst and private from non-administrator engineers.

So now that we no longer need to present you with any credentials, we wanted to present you with an experimental MVP of our new interface. It’s a new app named console that we have some pretty big plans for. In its MVP debut, the console app will launch at the conclusion of a kubefirst cluster create, and will present you with an easy tile to press to connect you to all of your new cloud native tools. We’d love to hear your feedback on these adjustments in our community slack.

‍