Closed lmsurpre closed 2 years ago
We will enable the user to pass in their own keystore and truststore files via Secrets. The following values will be added to the values.yaml
file to specify the Secret names:
keyStoreSecret
trustStoreSecret
For the keystore Secret, it will be expected to contain the content of the keystore file, the filename, and the password. The expected Secret keys are as follows:
Key | Value |
---|---|
fhirKeyStore |
The contents of the keystore file |
fhirKeyStoreFilename |
The name of the keystore file |
fhirKeyStorePassword |
The keystore password |
If a keystore secret is not specified, the default keystore will be used.
Small design update:
We will enable the user to pass in their own keystore and truststore files via Secrets. The following values will be added to the values.yaml
file to specify the Secret names and file formats:
keyStoreSecret
keyStoreFormat
trustStoreSecret
trustStoreFormat
For the keystore Secret, it will be expected to contain the content of the keystore file and the password. The expected Secret keys are as follows:
Key | Value |
---|---|
fhirKeyStore |
The contents of the keystore file |
fhirKeyStorePassword |
The keystore password |
If a keystore secret is not specified, the default keystore will be used.
The ibmcom/ibm-fhir-server docker image ships with a default self-signed certificate. This is handy because our fhir-client ships with a default truststore that is configured to trust the server. However, for real usage, this certificate should be replaced as needed for the target env.
As an example, the bitnami postgres chart has the following settings:
Liberty can auto-generate a TLS cert, so maybe it would be good to expose that?