Skip to content

Add token-based auth method to the Magnum CAPI Helm doc #1758

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 2 commits into
base: stackhpc/2024.1
Choose a base branch
from
Open
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
8 changes: 7 additions & 1 deletion doc/source/configuration/magnum-capi.rst
Original file line number Diff line number Diff line change
Expand Up @@ -88,7 +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-<site-specific-name>.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-<site-specific-name>.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::

Expand Down
Loading