Managing security for your Watson Speech services datastores

You can manage the access credentials for your MinIO, PostgreSQL, and RabbitMQ datastores by creating secrets objects for each datastore. You can create the credentials before you install Watson Speech services or update them after installation. You can also rotate your credentials for added security. Creating secrets objects for your datastores is optional. Secrets are generated automatically during installation if you do not create your own.

Note: The PostgreSQL and RabbitMQ datastores are installed only with some microservices. For information about the microservices that depend on these datastores, see Datastores properties.
Permissions you need for these tasks:
You must be an administrator of the Red Hat® OpenShift® project to manage the cluster.

Datastore management topics

For information about creating secrets objects for your datastores before you install Watson Speech services, see:

For information about creating secrets objects for your datastores after you install Watson Speech services, see:

You can also use the information in the second topic to rotate the credentials for your datastores at any time after installation.

To modify your datastores, you edit your custom resource. For more information, see Editing the custom resource.

Note: Because Watson Speech services depend on third-party datastores, they are limited by the password policies that the datastores enforce. For more information about restrictions on the length of passwords and the characters they can include, see the documentation for the datastores or contact your IBM Support representative.

Creating secrets objects for your datastores before you install the Speech services

To access the MinIO, PostgreSQL, or RabbitMQ datastore, the installation reads credentials from a secrets file. By default, the installation creates objects that contain randomly generated password when you install the Speech services. However, you can use the instructions in the following sections to specify the security secrets for the datastores before you install the Speech services:

Creating a secrets object for your MinIO datastore

MinIO object storage is used to store persistent data that is needed by the Speech services microservices. For information about the data that MinIO stores, see Configuring the MinIO datastore.

To specify the security secrets for the MinIO datastore, create a YAML file (for example, user-provided-minio.yaml) that has the following contents:

apiVersion: v1
kind: Secret
type: Opaque
metadata:
  name: <speech-cr>-ibm-minio-auth
data:
  accesskey: <base64-encoded-accesskey>
  secretkey: <base64-encoded-secretkey>

Use the following steps to specify the values for the secrets object:

  1. Set the value of the name property in the YAML file to <speech-cr>-ibm-minio-auth to match the default name that is used for the property global.datastores.minio.authSecretName in the Speech services custom resource. You must use this value for the name property when you create the secrets before installation.

  2. Create an accesskey (5-20 characters) and encode the value in base64. The following command encodes the value access1234 in base64. Use a different value for the accesskey that you encode.

    echo -n "access1234" | base64
    YWNjZXNzMTIzNAo=
  3. Create a secretkey (8-40 characters) and encode the value in base64. The following command encodes the value secret1234 in base64. Use a different value for the secretkey that you encode.

    echo -n "secret1234" | base64
    c2VjcmV0MTIzNAo=

To create the secrets object from the YAML file, run the following command, where user-provided-minio.yaml is the name of the YAML file that you created for the secrets object:

kubectl create -f user-provided-minio.yaml

Creating a secrets object for your PostgreSQL datastore

PostgreSQL object storage is used to store persistent data that is needed by the Speech services microservices. For information about the data that PostgreSQL stores, see Configuring the PostgreSQL datastore.

To specify the security secrets for the PostgreSQL datastore, create a YAML file (for example, user-provided-postgressql.yaml) that has the following contents:

apiVersion: v1
kind: Secret
type: kubernetes.io/basic-auth
metadata:
  name: <speech-cr>-postgres-auth-secret
  namespace: <namespace>
data:
  password: <base64-encoded-password>
  username: cG9zdGdyZXM=

Use the following steps to specify the values for the secrets object:

  1. Set the value of the name property in the YAML file to <speech-cr>-postgres-auth-secret to match the default name that is used for the property global.datastores.postgres.authSecretName in the Speech services custom resource. You must use this value for the name property when you create the secrets before installation.

  2. Set the value of the namespace property to the name of the project (the namespace) where you plan to install the Speech services.

  3. Create a password and encode the value in base64. The following command encodes the value password1234 in base64. Use a different value for the password that you encode.

    echo -n "password1234" | base64
    cGFzc3dvcmQxMjM0Cg==
  4. Set the value of the username property to cG9zdGdyZXM=, which is postgres in base64. Do not change this value.

To create the secrets object from the YAML file, run the following command, where user-provided-postgressql.yaml is the name of the YAML file that you created for the secrets object:

kubectl create -f user-provided-postgressql.yaml

Creating a secrets object for your RabbitMQ datastore

