kubriX Platform – Secret Inventory and Management Guide

Purpose of This Guide

In the kubriX platform, various types of secrets are essential for both the initial bootstrap of the platform and its ongoing operation.

These secrets originate from different sources, serve different purposes, and vary in their relevance for reinstallation, Day 2 operations, or disaster recovery. Without a comprehensive and structured understanding of these secrets, restoring or replicating a kubriX installation can lead to platform instability, failed service integrations, or data loss.

To avoid these risks and ensure operational continuity, this guide provides a clear mapping of:

• All relevant secrets in use within the kubriX platform
• Their role in the platform lifecycle (bootstrap vs. runtime usage)
• Which secrets are dynamically generated and can be re-created during reinstallation.
• Which secrets are required to be backed up to allow for reliable disaster recovery.
• If it can be changed during regular Day 2 operations
• Who provides or owns the secret (Customer vs. Platform Automation)

Secret Categories

Platform secrets can be separated into three major categories:

1. Initialization Secrets

   • Required to connect to external systems such as GitHub/GitLab and(e.g.) DNS providers.
   • These secrets are essential to start the bootstrap process of the kubriX platform(install-platform.sh).

2. Platform Application Secrets

   • Created during platform bootstrap process (e.g., Keycloak, Grafana, ArgoCD).
   • Required to maintain internal application connectivity and platform services.
   • Statically defined or automatically generated during bootstrap process.

3. Customer Integration Secrets

   • Enable kubriX to connect with customer-managed services such as S3 buckets or external IDPs.
   • These are crucial for platform-to-customer application integrations and onboarding use cases.

In a production environment, proper backup and secure storage of non-recreatable secrets (e.g., static GitHub tokens, custom client secrets) is crucial to avoid platform outages during reinstallation or migration. Overall responsibility of managing or rotating initialization secrets, platform applications secrets and customer integration secrets is within platform-team.

Moreover, the order in which secrets are used or required follows the platform’s dependency chain. For example:

• Pre-bootstrap secrets (e.g., Git credentials, domain name settings) must be present for kubriX to even begin deploying infrastructure.
• Internal platform secrets (e.g., Keycloak OIDC client secrets) must exist or be re-generated to allow authentication and service integration.
• Customer Integration Secrets (e.g., S3 bucket credentials) can be restored last, but are still essential for fully bootstrap functionality, if they are used in Helm Charts.

Practical Use Cases as a result of the following List

• Backup planning: Identify which secrets must be stored securely to enable reinstallation or recovery.
• Security audits: Understand ownership and lifecycle of each secret to ensure compliance.
• Platform operations: Know which secrets are changeable during live operations.
• Disaster recovery: Ensure correct restore sequencing based on application dependencies.

---

Secret Inventory Table

Category	App	Name	Type	Provided by	Store	Day 2+ changeable?	Required?
Initialization	VCS	Repository Token	Secret	Customer	k8s secret	Y	Y
	VCS	Repository Name, Branch, ...	Plain	Customer	Helm values	/	Y
	Overall Info	domainName, …	Plain	Customer	helm values	N	Y
	DNS	dns-provider secret	Secret	Customer	k8s secret	Y	Y
	VCS	Backstage Github/Gitlab Client ID and Secret	Secret	.secrets	vault	Y	Y
bootstrap	Keycloak	Admin username/password	Secret	.secrets	vault	Y	Y
	Keycloak	Demo user+Secrets	Secret	.secrets	vault	N	N
	Keycloak	OIDC client secrets for all OIDC-connected apps	Secret	.secrets	vault	Y	Y
		– Backstage, Kargo, Vault, Argocd, Pgadmin, Grafana, Minio
	Keycloak	CNPG DB username/host/database/port/svc	Secret	.secrets	vault	Y	Y (for HA)
	Keycloak	CNPG Adminuser/superuser password	Secret	.secrets	vault	Y	Y (for HA)
	Backstage	Backend Secret	Secret	.secrets	vault	Y	N
	Backstage	External Access Token	Secret	.secrets	vault	Y	Y
	Backstage	CNPG DB username/host/database/port/svc	Secret	.secrets	vault	Y	Y (for HA)
	Backstage	CNPG Adminuser/superuser password	Secret	.secrets	vault	Y	Y (for HA)
	Backstage	vault token for secret creation via template	Secret	crossplane	vault	Y	Y )
	Grafana	Adminuser/password	Secret	.secrets	vault	Y	Y
	Grafana	URL (for team-onboarding-usage)	Secret	.secrets	vault	Y	Y
	Grafana	CNPG DB username/host/database/port/svc	Secret	.secrets	vault	Y	Y (for HA)
	Grafana	CNPG Adminuser/superuser password	Secret	.secrets	vault	Y	Y (for HA)
	Falco	Adminuser/password	Secret	.secrets	vault	Y	Y
	Kargo	Adminpassword	Secret	.secrets	vault	Y	N (disable)
	Kargo	TokenSigninKey	Secret	.secrets	vault	Y	?
	CNPG	Adminuser/superuser password	Secret	.secrets	vault	Y	Y
	Minio	Adminuser/password	Secret	.secrets	vault	Y	Y
	Minio	Demouser/password	Secret	.secrets	vault	Y	N
	Velero	repositorypassword	Secret	.secrets	vault	N	Y
	Velero-UI	Adminuser/password	Secret	.secrets	vault	Y	Y
	Vault	root_token and unseal_key(s)	Secret	init	k8s secret	Y	Y
Customer Apps	IDP	Client secret for kubriX Keycloak	Secret	.secrets	vault	Y	Y
	ext. S3 Bucket	Bucketname, AccessKeyId, Endpoint, SecretAccessKey, S3Cert	Secret	.secrets	vault	Y	Y

---

Legend and Examples

Provided by

• .secrets means secrets get injected into the platform automatically during the bootstrap process.
• crossplane means crossplane resource handle secrets automatically.
• init means autogenerated during creation - should only exist during runtime. (More details on how this work - please see Password Management in kubriX)
• customer means provided by You as a customer

tip

See Runbooks how to change Secrets in running environment (Prime only)