Bahriya Kubernetes Engine 2.3.0 is released. It is a minor release: it moves the Kubernetes patch and Kuma’s major version, and adds the controls that security frameworks and regulators commonly ask of a Kubernetes platform. The Kubernetes minor does not move. Exact versions, every one pinned to a patch, are in the release notes in the Mamluk Console.
The Kubernetes patch moves on every node, so this release drains nodes. Plan it as a maintenance window.
Secrets are encrypted at rest
A cluster created with BKE 2.3.0 encrypts its Secrets in etcd, by default. The key is generated on the first control-plane node and never leaves your cluster. Back it up apart from your etcd snapshots: a snapshot cannot be restored without it.
An existing cluster is not changed by the upgrade. Encryption is turned on afterwards with one command, which says what it will do before it does anything, and the key can be rotated the same way. check.sh warns on a cluster that does not encrypt.
Compliance controls
A new compliance block in config.yaml turns on each control as a separate switch: API audit logging that never records the contents of a Secret, Pod Security defaults, hardening of the control plane and every kubelet, Kuma’s CNI plugin, named time servers, and a host firewall with a NodePort filter enforced by Calico. A ConfigMap records which controls are configured and which are observed in force, for a compliance tool or an auditor to read.
Every control is on unless config.yaml turns it off, except the host firewall and the NodePort filter, which are off unless it turns them on. An upgraded cluster receives the controls with the upgrade, and the documentation lists what to check before the window.
Node-to-node ports are open only to the cluster’s nodes
etcd, the kubelet and the pod network’s own ports are now admitted only from the cluster’s nodes. Only the API server and SSH stay open to every address. An existing cluster keeps its earlier rules until each node is told, with one command per node after the upgrade.
Every image is signed
Every image BKE installs is signed with BKE’s image signing key, which is published so that you can verify an image yourself or give the key to an admission policy.
Adding a node is two commands
A command on a control-plane node prints one command for the new node, which installs BKE and joins the node to the cluster. Nothing is copied between nodes by hand.
Kuma 3.0
Kuma moves to 3.0, a major release. The control plane upgrades without interrupting running workloads, but a mesh that carries traffic behaves differently once its workloads restart. apply.sh checks for each such case before it changes anything, and refuses by name when it finds one. If no namespace in your cluster has sidecar injection enabled, none of this affects you.
A query that fails now stops the scripts
In earlier releases, a query that failed, for example because the API server did not answer, could be read as an empty answer. In 2.3.0 a failed query is never read as an answer: apply.sh stops before it changes anything, and check.sh reports a failure, each naming the query.
Upgrading
Clusters upgrade from 2.2.x. A minor release cannot be skipped, and check.sh refuses an attempt to skip one; run it from 2.3.0 on a control-plane node days before the window, and act on every failure.
The order is the usual one: upgrade.sh on the first control-plane node, then on each other node in turn, then apply.sh for the components. As with every BKE upgrade, apply.sh first reports each change against your own values files and changes nothing until you run it with --commit. Turn on Secret encryption once the upgrade is complete. The full sequence is in the documentation.