The RabbitMQ datastore handles non-persistent message queuing for the Speech to Text asynchronous HTTP microservice (sttAsync). It is used only if the sttAsync microservice is installed and enabled. For information about the RabbitMQ datastore, see Configuring the RabbitMQ datastore.

To specify the security secrets for the RabbitMQ datastore, create a YAML file (for example, user-provided-rabbitmq.yaml) that has the following contents:

apiVersion: v1
kind: Secret
type: Opaque
metadata:
  name: <speech-cr>-ibm-rabbitmq-auth-secret
data:
  definitions.json: <base64-encoded-definitions>
  rabbitmq-erlang-cookie: <base64-encoded-cookie>
  rabbitmq-management-password: <base64-encoded-management-password>
  rabbitmq-password: <base64-encoded-admin-password>

Use the following steps to specify the values for the secrets object:

  1. Set the value of the name property in the YAML file to speech-cr-ibm-rabbitmq-auth-secret to match the default name that is used for the property global.datastores.rabbitMQ.authSecretName in the Speech services custom resource. You must use this value for the name property when you create the secrets before installation.

  2. Create a rabbitmq-management-password (management password) and rabbitmq-password (admin password) and encode the values in base64. The following example encodes the string rabbitmq123 in base64:

    echo -n "rabbitmq123" | base64
    cmFiYml0bXExMjM=

    This procedure uses the same password for rabbitmq-management-password and rabbitmq-password. You can use different values for the two passwords. If you do, you must base64-encode both passwords, you must specify the encoded values for the appropriate properties of the YAML file, and you must specify the correct values for the management and admin passwords in the value for the definitions.json property in the following step.

  3. Create the following base64-encoded value for the definitions.json property. In the command, replace rabbitmq123 with the unencoded management and admin passwords that you created in the previous step.

    echo -n {users: [{name: management, : rabbitmq123, tags: management}, \
    {name: admin, password: rabbitmq123, tags: administrator}], vhosts: [{name: /}], \
    permissions: [{user: admin, vhost: /, configure: .*, read: .*, write: .*}], \
    parameters: [], policies: [{name: ha-all, pattern: .*, vhost: /, definition: \
    {ha-mode: all, ha-sync-mode: automatic, ha-sync-batch-size: 1}}], queues: [], \
    exchanges: [], bindings: []} | base64

    The command generates a long base64-encoded value. The following example uses line breaks to make the encoded value readable, but the value that you generate is a single string that you must include on a single line for the definitions.json property.

    e3VzZXJzOiBbe25hbWU6IG1hbmFnZW1lbnQsIHBhc3N3b3JkOiByYWJiaXRtcTEyMywgdGFnczogbWFuYWdlbW
    VudH0sIHtuYW1lOiBhZG1pbiwgcGFzc3dvcmQ6IHJhYmJpdG1xMTIzLCB0YWdzOiBhZG1pbmlzdHJhdG9yfV0s
    IHZob3N0czogW3tuYW1lOiAvfV0sIHBlcm1pc3Npb25zOiBbe3VzZXI6IGFkbWluLCB2aG9zdDogLywgY29uZm
    lndXJlOiAuKiwgcmVhZDogLiosIHdyaXRlOiAuKn1dLCBwYXJhbWV0ZXJzOiBbXSwgcG9saWNpZXM6IFt7bmFt
    ZTogaGEtYWxsLCBwYXR0ZXJuOiAuKiwgdmhvc3Q6IC8sIGRlZmluaXRpb246IHtoYS1tb2RlOiBhbGwsIGhhLX
    N5bmMtbW9kZTogYXV0b21hdGljLCBoYS1zeW5jLWJhdGNoLXNpemU6IDF9fV0sIHF1ZXVlczogW10sIGV4Y2hh
    bmdlczogW10sIGJpbmRpbmdzOiBbXX0=
  4. Generate a random 32-character value for the rabbitmq-erlang-cookie. The Erlang cookie is a string of alphanumeric characters that is used for communication between nodes in a RabbitMQ cluster and by different RabbitMQ command-line tools. Base64-encode the value for the cookie.

    openssl rand -base64 32
    DNk2rpcm5tTlH0477/O71V/b4dITZHt4cNsjZ6JNDH0=

An example of the YAML file that is created by these steps follows. The example uses the same encoded value for the rabbitmq-management-password and the rabbitmq-password properties. As mentioned previously, you can use different values for the two passwords, and the value for the definitions.json property must appear on a single line.

apiVersion: v1
kind: Secret
type: Opaque
metadata:
  name: <speech-cr>-ibm-rabbitmq-auth-secret
