Required Secrets

Managing Secrets Securely

You can manage secrets using two primary approaches:

• Helm-Managed Secrets: Define secrets in the systemlink-secrets.yaml file. You deploy secrets to the Kubernetes cluster as part of the Helm installation. This approach is simpler to configure but requires additional steps to encrypt the secrets file for secure storage in version control.
• External Secret Management: Store and manage secrets in an external secret management system such as HashiCorp Vault, AWS Secrets Manager, or Azure Key Vault. The secrets are synchronized to the Kubernetes cluster using tools like the External Secrets Operator. This approach provides centralized secret management.

Helm-Managed Secrets with Encrypted Values Files

When using Helm to manage secrets, configure the global.deploySecrets parameter to true in systemlink-values.yaml. Define secrets in the systemlink-secrets.yaml file and deployed to the cluster during Helm installation or upgrade.

To securely store the systemlink-secrets.yaml file in version control, you must encrypt it. One approach is to use the Helm Secrets plugin with Mozilla SOPS (Secrets OPerationS).

The Helm Secrets plugin integrates with Mozilla SOPS to encrypt and decrypt Helm values files. SOPS supports multiple encryption backends including AWS KMS, Azure Key Vault, Google Cloud KMS, and PGP.

To use Helm Secrets:

1. Install the Helm Secrets plugin:

   helm plugin install https://github.com/jkroepke/helm-secrets --version <version>

2. Install Mozilla SOPS following the SOPS installation instructions.
3. Configure your encryption backend (AWS KMS, Azure Key Vault, GCP KMS, or PGP). Refer to the SOPS documentation for configuration details.
4. Encrypt your systemlink-secrets.yaml file:

   helm secrets encrypt systemlink-secrets.yaml

5. Deploy SystemLink Enterprise using helm secrets upgrade instead of helm upgrade commands. The Helm Secrets plugin automatically decrypts the encrypted values file during deployment.

You can commit the encrypted systemlink-secrets.yaml file safely to version control.

External Secret Management Tools

External secret management tools provide centralized storage and management of secrets outside of the Kubernetes cluster. Secrets are synchronized to Kubernetes using operators or agents. When using external secret management, set global.deploySecrets parameter to false in systemlink-values.yaml to prevent Helm from deploying secrets.

The External Secrets Operator is a Kubernetes operator that synchronizes secrets from external secret management systems to Kubernetes Secret objects. The operator supports multiple backends including HashiCorp Vault, AWS Secrets Manager, Azure Key Vault, Google Cloud Secret Manager, and others.

To use the External Secrets Operator:

1. Install the External Secrets Operator in your Kubernetes cluster following the installation guide.
2. Configure a SecretStore or ClusterSecretStore resource that defines the connection to your external secret management system. Refer to the provider-specific documentation for configuration details.
3. Create ExternalSecret resources for each SystemLink Enterprise secret. The operator will synchronize the secrets from your external system to Kubernetes.
4. Set global.deploySecrets: false in systemlink-values.yaml.
5. Deploy SystemLink Enterprise using Helm.

Security Best Practices

For more information on Kubernetes secrets and security, refer to the Kubernetes Secrets documentation and the Kubernetes Good Practices for Secrets.

Secret Format Examples

This section provides examples of generating secrets and viewing secrets in Kubernetes. Secrets are stored in base64-encoded format in the cluster.

Generating Encryption Keys:

Use OpenSSL or similar tools to generate cryptographically secure random keys.

• AES-256 Keys (32 bytes):

  openssl rand -base64 32

  Example output:

  h8F3mK9pL2nQ7vR4tY6uE1wX5zA8bC0dD2fG4hJ6k=

• AES-128 Keys (16 bytes):

  openssl rand -base64 16
  

  Example output:

  mK9pL2nQ7vR4tY6u

• AEAD Keys (32 bytes):

  openssl rand -base64 32
  

  Example output:

  p2sT4uV5wX8yA9bC0dD2fG4hJ6kL7mN9qR2sT5vW8=

• SHA-256 Signature Keys (32-64 bytes):

  openssl rand -base64 48
  

  Example output:

  G4hJ6kL7mN9qR2sT4uV5wX8yA9bC0dD2fG4hJ6kL7mN9qR2sT4uV5wX8yA9b

