_Secrets and Passwords

Important Note: The procedure described on this page has been deprecated.

This page describes how to manage Black Duck secrets in Kubernetes/OpenShift when Black Duck is not deployed with Synopsys Operator.

Do not use these instructions for Black Duck instances deployed with Synopsys Operator.

The documentation below is provided only for historical purposes, and should not be followed unless instructed to by Synopsys support personnel.

Deprecated: Managing Secrets and Passwords on Kubernetes and OpenShift

If you installed Black Duck in Kubernetes/OpenShift using Synopsys Operator (this is the recommended installation mechanism), then all secrets (and passwords) were created for you automatically.

This page describes how to view and change Black Duck secrets after Black Duck is installed.

Note: Passwords are stored as secrets.

Managing Secrets

On any Black Duck instance that you have created, you can view secrets by running:

kubectl get secrets -n <black-duck-namespace>

You can modify a secret with the command:

kubectl edit secret <name-of-secret> -n <black-duck-namespace>

Common Use Cases

The following use cases are covered:

• Changing Black Duck Passwords
• Authenticated Proxy Passwords
• Web Server Custom Certificate and Key
• Supporting Custom Certificate Authorities
• LDAP Trust Store Password

Changing Black Duck Passwords

After setting up Black Duck, you may wish to expose your Black Duck UI to the external world. If you do this, you should modify the default password for security purposes.

After installing Synopsys Operator, you can modify the default Black Duck and Postgres passwords used for newly created Black Duck instances by editing the blackduck-secret secret in the namespace where the Synopsys operator is running. Note that the passwords are encoded in base64 and thus if you change any of the passwords, you must be sure to provide the new passwords in base64 encoding. Newly created Black Duck instances will use these credentials. If you want already-existing Black Duck instances to use your new credentials, you will have to restart the affected Black Duck pods (authentication and/or postgres, depending on which passwords you changed).

Authenticated Proxy Passwords

If you use an external proxy that requires authentication, you can add the proxy password as a secret to the following services:

• authentication
• jobrunner
• registration
• scan
• webapp

In each of these pod specifications, you will need to add the secret injection next to the image that is using them, for example:

        image: hub-webapp:4.2.0
        env:
            - name: HUB_PROXY_PASSWORD_FILE
              valueFrom:
              secretKeyRef:
                name: db_user
                key: password

This secret references a db_user secret that would be created beforehand, for example:

kubectl create secret generic db_user --from-file=./username.txt --from-file=./password.txt

Note: Alternatively, you can specify an environment variable called RUN_SECRETS_DIR that references a directory (e.g., /run/secrets) that contains a file HUB_PROXY_PASSWORD_FILE. Put the password in that file.

Web Server Custom Certificate and Key

If you want to import a custom cert into your Black Duck web server, then can use the procedure below to modify the webserver (nginx) certificate and key. This allows the use of custom web server certificate-key pairs for establishing SSL connections to your Black Duck web server.

To do import a customer cert, create the following two Kubernetes secrets:

1. WEBSERVER_CUSTOM_CERT_FILE
2. WEBSERVER_CUSTOM_KEY_FILE with the custom certificate and custom key in your namespace.

You can do so with the commands:

kubectl secret create WEBSERVER_CUSTOM_CERT_FILE --from-file=<certificate file>
kubectl secret create WEBSERVER_CUSTOM_KEY_FILE --from-file=<key file>

Note: Alternatively you could achieve the same end by creating a configmap/secret that can hold data necessary for injecting your organization's credentials into nginx. For example:

apiVersion: v1
items:
- apiVersion: v1
  kind: ConfigMap
    metadata:
      name: certs
      namespace: customer1
  data:
    WEBSERVER_CUSTOM_CERT_FILE: |
      -----BEGIN CERTIFICATE-----
      ... (insert certs of your organization here)
      -----END CERTIFICATE-----
    WEBSERVER_CUSTOM_KEY_FILE: |
      -----BEGIN PRIVATE KEY-----
      ... (insert SSL keys of your organization here)
      -----END PRIVATE KEY-----

Then create that config map:

kubectl create -f nginx.yml

And update the nginx pod segment for nginx, adding the following volume/volume-mount pair:

volumes
- configMap:
      defaultMode: 420
      name: certs
    name: dir-certs
...
volumeMounts:
- mountPath: /run/secrets
  name: dir-certs

Supporting Custom Certificate Authorities

Black Duck allows users to use their own Certificate Authority (CA) for the certificate authentication. To enable this, users should add the volume mount to the webserver and the authentication service.

• Create a Kubernetes secret each called AUTH_CUSTOM_CA with the custom CA certificate in your namespace.

You can do so with the command:

kubectl secret create AUTH_CUSTOM_CA --from-file=<CA certificate file>

• Start the webserver container, and the authentication service.

• Once the Black Duck services are all up, make an API request which would return the JWT (JSON Web Token) with the certificate key pair that was signed with the trusted CA.

For example:

curl https://localhost:443/jwt/token --cert user.crt --key user.key

Note: The username of the certificate used for authentication must exist in the Black Duck system as its Common Name.

For the webserver service, add secrets by copying their values into 'env' values for the pod specifications in the webserver.

LDAP Trust Store Password

There are two methods for specifying an LDAP trust store password:

1. Specify an environment variable called LDAP_TRUST_STORE_PASSWORD that contains the password.
2. Mount a directory that contains a file called 'LDAP_TRUST_STORE_PASSWORD_FILE' to /run/secrets.

This configuration is needed only when adding a custom Black Duck web application trust store.