Kubernetes credentials: create and inspect Secrets

Use this workflow for Lab 4 API credentials, PostgreSQL, and student-managed production credentials in Lab 5. The assignment specifies each Secret's name, keys and consumers. Commands below use a Bash-style shell; adapt them for PowerShell.

Create once, outside Git

Choose one teammate to create each student-managed Secret in the target namespace (group-N-staging below; group-N for production). Generate a different long random password for each account, using a password manager or openssl rand -base64 32. Never reuse the public local/test passwords. Teammates retrieve existing values through their own cluster access when needed; do not send passwords through chat or recreate shared Secrets.

Lab 5's production gamehost credentials are an exception: staff already provision colony-basic-auth. Reference its keys directly; do not generate a replacement password. Group A still creates its own production POI viewer credentials, with a different username.

For example, this creates Group B's API Secret without typing a password into shell history:

kubectl create secret generic logic-api-credentials -n group-N-staging \
  --from-literal=GAMEHOST_USERNAME=group-N \
  --from-literal=GAMEHOST_PASSWORD="$(openssl rand -base64 32)"

Replace N. Group A: before running the command, extend it with --from-literal=POI_USERNAME="<your-viewer-name>" and --from-literal=POI_PASSWORD="$(openssl rand -base64 32)", preserving the shell's line continuations. Use your chosen username, not the angle-bracket placeholder.

For an existing password, prompt into a variable rather than putting its literal value in the command. In Bash, read -r -s -p 'Password: ' PASSWORD; printf '\n' reads without echoing; pass --from-literal=KEY="$PASSWORD", then unset PASSWORD. Do not enable shell tracing (set -x). --from-file preserves every byte of a file, including a trailing newline if present; that newline becomes part of the credential. --from-literal with the quoted values above avoids that pitfall.

These commands create new Secrets, not rotations. If a name already exists, inspect it and coordinate with teammates instead of deleting or replacing it blindly. Environment values in running containers do not automatically change when the Secret changes. Database passwords also need changing in the database itself, not just in the Secret.

Inspect privately

Check the namespace and key names with:

kubectl get secret logic-api-credentials -n group-N-staging -o yaml

The values are base64-encoded, not encrypted. Treat this output as credentials: keep it out of Git, CI logs, screenshots and submissions. Applications should use secretKeyRef; do not copy decoded passwords into Helm values or Deployment manifests.

For a local HTTP client or pgAdmin, decode just the key you need. Substitute the Secret name and key from the relevant assignment:

kubectl get secret logic-api-credentials -n group-N-staging \
  -o jsonpath='{.data.GAMEHOST_PASSWORD}' | base64 --decode

This prints plaintext. Keep the terminal private; use a local client environment for staging credentials, not an exported Postman collection. For PostgreSQL's application password, use Secret logic-db-credentials and key CUSTOM_PASSWORD.

PowerShell, for the same API password:

$secret = kubectl get secret logic-api-credentials -n group-N-staging -o json | ConvertFrom-Json
[System.Text.Encoding]::UTF8.GetString([System.Convert]::FromBase64String($secret.data.GAMEHOST_PASSWORD))

See Kubernetes' Secret creation and Secret-backed environment variables.