Manage Security and Secrets
Ensure the security of your installation by creating a Secret to use for TLS communication between the Virtual Appliance and the backend HSM.
If you want to verify the HSM TLS connection or use client PKI for mutual TLS (mTLS), you need to create a Secret on your Kubernetes cluster.
You need to create a generic Secret containing the PKI files you want to use (such as PKCS #12 Bundles, PKCS #12 passwords, X.509 CAs, and CRLs). Do this with a kubectl command as shown.
The key names, such as p12Pass, need to be given to the helm install command so it understands the mapping. See the table in the Pod parameters section for more information, including default values.
Included in the build artifacts is an example that will add an FxCerts Test ECC PKI Secret with the following command.
You can now use Helm to push to your GKE cluster.
You can use the following methods to protect the Secrets required to connect to a remote HSM when using Kubernetes:
- Kubernetes enables integration with HashiCorp Vault or cloud-provider-specific Secret stores that only allow authorized pods to get access to the Secrets with role-based access control
- Kubernetes allows for role-based access control to approve PKI certificate issuance to pods. For information, reference this article.
- It is possible to give Kubernetes the ability to use a PKI token for TLS signing.
Refer to the following reference for information about alternatives to using Secrets to protect confidential data.