Managing custom trusted certificates
You can now import custom trusted certificates to Concert for TLS verification. Integrating trusted certificates across all deployment types involves adding them to a known location. In virtual machine (VM) deployments, there is a dedicated folder, while in Kubernetes, it is a specific secret. This method ensures consistent handling of certificates across different environments.
Before you begin
Concert uses an internal certificate authority (CA) bundle with all trusted certificates and during operations such as updates, Concert might regenerate its CA bundle. Therefore, any certificates that are added to the well-known locations should persist there. Later, if these certificates are removed, Concert may interpret this as you no longer require those certificates to be part of the CA bundle.
Adding invalid or corrupted certificates to Concert's CA bundle can have adverse effects. It may render the CA bundle unusable, leading to unexpected behavior, including constant restarts. Always exercise caution while updating the CA bundle to avoid such issues.
Before the CA bundle gets corrupted, you can backup Concert's private key, self-signed certificate, and CA bundle. The data that is saved on these backup 's critical to ensure that both Concert's internal communications and the connections toward external services are safe, and therefore they must be securely stored.
It is recommended to have a backup that is taken before triggering any update to Concert's CA bundle.
Backup and restore on VM
$ export CONCERT_TLS_DIR="<path_to_concert_std>/localstorage/volumes/infra/tls"
$ export BACKUP_FILE="${HOME}/concert-tls-backup.tar.gz"
$ tar cvzf "${HOME}/concert-tls-backup.tar.gz" -C "${CONCERT_TLS_DIR}" tls.key tls.crt tls-ca-bundle.pem
tls.key
tls.crt
tls-ca-bundle.pem
$ tar xzvf "${HOME}/concert-tls-backup.tar.gz" -C "${CONCERT_TLS_DIR}"
tls.key
tls.crt
tls-ca-bundle.pem
Backup and restore on Kubernetes
$ export CONCERT_NS=<your_concert_namespace>
$ export CONCERT_TLS_SECRET="${HOME}/app-cfg-internal-tls.yaml"
$ kubectl -n "${CONCERT_NS}" get secret app-cfg-internal-tls -oyaml > "${CONCERT_TLS_SECRET}"
$ kubectl -n "${CONCERT_NS}" apply -f "${CONCERT_TLS_SECRET}"
VM deployment and triggering CA bundle update
Copy any certificate that you want to add to Concert's CA bundle to localstorage/infra/custom-ca-certs
folder. If you want to remove
previously added certificates from the CA bundle, delete them from
localstorage/infra/custom-ca-certs
.
After modifying the contents of localstorage/infra/custom-ca-certs
folder, run
the cert-mgmt
script. The cert-mgmt
script is part of ibm-concert-std.tgz package that is published on Concert public GitHub.
Kubernetes deployments
Export the name of the namespace where Concert is deployed, so it can be referenced by using the following command:
$ export CONCERT_NS=<concert's namespace>
app-cfg-custom-ca-certs
exists in the namespace where
Concert is deployed. If it does not exist, you can
create it by using the following
command:$ kubectl --namespace "${CONCERT_NS}" create secret generic app-cfg-custom-ca-certs
Edit the secret to add any certificate that you want to add to the secret's data section. The key of each entry in this section is the name of the certificate file, and the value is the content of the certificate, encoded in base64 format.
$ kubectl --namespace "${CONCERT_NS}" edit secret app-cfg-custom-ca-certs
Triggering CA bundle on Kubernetes
$ MGMT_POD=$(kubectl --namespace "${CONCERT_NS}" get pods -o=name | grep 'roja-mgmt-' | head -n1)
$ kubectl --namespace "${CONCERT_NS}" exec -it "${MGMT_POD}" -- bash
bash-5.1$ ls /mnt/infra/custom-ca-certs
bash-5.1$ /app/bin/process_custom_ca_certs.sh
Adding more than one certificate to the CA bundle
To ensure that related certificates (such as a root CA and an intermediate CA) are added in the correct sequence within the CA bundle, they must be entered in the proper order. By doing so, Concert can correctly establish and maintain the desired certificate hierarchy.
$ ls /localstorage/volumes/infra/custom-ca-certs
00-server.crt
01-intermediate.crt
02-root.crt
Similarly, when dealing with Kubernetes secrets, it is essential to maintain consistent naming conventions for the keys within the data section.