Managing security for your Watson Knowledge Studio data stores

You can manage the access credentials for your MinIO, PostgreSQL, etc, and nosql data stores by creating secrets objects for each data store. Secrets are generated automatically during installation. You can create new credentials after installation. You can also rotate your credentials at any time for added security. Creating secrets objects for your data stores is optional. Support for this function was added with the 4.6.2 release.

Permissions you need for these tasks:: You must be an administrator of the Red Hat® OpenShift® project to manage the cluster.

Updating secrets objects for your data stores

The following procedures describe how to update the secrets objects for each data source individually. Use these steps to change the secrets for your data stores after you install the service or to rotate the secrets for added security.

Note: Because Watson Knowledge Studio depends on third-party data stores, they are limited by the password policies that the data stores enforce. For more information about restrictions on the length of passwords and the characters they can include, see the documentation for the data stores.

Prerequisite step

Before you re-create secrets objects, you must shut down the Watson Knowledge Studio service.

Back up the data stores by using the backup script that is described in Backup and restore data. Store the backups in a safe location.
Shut down the Watson Knowledge Studio service by editing your custom resource with the following command:
```
oc patch KnowledgeStudio wks --type=merge \
--patch='{"spec":{"global":{"quiesceMode":true}}}'
```
Save the change to the custom resource.
Use the procedures in the following sections to create new secrets objects for the data stores.

Attention: Change the names of only the passwords and secrets. Do not change the user names that are associated with those passwords and secrets.

Creating a secrets object for your PostgreSQL data store

Complete the prerequisite step to quiesce the service first.
Create the new secret by using the oc create secret command.
```
oc create secret generic new-auth-secret-name \
--from-literal=username=postgres --from-literal=password=new-postgres-password
```
where the following values are specified:
- new-auth-secret-name is a new secret name, such as credentials-psql.
- new-postgres-password is replaced by the new password value.
Note: The postgres user name is a fixed value. Do not change it.

Create a patch to apply the new secret to the service.

oc patch KnowledgeStudio wks --type=merge \
--patch='{"spec":{"global":{"postgresql":{"authSecret":{"fixedName":"new-auth-secret-name"}}}}}'

Now that new credentials exist, you can delete the previous secret.
```
oc delete secret old-auth-secret-name
```
To delete the secret that is generated by the installation process, use the following command:
```
oc delete secret wks-edb-postgresql-auth-secret
```

Creating a secrets object for your MinIO data store

Complete the prerequisite step to quiesce the service first.
Create the new secret by using the oc create secret command.
```
oc create secret generic new-auth-secret-name \
--from-literal=accesskey=new-access-key --from-literal=secretkey=new-secret-key
```
where the following values are specified:
- new-auth-secret-name is a new secret name, such as credentials-minio.
- new-access-key is replaced by the new access key value.
- new-secret-key is replaced by the new secret key value.

Create a patch to apply the new secret to the service.

oc patch KnowledgeStudio wks --type=merge --patch='{"spec":{"global":{"s3":{"accessSecret":{"fixedName":"new-auth-secret-name"}}}}}'

Now that new credentials exist, you can delete the previous secret.
```
oc delete secret old-auth-secret-name
```
To delete the secret that is generated by the installation process, use the following command:
```
oc delete secret minio-access-secret-wks
```

Creating a secrets object for your nosql data store

Complete the prerequisite step to quiesce the service first.
Create the new secret by using the oc create secret command.
```
oc create secret generic new-auth-secret-name --from-literal=user=admin --from-literal=password=new-nosql-password
```
where the following values are specified:
- new-auth-secret-name is a new secret name, such as credentials-nosql.
- new-nosql-password is replaced by the new password value.
Note: The admin user name is a fixed value. Do not change it.

Create a patch to apply the new secret to the service.

oc patch KnowledgeStudio wks --type=merge \
--patch='{"spec":{"mongodb":{"auth":{"oldAuthSecretName":"old-auth-secret-name","authSecretName":"new-auth-secret-name"}}}}'

where old-auth-secret-name is the current secret name, such as wks-ibm-mongodb-auth-secret.

Wait until the new secret is applied. Check that the database pods are rotated by using the following command.

oc get pods -lapp.kubernetes.io/name=ibm-mongodb,app.kubernetes.io/instance=wks

Remove the following patch entry:

 oc patch KnowledgeStudio wks --type=json \
--patch='[{"op":"remove","path":"/spec/mongodb/auth/oldAuthSecretName"}]'

Creating a secrets object for your etcd data store

Do not create a secrets object or perform any rotation of credentials for the etcd service while the service is quiesced or shut down. Only when the service is up and running, complete the following steps to re-create the secrets object for etcd.

The etcd operator requires both credentials to exist in the namespace to perform rotation. Do not delete the existing credentials until after the new credentials are created.

Verify that the etcd pods are up and running.

oc get pods -lapp=etcd,app.kubernetes.io/instance=wks

Create the new secret by using the oc create secret command.
```
oc create secret generic new-auth-secret-name \
--from-literal=username=root --from-literal=password=new-etcd-password
```
where the following values are specified:
- new-auth-secret-name is a new secret name, such as credentials-etcd.
- new-etcd-password is replaced by the new password value.
Note: The root user name is a fixed value. Do not change it.

Create a patch to apply the new secret to the service.

oc patch KnowledgeStudio wks --type=merge \
--patch='{"spec":{"global":{"etcd":{"authSecret":"new-auth-secret-name"}}}}'

Monitor the etcd pods as they restart after the credential is rotated internally.
```
oc get pods -lapp=etcd,app.kubernetes.io/instance=wks
```

Restarting the service

Restart the Watson Knowledge Studio service by editing your custom resource with the following command:
```
oc patch KnowledgeStudio wks --type=merge \
--patch='{"spec":{"global":{"quiesceMode":false}}}'
```
Save the change to the custom resource.
Wait for the services to restart and verify that all of the pods that are listed by the following command are in a Ready state.
```
oc get pods -l 'release in (wks,wks-minio,wks-ibm-watson-ks)'
```