From c48d60b0e803774b3f15e54bd48922cf601a3427 Mon Sep 17 00:00:00 2001 From: JasleenKaurSethi <53913719+JasleenKaurSethi@users.noreply.github.com> Date: Mon, 14 Jul 2025 12:07:28 +0100 Subject: [PATCH 1/2] Update magnum-capi.rst --- doc/source/configuration/magnum-capi.rst | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/doc/source/configuration/magnum-capi.rst b/doc/source/configuration/magnum-capi.rst index bc836ccc8..1168fd45f 100644 --- a/doc/source/configuration/magnum-capi.rst +++ b/doc/source/configuration/magnum-capi.rst @@ -88,7 +88,8 @@ The general running order of the provisioning playbook is the following: - Install the required components on the HA cluster to manage Magnum user clusters -Once the seed VM has been provisioned, it can be accessed via SSH by running ``./bin/seed-ssh`` from the root of the azimuth-config repository. Within the seed VM, the k3s cluster and the HA cluster can both be accessed using the pre-installed ``kubectl`` and ``helm`` command line tools. Both of these tools will target the k3s cluster by default; however, the ``kubeconfig`` file for the HA cluster can be found in the seed's home directory (named e.g. ``kubeconfig-capi-mgmt-.yaml``). +Once the seed VM has been provisioned, it can be accessed via SSH by running ``./bin/seed-ssh`` from the root of the azimuth-config repository. Within the seed VM, the k3s cluster and the HA cluster can both be accessed using the pre-installed ``kubectl`` and ``helm`` command line tools. Both of these tools will target the k3s cluster by default; however, the ``kubeconfig`` file for the HA cluster can be found in the seed's home directory (named e.g. ``kubeconfig-capi-mgmt-.yaml``). This file can contain two types of authentication configurations: +Client Certificate-Based Authentication configuration which is valid for a limited period (typically one year). Once expired, the certificate must be manually refreshed, which can lead to operational overhead. As an alternative, a token-based kubeconfig can be created by generating a ServiceAccount with appropriate ClusterRole permissions and embedding its token in a kubeconfig. This method provides a long-lived, non-expiring authentication without any manual intervention required. .. note:: From f4b4e85a8d840a03b8300be6fb4bf39f5636acea Mon Sep 17 00:00:00 2001 From: JasleenKaurSethi <53913719+JasleenKaurSethi@users.noreply.github.com> Date: Mon, 14 Jul 2025 12:24:53 +0100 Subject: [PATCH 2/2] Apply suggestions from code review Co-authored-by: Scott Davidson <49713135+sd109@users.noreply.github.com> --- doc/source/configuration/magnum-capi.rst | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/doc/source/configuration/magnum-capi.rst b/doc/source/configuration/magnum-capi.rst index 1168fd45f..2bec44e3f 100644 --- a/doc/source/configuration/magnum-capi.rst +++ b/doc/source/configuration/magnum-capi.rst @@ -88,8 +88,13 @@ The general running order of the provisioning playbook is the following: - Install the required components on the HA cluster to manage Magnum user clusters -Once the seed VM has been provisioned, it can be accessed via SSH by running ``./bin/seed-ssh`` from the root of the azimuth-config repository. Within the seed VM, the k3s cluster and the HA cluster can both be accessed using the pre-installed ``kubectl`` and ``helm`` command line tools. Both of these tools will target the k3s cluster by default; however, the ``kubeconfig`` file for the HA cluster can be found in the seed's home directory (named e.g. ``kubeconfig-capi-mgmt-.yaml``). This file can contain two types of authentication configurations: -Client Certificate-Based Authentication configuration which is valid for a limited period (typically one year). Once expired, the certificate must be manually refreshed, which can lead to operational overhead. As an alternative, a token-based kubeconfig can be created by generating a ServiceAccount with appropriate ClusterRole permissions and embedding its token in a kubeconfig. This method provides a long-lived, non-expiring authentication without any manual intervention required. +Once the seed VM has been provisioned, it can be accessed via SSH by running ``./bin/seed-ssh`` from the root of the azimuth-config repository. Within the seed VM, the k3s cluster and the HA cluster can both be accessed using the pre-installed ``kubectl`` and ``helm`` command line tools. Both of these tools will target the k3s cluster by default; however, the ``kubeconfig`` file for the HA cluster can be found in the seed's home directory (named e.g. ``kubeconfig-capi-mgmt-.yaml``). + +This file can contain two types of authentication configuration: + +- Certificate-based authentication which is valid for a limited period (typically one year). The certificate must be manually refreshed before it expires, which can lead to undesirable operational overhead. + +- A service account and corresponding token-based kubeconfig with appropriate Kubernetes RBAC permissions. This method provides a long-lived, non-expiring authentication and should be preferred where possible. This option can be enabled by setting `capi_cluster_service_account_enabled: true` in the azimuth-config repository (this is the default behaviour when using the capi-mgmt mixin environment). .. note::