data:
  definitions.json: e3VzZXJzOiBbe25hbWU6IG1hbmFnZW1lbnQsIHBhc3N3b3JkOiByYWJiaXRtcTEyMywgdGF
nczogbWFuYWdlbWVudH0sIHtuYW1lOiBhZG1pbiwgcGFzc3dvcmQ6IHJhYmJpdG1xMTIzLCB0YWdzOiBhZG1pbmlzdH
JhdG9yfV0sIHZob3N0czogW3tuYW1lOiAvfV0sIHBlcm1pc3Npb25zOiBbe3VzZXI6IGFkbWluLCB2aG9zdDogLywgY
29uZmlndXJlOiAuKiwgcmVhZDogLiosIHdyaXRlOiAuKn1dLCBwYXJhbWV0ZXJzOiBbXSwgcG9saWNpZXM6IFt7bmFt
ZTogaGEtYWxsLCBwYXR0ZXJuOiAuKiwgdmhvc3Q6IC8sIGRlZmluaXRpb246IHtoYS1tb2RlOiBhbGwsIGhhLXN5bmM
tbW9kZTogYXV0b21hdGljLCBoYS1zeW5jLWJhdGNoLXNpemU6IDF9fV0sIHF1ZXVlczogW10sIGV4Y2hhbmdlczogW1
0sIGJpbmRpbmdzOiBbXX0=
  rabbitmq-erlang-cookie: DNk2rpcm5tTlH0477/O71V/b4dITZHt4cNsjZ6JNDH0=
  rabbitmq-management-password: cmFiYml0bXExMjM=
  rabbitmq-password: cmFiYml0bXExMjM=

To create the secrets object from the YAML file, run the following command, where user-provided-rabbitmq.yaml is the name of the YAML file that you created for the secrets object:

kubectl create -f user-provided-rabbitmq.yaml

Updating secrets objects for your datastores after you install the Speech services

When you install Watson Speech services, you can either create your own credentials before installation or let the service create them for you during installation. You can update the access credentials for your datastores at any time after you install Watson Speech services.

The following procedure documents how to re-create the secrets objects for all three datastores at once. But you can update the secrets objects individually if you want. (Rather than duplicate information, the steps rely on other procedures from the documentation.)

You can follow this same procedure to rotate the credentials for your datastores. You can create new secrets objects on a periodic basis to provide greater security for your datastores.

  1. Back up the data stores by using the import and export utilities described in Backing up and restoring Watson Speech services data. Store the backups in a safe location.

  2. Shut down the Watson Speech services by adding a property to the custom resource. Edit the custom resource by using the following command:

    oc edit watsonspeech ${CUSTOM_RESOURCE_SPEECH} -n ${PROJECT_CPD_INSTANCE}
  3. Add the shutdown: true property beneath the spec tag:

    spec:
      shutdown: true

    Save the change to the custom resource.

  4. Wait for the Watson Speech services to shut down. To check the status of the services, enter the following command:

    oc get watsonspeech ${CUSTOM_RESOURCE_SPEECH} -n ${PROJECT_CPD_INSTANCE} \
        -o 'jsonpath={.status.speechStatus}'

    The services are shut down when the command returns the status shutdown.

  5. Use the procedures in the previous sections to create new secrets objects for the datastores:

    To preserve the existing objects, choose new names for the secrets objects. If you use new names, you must update the authSecretName property for each datastore in the custom resource.

    Note: Change the names of only the passwords and secrets. Do not change the usernames that are associated with those passwords and secrets.
  6. Restart the Watson Speech services by reverting the previous shutdown step. Edit the custom resource by using the following command:

    oc edit watsonspeech ${CUSTOM_RESOURCE_SPEECH} -n ${PROJECT_CPD_INSTANCE}
  7. Change the value of the property that you added previously to shutdown: false:

    spec:
      shutdown: false

    Save the change to the custom resource.

  8. Wait for the Watson Speech services to restart. To check the status of the services, enter the following command:

    oc get watsonspeech ${CUSTOM_RESOURCE_SPEECH} -n ${PROJECT_CPD_INSTANCE} \
        -o 'jsonpath={.status.speechStatus}'

    The services are running again when the command returns the status Completed.

  9. Use the curl commands described in Verifying a service instance to ensure that the Watson Speech services are functional and that all previous data is intact and reachable.

If you used new names for the secrets objects and you no longer need the old objects, you can delete them by running the following command once for each object. In the command, <auth-secret-name> is the name of the secrets object that you want to delete.

oc delete secret <auth-secret-name> -n ${PROJECT_CPD_INSTANCE}>