Common Tasks

The sections provides information about common tasks that users and administrators may need to perform to manage SD Elements.

Helm

  • List all deployed charts:

    helm list

Kubernetes

  • List all SD Elements Pods:

    $ kubectl get pods
sde-1578433057-broker-b698dfcfb-55rnk                 1/1     Running       1          6d
sde-1578433057-cache-84fd48b88-4qsgl                  1/1     Running       1          6d
sde-1578433057-database-5c5fdf76d-jqzm6               1/1     Running       1          6d
sde-1578433057-mail-6977f6dfd-ln55j                   1/1     Running       1          6d
sde-1578433057-web-6c4d548c7d-bzjw9                   1/1     Running       1          6d
sde-1578433057-worker-10-7ddc88d5c-qlwdf              1/1     Running       5          6d
sde-1578433057-worker-15-sde-medium-c9bff4dbd-spkmc   1/1     Running       1          6d
sde-1578433057-worker-17-6754875844-gfkwk             1/1     Running       3          6d
sde-1578433057-worker-18-sde-low-6dfcf68c4d-98t54     1/1     Running       1          6d

  • Retreive pod logs:

    # Syntax
kubectl logs pod/<POD_NAME>
# Example
kubectl logs pod/sde-1578433057-broker-b698dfcfb-55rnk

  • Retrieve superuser login username:

    kubectl describe pods | grep 'SDE_SUPERUSER:' | sort -u

  • Retrieve superuser login password:

    # Syntax
kubectl get secrets "<HELM_RELEASE_NAME>-sde-secrets" --output jsonpath='{.data.SDE_SUPERUSER_PASSWORD}' | base64 -d
# Example
kubectl get secrets "prod-sde-secrets" --output jsonpath='{.data.SDE_SUPERUSER_PASSWORD}' | base64 -d

TLS/SSL certificates

Table 1. Supported Certificate Configurations

Public CA

Private CA

Self-signed

Ingress

Yes

Yes

Yes

Integrations

Yes

Optional

Optional

Enabling HTTPS

By default, SD Elements will not be configured to serve HTTPS traffic or encrypt traffic in transit. The SD Elements Helm chart supports three methods of supplying TLS certificates:

  1. Kubernetes TLS Secret

  2. Blob

  3. File paths

As of SD Elements version 2023.4, Kubernetes secrets are the preferred method of supplying TLS certificates.

Prerequisites:

  1. The domain set in sde.fqdn matches the common name (CN) or Subject Alternative Name (SAN) in the certificate

  2. sde.fqdn is set in values.custom.yaml

For Kubernetes Secret configuration, add the following lines to your values.custom.yaml file:

sde:
  fqdn: "example.com"
web:
  externalTlsSecretName: "my-k8s-tls-certificate-secret-name"
The Kubernetes TLS Secret must exist in the same namespace in which SD Elements is deployed.

For blob configuration, add the following lines to your values.custom.yaml file:

web:
  tlsCertificate: |-
    -----BEGIN CERTIFICATE-----
    MIIFWzCCA0OgAwIBAgIQTfQrldHumzpMLrM7jRBd1jANBgkqhkiG9w0BAQsFADBm
    MQswCQYDVQQGEwJVU ... <truncated> ... dJTkcpIEludGVybmV0IFNlY3Vy
    hSjpTUFGSiQrR2JK2Evp+o6AETUkBCO1aw0PpQBPDQ==
    -----END CERTIFICATE-----
  tlsKey: |-
    -----BEGIN PRIVATE KEY-----
    MIIFWzCCA0OgAwIBAgIQTfQrldHumzpMLrM7jRBd1jANBgkqhkiG9w0BAQsFADBm
    MQswCQYDVQQGEwJVU ... <truncated> ... dJTkcpIEludGVybmV0IFNlY3Vy
    hSjpTUFGSiQrR2JK2Evp+o6AETUkBCO1aw0PpQBPDQ==
    -----END PRIVATE KEY-----
  tlsCiphers: "ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256"
  tlsProtocols: "TLSv1 TLSv1.1 TLSv1.2

For file path configuration, add the following lines to your values.custom.yaml file:

web:
  tlsCertificatePath: files-static/myServerCert.pem
  tlsKeyPath: files-static/myServerKey.pem
  tlsCiphers: "ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256"
  tlsProtocols: "TLSv1 TLSv1.1 TLSv1.2

Third-party integration certificates

SD Elements containers have a list of trusted Certificate Authorities built into their operating systems. An administrator of SD Elements may choose to append CAs to this list to validate custom TLS certificates.

Allowing trusted CA Certificates is required

global:
  thirdPartyCACertificates:
    enabled: true

For blob configuration, add the following lines to your values.custom.yaml file:

global:
  thirdPartyCACertificates:
    enabled: true
    certs:
      mycert.crt: |-
        -----BEGIN CERTIFICATE-----
        MIIFWzCCA0OgAwIBAgIQTfQrldHumzpMLrM7jRBd1jANBgkqhkiG9w0BAQsFADBm
        MQswCQYDVQQGEwJVU ... <truncated> ... dJTkcpIEludGVybmV0IFNlY3Vy
        hSjpTUFGSiQrR2JK2Evp+o6AETUkBCO1aw0PpQBPDQ==
        -----END CERTIFICATE-----

For CA certificates generated by auxillary systems, configuration for the name of a Kubernetes ConfigMap or Secret is available. You may set either or both values, all certificates will be used.

global:
  thirdPartyCACertificates:
    enabled: true
    externalConfigMapName: "my-k8s-ca-certificate-configmap-name"
    externalSecretName: "my-k8s-ca-certificate-secret-name"
The certificate filenames must end in .crt to be used

Certificate rotation

TLS certificates have a pre-defined expiry set during creation. When the certificate expires, a new one must be issued and supplied to SD Elements. Rotation will require different steps depending on the use of the certificate and configuration method used when supplying the original certificate.

  • If the certificate is stored in a Kubernetes Secret, delete the existing TLS Secret containing the expired certificate and create a new Secret containing the new certificate’s contents and private key. If the Secret name is unchanged, no further action is required. Should the Secret name change, update web.externalTlsSecretName and use helm upgrade to apply the change.

  • If the certificate is supplied via blob or file path configuration, replace the relevant values in the values.custom.yaml file and use helm upgrade to apply the change.

Regardless of configuration method, if the certificate/CA is used to validate TLS for integrations the sde-worker-{number} deployments must be restarted so the new certificate/CA can be added to the pods' CA bundle. Deployments can be restarted using the kubectl rollout restart command. See this page from the official Kubernetes documentation for more information.

results matching ""

    No results matching ""