• Whitelisted API Keys (42 bytes):

  openssl rand -base64 42
  

  Example output:

  kL7mN9qR2sT4uV5wX8yA9bC0dD2fG4hJ6kL7mN9qR2sT4uV5w=

• MongoDB Replica Set Key:

  MongoDB replica set keys are used to authenticate pods in the database cluster. Refer to the MongoDB documentation for key generation instructions.

• RabbitMQ Erlang Cookie:

  openssl rand -hex 32
  

  Example output:

  a1b2c3d4e5f6a1b2c3d4e5f6a1b2c3d4e5f6a1b2c3d4e5f6a1b2c3d4e5f6a1b2

• RSA Keys for Salt Master:

  Used for Salt master communication with minions. Must be in PKCS1 format.

  # Generate RSA private key (4096-bit)
  openssl genrsa 4096
  # Generate RSA public key from private key
  openssl rsa -in private_key.pem -pubout -outform PEM
  

  Example private key:

  -----BEGIN RSA PRIVATE KEY-----
  MIIJKAIBAAKCAgEA1234567890abcdefghijklmnopqrstuvwxyzABCDEFGHIJKL
  ...
  -----END RSA PRIVATE KEY-----
  

  Example public key:

  -----BEGIN PUBLIC KEY-----
  MIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEA1234567890abcdefgh
  ...
  -----END PUBLIC KEY-----

• MongoDB Connection String Format:

  Refer to Configuring MongoDB for SystemLink Enterprise for connection string examples and formats.

• PostgreSQL Connection String Format:

  Refer to PostgreSQL for connection string examples and configuration details.

• Viewing Secrets in Kubernetes:

  Use kubectl to view secrets deployed to the cluster. Secret data is base64-encoded:

  # View a secret in YAML format
  kubectl get secret webserver-session -n systemlink -o yaml
  

  Example output:

  apiVersion: v1
  kind: Secret
  metadata:
    name: webserver-apikey
    namespace: systemlink
  type: Opaque
  data:
    encryptionKey: aDhGM21LOXBMMm5RN3ZSNHRZNnVFMXdYNXpBOGJDMGQ=
    signatureKey: RDJmRzRoSjZrN21MOHBOOXFSMnNUNHVWNXdYOHlBOWI=
  

  Decode a secret value:

  kubectl get secret webserver-session -n systemlink -o jsonpath='{.data.encryptionKey}' | base64 -d

• Creating Secrets Manually:

  When not using Helm-managed secrets, create secrets directly with kubectl:

  # Create a secret with multiple fields
  kubectl create secret generic oidc-secret \
    --from-literal=clientId='my-client-id' \
    --from-literal=clientSecret='my-client-secret' \
    --from-literal=jwks='' \
    -n systemlink

Image Pull Secrets

The NI container repository that hosts SystemLink Enterprise is private and requires authenticated access. You will have received credentials with access to SystemLink Enterprise. Configure image pull secrets for SystemLink Enterprise using the global.imagePullSecrets array in systemlink-values.yaml and systemlink-admin-values.yaml. Image pull secrets must conform to the kubernetes.io/dockerconfigjson format.

Authentication Secrets

Whitelisted API Keys

Whitelisted API Key Hashes

Encryption Keys

Elasticsearch Credentials

Dremio Credentials

Grafana Credentials

MongoDB Credentials

All MongoDB instances store the credentials in a secret with the following fields:

• mongodb-root-password: A password that grants root access to the database cluster.
• mongodb-passwords: An array of passwords that each grant full access to an individual database. These passwords cannot contain commas or any reserved characters as defined by the IETF URL specification.
  Note Separate passwords with commas. Do not include whitespace or a trailing delimiter. For example: password1,password2. All MongoDB credential secrets except userservices-mongodb-credentials and saltmaster-mongodb-credentials require one password.
• mongodb-replica-set-key: A key used to authenticate nodes in a MongoDB replica set.
• mongodb-connection-string: The connection string, including credentials, for authentication to the MongoDB database.

PostgreSQL Credentials

Proxy Server Credentials

RabbitMQ Credentials

Redis Credentials

Amazon S3 Credentials

Azure Storage Credentials

SMTP Credentials