Sample secrets file

Capacity Private Cloud relies on four supporting services — RabbitMQ, PostgreSQL, Redis, and MongoDB — each of which authenticates with credentials supplied through Kubernetes Secrets. These secrets must exist in the cluster before you install the Capacity Private Cloud Helm chart, because the chart references them by name when deploying the workloads.

Below is a sample manifest you can adapt for your installation. Replace each EXAMPLE_PASSWORD placeholder with the real password for the corresponding service. Adjust the namespace if your installation does not use the default lumenvox namespace.

Sample Manifest

apiVersion: v1
kind: Secret
metadata:
  namespace: lumenvox
  name: rabbitmq-existing-secret
type: Opaque
data:
  rabbitmq-password: EXAMPLE241901SNSJKvzw2
---
apiVersion: v1
kind: Secret
metadata:
  namespace: lumenvox
  name: postgres-existing-secret
type: Opaque
data:
  postgresql-password: EXAMPLE241901SNSJKvzw2
  postgresql-postgres-password: EXAMPLE241901SNSJKvzw2
---
apiVersion: v1
kind: Secret
metadata:
  namespace: lumenvox
  name: redis-existing-secret
type: Opaque
data:
  redis-password: EXAMPLE241901SNSJKvzw2
---
apiVersion: v1
kind: Secret
metadata:
  namespace: lumenvox
  name: mongodb-existing-secret
type: Opaque
data:
  mongodb-root-password: EXAMPLE241901SNSJKvzw2
---


Applying the Manifest

Save the manifest as secrets.yaml and apply it with:

kubectl apply -f secrets.yaml

Verify that all four secrets exist in the namespace:

kubectl get secrets -n lumenvox

You should see rabbitmq-existing-secret, postgres-existing-secret, redis-existing-secret, and mongodb-existing-secret in the output.

stringData vs. data

This example uses stringData, which accepts plaintext values that Kubernetes encodes automatically before storing. If you prefer to provide pre-encoded values, replace stringData with data and encode each password in base64. For example, on Linux or macOS:

echo -n 'MyPassword' | base64

The output is the base64 string you would place under data. Use echo -n (no trailing newline) to avoid encoding a newline character into the secret.

Security Notes

  • Do not commit this file to source control with real credentials. Keep production manifests in a secrets manager (such as Vault, AWS Secrets Manager, or Sealed Secrets) and inject the values at deploy time.
  • The Kubernetes Secrets created by this manifest are stored base64-encoded at rest in etcd. Enable encryption at rest for your cluster if it is not already configured.
  • Restrict RBAC access to Secrets in the platform namespace to the minimum set of users and service accounts that need them.

Related Articles

Was this article helpful?