Password Management in kubriX

This document describes how to manage and change administrative passwords for various services within the kubriX platform.

---

High-Level Overview

For Day 2 Operations, users should primarily operate in their own user context by logging in via OIDC/Keycloak. This approach ensures that the kubriX platform can maintain traceability and accountability for all user actions.

While it is considered best practice to disable admin logins wherever possible, certain scenarios—such as troubleshooting, disaster recovery, or special use cases—require administrative access. These admin credentials should then be treated with care and rotated periodically.

This guide outlines how to manage both the initial setup of credentials during bootstrap and how to rotate passwords during regular operations.

---

Initial Password Setup — Bootstrap Process

During the cluster bootstrap, initial passwords can be defined in files within the .secrets/ directory.

automatic generated credentials

credentials get automatically generated during bootstrap by adding following parameters.

Example File (.secrets/.envoss.yaml):

secrets:
# Baseenvironment variables
# For Demo Purposes they can be used "as is" but for production they should be changed

#  - application: "<application name>"
#    path: "<path to secret in vault>"
#    namespace: "<namespace where secret should be created>"
#    secretType: "<Opaque, tls, auth,... "
#    secretname: <secretname> 
#    stringData:
#      rootPassword: "root12345"
#      API_KEY: "dynamic:32:hex"
#      API_SECRET: "dynamic:16:alphanumeric"
...

During Installationprocess Secrets got generated out of these templates and additional pushed via Pushsecret to vault. These secrets are used with ExternalSecrets so they can be changed in Day 2 Operations.

tip

See annotations about the current State of these Secrets:

# bootrap mode
annotations:
    kubrix.io/install: "true"
# bootstrap finished
annotations:
    kubrix.io/install: "false"

Important

The pushsecrets component, responsible for pushing secrets to Vault during bootstrap, MUST be deleted after bootstrap. If it remains active, due to a failure during bootstrap process, it may prevent subsequent password changes.