Application-Level Encryption

Keyfactor ACME uses data encryption for sensitive data—such as EAB HMAC keys—stored in the Keyfactor ACME database. This option encrypts only the data in the database deemed to be of a sensitive nature, not the entire database. By default, the data is encrypted using SQL encryption, but you have the option to add a second level of security with application-level encryption. If you choose to enable this option, you will need an encryption methodology for this purpose. For Windows installations under IIS, this would typically be a certificate installed in the Personal Certificate store of the Local Computer on each Keyfactor ACME server. For container installations under Kubernetes, there are a variety of options (see Container Installations (Kubernetes)).

Application-level encryption uses AES-256 encryption to provide for FIPS compliance.

Windows Installations (IIS)

Application-level encryption for Windows installations under IIS can be approached in a couple of different ways:

Note:  In an environment where there are multiple Keyfactor ACME servers pointing to the same database, each server running a Keyfactor ACME instance will need to have the same encryption methodology (e.g. the certificate AND the corresponding private key).

If a certificate is used for application-level encryption, the certificate has the following requirements:

  • The certificate must be installed in the Personal Certificate store of the Local Computer on each Keyfactor ACME server.

  • The certificate must have a key usage of one of:

    • Key Encipherment

    • Data Encipherment (Microsoft certificate templates allow this only as a suboption of key encipherment.)

  • You may use:

    • The certificate issued to the Keyfactor ACME website and bound to it in IIS, provided that it supports the appropriate key usage

    • A separate certificate for this purpose.

Optional Hardware Security Module (HSM):

  • An HSM may be used to store the private key for the certificate.

  • The Windows CSP driver for the HSM must be installed on the Keyfactor ACME server.

  • Be aware that transactions accessing the encrypted data (e.g. certificate enrollment) will require HSM access, which may slow down processes if the HSM is slow.

Note:  The thumbprint of the certificate used for application-level encryption is stored in the registry on the Keyfactor ACME server(s)—rather than in the Keyfactor ACME database—to provide a further level of separation from SQL.
Important:  If the certificate used for application-level encryption or the private key for this certificate are removed from the Keyfactor ACME server while data in the database is encrypted with this certificate, access to this data will be lost. Take care to ensure that this certificate and its private key remain in place or that there are backups of both the certificate and private key (with any necessary password) that can be accessed in the event that the certificate needs to be restored.

Figure 8: Certificate Template with Key Encipherment Key Usage

Cryptographic Provider for Application-Level Encryption Certificates

The certificate you use for application-level encryption must be issued using a key storage provider (KSP) or at least installed on the Keyfactor ACME server using a KSP in order to allow Keyfactor ACME to grant permissions on the certificate’s private key appropriately during installation. If Keyfactor ACME is not able to access the private key of the application-level certificate, you may receive a 500.30 error trying to access Keyfactor ACME or you may find you can access Keyfactor ACME but not all features function and you find errors such as these in the log (which of these occurs depends on other configuration factors):

Unable to decrypt enveloped PKCS7 data
Keyset does not exist

You can check the provider on your certificate with a command similar to the following issued in an administrative command prompt:

certutil -store MY [thumbprint of the application encryption certificate]

Output from this command should like similar to the following for a KSP certificate:

MY "Personal"
================ Certificate 3 ================
Serial Number: 1800000f39f4c506c41239c566000200000f39
Issuer: CN=CorpIssuingCA1, DC=Keyexample, DC=com
NotBefore: 10/27/2024 4:19 PM
NotAfter: 10/26/2026 4:19 PM
Subject: CN=keyfactor.keyexample.com
Non-root Certificate
Template: CorpWebServerv2, Corp Web Server v2
Cert Hash(sha1): 89b5099bc1f7146185331017db60373afb136edb
   Key Container = te-CorpWebServerv2-8b4d6ca7-e5ec-472f-a096-8b4aa590b22b
   Unique container name: 153703d13e6c7339e297f44547260e6d_00139f2c-9f21-4793-b740-bb3fe658245c
   Provider = Microsoft Software Key Storage Provider
Private key is NOT exportable
Encryption test passed
CertUtil: -store command completed successfully.

Output from this command should like similar to the following for a CSP certificate (legacy CSPs vary):

MY "Personal"
================ Certificate 0 ================
Serial Number: 59000006513beacf07ce121e45000100000651
Issuer: CN=CorpIssuingCA1, DC=Keyexample, DC=com
NotBefore: 10/27/2024 4:32 PM
NotAfter: 10/26/2026 4:32 PM
Subject: CN=keyfactor.keyexample.com
Non-root Certificate
Template: CorpWebServer, Corp Web Server
Cert Hash(sha1): a3a1299d3f5d209c89573c356495547b67d92f15
   Key Container = d5549bc8ea7af0f51d8b26ffbe9617b8_00139f2c-9f21-4793-b740-bb3fe658245c
   Simple container name: te-CorpWebServer-c6c249ac-66d3-427e-aff0-8de81250887f
   Provider = Microsoft RSA SChannel Cryptographic Provider
Private key is NOT exportable
Encryption test passed
CertUtil: -store command completed successfully.

If you have a certificate in PFXClosed A PFX file (personal information exchange format), also known as a PKCS#12 archive, is a single, password-protected certificate archive that contains both the public and matching private key and, optionally, the certificate chain. It is a common format for Windows servers. format with CSP and would like to import it as a KSP, you can use a command similar to the following:

certutil -importPFX -csp KSP MY <PFX Path and FileName> NoExport

Alternately, if you’re unable to use a certificate with a KSP, you may use a CSP and manually grant the Keyfactor ACME application pool user private key read permissions on the certificate.

As an alternative to using a certificate for application-level encryption for Windows installations under IIS, a base-64 encoded raw AES key file may be used. This option is used primarily to pave the way for migrating to Keyfactor ACME container installations under Kubernetes, since certificate-based application-level encryption is not supported for container installations under Kubernetes. The upgrade process would be:

  1. The secret data in the database begins with certificate-based application-level encryption.
  2. Re-encrypt the secret data in the database with a raw AES key while still on Windows.
  3. Deploy Keyfactor ACME in containers under Kubernetes with one of the application-level encryption methodologies supported there (see Container Installations (Kubernetes)) and raw AES key encryption as a secondary decryption option, triggering a second encryption.

To use a raw AES key, generate your base-64 encoded raw AES key before beginning the Keyfactor ACME installation. Once the installation has been run but before running the configuration wizard, copy your base-64 encoded raw AES key file to the \Configuration\Keys directory under the directory in which Keyfactor ACME is installed. By default, this is:

C:\Program Files\Keyfactor\ACME\Configuration\Keys
Tip:  There are a number of approaches to generating a raw AES key. One option is to use OpenSSL with a command similar to the following (where 16 generates an AES-128 key, 24 generates an AES-192 key, and 32 generates an AES-256 key):
openssl rand -base64 32 > aes-256-base64.key
Container Installations (Kubernetes)

Application-level encryption for container installations under Kubernetes can be approached in a couple of different ways:

The following are some example configurations.

A base-64 encoded raw AES key stored as a local Kubernetes Secret can be a simple solution for application-level encryption as a migration step to an alternate encryption methodology for databases previously used by Windows installations under IIS.

To configure application level-encryption with a raw AES key stored as a local Secret:

  1. Either generate a new raw AES key, if you’re starting with a Keyfactor ACME database that is not encrypted, or acquire the raw AES key used to encrypt the database if you’re working with a Keyfactor ACME database encrypted with a Windows installation under IIS.

    Tip:  There are a number of approaches to generating a raw AES key. One option is to use OpenSSL with a command similar to the following (where 16 generates an AES-128 key, 24 generates an AES-192 key, and 32 generates an AES-256 key):
    openssl rand -base64 32 > aes-256-base64.key

  2. Create a Secret in Kubernetes for your raw AES key. For example:

    sudo kubectl create secret generic aes-key --namespace keyfactor-acme --from-literal=aes-key=your-AES-key

  3. On your Kubernetes server, create an application encryption file (appencryptor.json) that defines that you will use raw AES encryption as your application-encryption methodology and specifies the name of the file containing the key. The file should contain the following, including a file name for your AES key on the file system within the containers (e.g. aes-256-base64.key):

    Copy 
    {
      "AppEncryptorInfo": {
        "Driver": "AESKey",
        "AESKey": {
          "FileName": "aes-256-base64.key"
        }
      }
    }
    Important:  The file must be named appencryptor.json when you build the ConfigMap for it in the next step.

  4. Create a ConfigMap in Kubernetes referencing the appencryptor.json file. For example:

    sudo kubectl create ConfigMap app-encryptor-aes --namespace keyfactor-acme --from-file=/opt/kyf_acme/appencryptor.json

  5. On your Kubernetes server, edit your values file to add a volume and volumeMount for the ConfigMap. For example, the following shows a portion of the example values file (see Installing Keyfactor ACME in Containers Under Kubernetes) with the example root trusts volume and volumeMount alongside the raw AES volume and volumeMount for the ConfigMap and Secret.

    workloadDefaults
  volumes:
    - name: root-cas
      configMap:
        name: ca-roots
        items:
          - key: ca-certificates.crt
            path: ca-certificates.crt
    - name: app-encryptor-info
      configMap:
        name: app-encryptor-aes
        items:
          - key: appencryptor.json
            path: appencryptor.json
    - name: raw-key-secret
      secret:
        secretName: aes-key
        optional: true

  volumeMounts:
    - name: root-cas
      mountPath: /etc/ssl/certs/ca-certificates.crt
      subPath: ca-certificates.crt
    - name: app-encryptor-info
      mountPath: /app/Configuration/appencryptor.json
      subPath: appencryptor.json
    - name: raw-key-secret
      mountPath: /app/keys/aes-256-base64.key
      subPath: aes-key
      readOnly: true
config:
  forceSecretReencryption: true

  6. To apply the new values and, if applicable, start encryption, run a Helm uninstall/install. A Helm upgrade will not trigger an encryption. For example (referencing the deployment name, namespace, your customized values file, the helm chart, and version):

    sudo helm uninstall Helm_Deployment_Name --namespace keyfactor-acme
    sudo helm install Helm_Deployment_Name --namespace keyfactor-acme --values values.yaml oci://repo.keyfactor.com/charts/command/acme --version 1.0.0

A base-64 encoded raw AES key stored in an Azure Key Vault can be used either as a long-term solution for application-level encryption for container installations under Kubernetes or as a migration step to an alternate encryption methodology for databases previously used by Windows installations under IIS.

To configure application-level encryption with a raw AES key stored in an Azure key vault:

  1. Either generate a new raw AES key, if you’re starting with a Keyfactor ACME database that is not encrypted, or acquire the raw AES key used to encrypt the database if you’re working with a Keyfactor ACME database encrypted with a Windows installation under IIS.

    Tip:  There are a number of approaches to generating a raw AES key. One option is to use OpenSSL with a command similar to the following (where 16 generates an AES-128 key, 24 generates an AES-192 key, and 32 generates an AES-256 key):
    openssl rand -base64 32 > aes-256-base64.key
  2. Create a Secret in the Azure vault to store your base-64 encoded AES key.

  3. Create a configuration file containing the information for the secret provider that specifies your Azure key vault information (e.g. azureprovider.yaml). For example:

    apiVersion: secrets-store.csi.x-k8s.io/v1
kind: SecretProviderClass
metadata:
  name: azure-vault
  namespace: keyfactor-acme
spec:
  parameters:
    keyvaultName: <YOUR_AZURE_VAULT_NAME>
    objects: |
      array:
        - |
          objectName: <YOUR_AZURE_SECRET_NAME>
          objectType: secret
    tenantId: <YOUR_AZURE_TENANT_ID>
    usePodIdentity: "false"
    useVMManagedIdentity: "true"
    userAssignedIdentityID: <YOUR_AZURE_VAULT_MANAGED_IDENTITY_CLIENT_ID>
  provider: azure
    • keyvaultName: A string identifying the Azure vault where the Secret resides.
    • objectName: The name given to the Azure vault secret holding your base-64 encoded AES key. For example, ACMEAESKeySecret.
    • tenantId: The GUID identifying the tenant where the Azure vault secret resides.
    • userAssignedIdentityID: The GUID identifying the managed identity used to access the Azure vault.

  4. On a server with the Azure Kubernetes Service (AKS) command-line interface (CLI) tool (kubectl) installed, create the provider connection to Azure referencing the configuration file created in the previous step. For example:

    kubectl apply --filename /opt/kyf_acme/azureprovider.yaml --namespace keyfactor-acme

  5. On the server with the Azure kubectl, create an application encryption file (appencryptor.json) that defines that you will use raw AES encryption as your application-encryption methodology and specifies the name of your key secret. The file should contain the following, including the name of your secret for Keyfactor ACME in the Azure vault (e.g. ACMEAESKeySecret):

    Copy 
    {
      "AppEncryptorInfo": {
        "Driver": "AESKey",
        "AESKey": {
          "FileName": "ACMEAESKeySecret"
        }
      }
    }
    Important:  The file must be named appencryptor.json when you build the config map for it in the next step.

  6. Create a ConfigMap using the Azure kubectl referencing the appencryptor.json file. For example:

    kubectl create ConfigMap app-encryptor-azure --namespace keyfactor-acme --from-file=/opt/kyf_acme/appencryptor.json

  7. On the server with the Azure kubectl, edit your values file to add a volume and volumeMount for the ConfigMap and AES key secret. For example, the following shows a portion of the example values file (see Installing Keyfactor ACME in Containers Under Kubernetes) with the example root trusts volume and volumeMount alongside the raw AES volume and volumeMount for the ConfigMap and Secret.

    workloadDefaults
  volumes:
    - name: root-cas
      configMap:
        name: ca-roots
        items:
          - key: ca-certificates.crt
            path: ca-certificates.crt
    - name: app-encryptor-info
      configMap:
        name: app-encryptor-azure
        items:
          - key: appencryptor.json
            path: appencryptor.json
    - csi:
        driver: secrets-store.csi.k8s.io
        readOnly: true
        volumeAttributes:
          secretProviderClass: azure-vault
      name: azure-key-secret

  volumeMounts:
    - name: root-cas
      mountPath: /etc/ssl/certs/ca-certificates.crt
      subPath: ca-certificates.crt
    - name: app-encryptor-info
      mountPath: /app/Configuration/appencryptor.json
      subPath: appencryptor.json
    - name: azure-key-secret
      mountPath: /app/keys
      readOnly: true
config:
  forceSecretReencryption: true

  8. To apply the new values and, if applicable, start encryption, run a Helm uninstall/install. A Helm upgrade will not trigger an encryption. For example (referencing the deployment name, namespace, your customized values file, the helm chart, and version):

    helm uninstall Helm_Deployment_Name --namespace keyfactor-acme
    helm install Helm_Deployment_Name --namespace keyfactor-acme --values values.yaml oci://repo.keyfactor.com/charts/command/acme --version 1.0.0

If your starting with a database that has not previously been configured for application-level encryption (or is at least not currently encrypted with application-level encryption) and you wish to deploy encryption using Fortanix, follow the steps in this section. If your database is already encrypted using a raw AES key and you want to migrate to Fortanix, see Migrating from Raw AES to Fortanix HSM.

To configure application level-encryption with Fortanix:

  1. In Fortanix, create an application and security object for use by Keyfactor ACME for application-level encryption.

  2. In Fortanix, locate the username and password for your application. To find these, browse to Apps, open your application for Keyfactor ACME application-level encryption, click the View API Key Details button, and change to the Username/Password tab in the Credentials Details dialog. Copy these to a secure temporary location.

    Figure 9: Find Fortanix Application Username and Password

  3. In Fortanix, locate the key ID of the security object you created for Keyfactor ACME application-level encryption. To find this, browse to Security Objects, open your security object for Keyfactor ACME, find the UUID, and click Copy ID. Copy this to a secure temporary location.

    Figure 10: Find Fortanix Security Object Key ID

  4. Create a Secret in Kubernetes for your Fortanix application password. For example:

    sudo kubectl create secret generic fortanix-secret --namespace keyfactor-acme --from-literal=fortanix-password=your-fortanix-app-password

  5. On your Kubernetes server, create an application encryption file (appencryptor.json) that defines the settings when using Fortanix as your application-encryption methodology, customizing it with your Fortanix application username and security object UUID. The file should contain the following:

    Copy 
    {
      "AppEncryptorInfo": {
        "Driver": "Fortanix",
        "Fortanix": {
          "BaseUrl": "https://amer.smartkey.io",
          "UserName": "<YOUR_FORTANIX_APP_USERNAME>",
          "KeyId": "<YOUR_FORTANIX_SECURITY_OBJECT_UUID>"
        }
      }
    }
    Important:  The file must be named appencryptor.json when you build the config map for it in the next step.

  6. Create a ConfigMap in Kubernetes referencing the appencryptor.json file. For example:

    sudo kubectl create ConfigMap app-encryptor-fortanix --namespace keyfactor-acme --from-file=/opt/kyf_acme/appencryptor.json
    Tip:  Once the ConfigMap has been created for the appencryptor.json file, it can be removed from the file system to limit access to the Fortanix username and key ID, if desired.

  7. On your Kubernetes server, edit your values file to add an additionalEnvironmentVariables section (if one does not already exist) with the environment variable name and value for the Fortanix application password as a Secret and a volume and volumeMount for the ConfigMap containing the Fortanix configuration. For example, the following shows a portion of the example values file (see Installing Keyfactor ACME in Containers Under Kubernetes) with just the Fortanix value in the additionalEnvironmentVariables section and the example root trusts volume and volumeMount alongside the Fortanix volume and volumeMount.

    workloadDefaults
  additionalEnvironmentVariables:
    - name: AppEncryptorInfo__Fortanix__Password
      valueFrom:
        secretKeyRef:
          name: fortanix-secret
          key: fortanix-password

  volumes:
    - name: root-cas
      configMap:
        name: ca-roots
        items:
          - key: ca-certificates.crt
            path: ca-certificates.crt
    - name: app-encryptor-info
      configMap:
        name: app-encryptor-fortanix
        items:
          - key: appencryptor.json
            path: appencryptor.json

  volumeMounts:
    - name: root-cas
      mountPath: /etc/ssl/certs/ca-certificates.crt
      subPath: ca-certificates.crt
    - name: app-encryptor-info
      mountPath: /app/Configuration/appencryptor.json
      subPath: appencryptor.json
config:
  forceSecretReencryption: true

  8. To apply the new values and start the encryption, run a Helm uninstall/install. A Helm upgrade will not trigger the encryption. For example (referencing the deployment name, namespace, your customized values file, the helm chart, and version):

    sudo helm uninstall Helm_Deployment_Name --namespace keyfactor-acme
    sudo helm install Helm_Deployment_Name --namespace keyfactor-acme --values values.yaml oci://repo.keyfactor.com/charts/command/acme --version 1.0.0

If your starting with a database that is currently encrypted with application-level encryption using a raw AES key and you wish to deploy encryption using Fortanix, follow the steps in this section. If your database is not currently encrypted using application-level encryption and you want to deploy to Fortanix, see Fortanix HSM.

Note:  A database cannot have two concurrent application-level encryption methodologies. The steps in this section configure both a raw AES key and Fortanix information so that the raw AES key is available to decrypt the data as the Fortanix HSM encrypts it.

To configure application level-encryption with Fortanix and allow the data to be decrypted with the existing raw AES key:

  1. In Fortanix, create an application and security object for use by Keyfactor ACME for application-level encryption.

  2. In Fortanix, locate the username and password for your application. To find these, browse to Apps, open your application for Keyfactor ACME application-level encryption, click the View API Key Details button, and change to the Username/Password tab in the Credentials Details dialog. Copy these to a secure temporary location.

    Figure 11: Find Fortanix Application Username and Password

  3. In Fortanix, locate the key ID of the security object you created for Keyfactor ACME application-level encryption. To find this, browse to Security Objects, open your security object for Keyfactor ACME, find the UUID, and click Copy ID. Copy this to a secure temporary location.

    Figure 12: Find Fortanix Security Object Key ID

  4. Create a Secret in Kubernetes for your Fortanix application password. For example:

    sudo kubectl create secret generic fortanix-secret --namespace keyfactor-acme --from-literal=fortanix-password=your-fortanix-app-password

  5. On your Kubernetes server, create an application encryption file (appencryptor.json) that defines the settings when using Fortanix as your application-encryption methodology, customizing it with your Fortanix application username and security object UUID. The file should contain the following:

    Copy 
    {
      "AppEncryptorInfo": {
        "Driver": "Fortanix",
        "Fortanix": {
          "BaseUrl": "https://amer.smartkey.io",
          "UserName": "<YOUR_FORTANIX_APP_USERNAME>",
          "KeyId": "<YOUR_FORTANIX_SECURITY_OBJECT_UUID>"
        }
      }
    }                    
    Important:  The file must be named appencryptor.json when you build the config map for it in the next step.

  6. Create a ConfigMap in Kubernetes referencing the appencryptor.json file. For example:

    sudo kubectl create ConfigMap app-encryptor-fortanix --namespace keyfactor-acme --from-file=/opt/kyf_acme/appencryptor.json
    Tip:  Once the ConfigMap has been created for the appencryptor.json file, it can be removed from the file system to limit access to the Fortanix username and key ID, if desired.

  7. On your Kubernetes server, edit your values file to add an additionalEnvironmentVariables section (if one does not already exist) with the environment variable name and value for the Fortanix application password as a Secret and a volume and volumeMount for the ConfigMap containing the Fortanix configuration. The file also needs to contain the secret information for you raw AES key so that it may be used to decrypt data. For example, the following shows a portion of the example values file (see Installing Keyfactor ACME in Containers Under Kubernetes) with just the Fortanix value in the additionalEnvironmentVariables section and the example root trusts volume and volumeMount alongside the Fortanix and raw AES key volumes and volumeMounts.

    workloadDefaults:

  additionalEnvironmentVariables:
    - name: AppEncryptorInfo__Fortanix__Password
      valueFrom:
        secretKeyRef:
          name: fortanix-secret
          key: fortanix-password

  volumes:
    - name: root-cas
      configMap:
        name: ca-roots
        items:
          - key: ca-certificates.crt
            path: ca-certificates.crt
    - name: app-encryptor-info
      configMap:
        name: app-encryptor-fortanix
        items:
          - key: appencryptor.json
            path: appencryptor.json
    - name: raw-key-secret
      secret:
        secretName: aes-key
        optional: true

  volumeMounts:
    - name: root-cas
      mountPath: /etc/ssl/certs/ca-certificates.crt
      subPath: ca-certificates.crt
    - name: app-encryptor-info
      mountPath: /app/Configuration/appencryptor.json
      subPath: appencryptor.json
    - name: raw-key-secret
      mountPath: /app/keys/aes-256-base64.key
      subPath: aes-key
      readOnly: trueconfig:
  forceSecretReencryption: true

  8. To apply the new values and start the decryption and re-encryption, run a Helm uninstall/install. A Helm upgrade will not trigger the decryption and re-encryption. For example (referencing the deployment name, namespace, your customized values file, the helm chart, and version):

    sudo helm uninstall Helm_Deployment_Name --namespace keyfactor-acme
    sudo helm install Helm_Deployment_Name --namespace keyfactor-acme --values values.yaml oci://repo.keyfactor.com/charts/command/acme --version 1.0.0

To remove application-encryption from a Keyfactor ACME database and return it to SQL encryption only:

  1. On your Kubernetes server, create an application encryption file (appencryptor.json) that contains a blank value for the application-encryption driver. Remaining values in the file will vary depending on what encryption methodology you’re removing. The configuration information for the encryption methodology you’re removing needs to be supplied to allow the data to be decrypted using that methodology. For example, raw AES contains no additional configuration in the appencryptor.json file, so to decrypt raw AES and return to SQL only, the file would look like:

    Copy 
    {
      "AppEncryptorInfo": {
        "Driver": ""
      }
    }

    Fortanix needs additional information in the appencryptor.json file, so to decrypt Fortanix and return to SQL only, the file would look like:

    Copy 
    {
      "AppEncryptorInfo": {
        "Driver": "",
        "Fortanix": {
          "BaseUrl": "https://amer.smartkey.io",
          "UserName": "<YOUR_FORTANIX_APP_USERNAME>",
          "KeyId": "<YOUR_FORTANIX_SECURITY_OBJECT_UUID>"
        }
      }
    }                    
    Important:  The file must be named appencryptor.json when you build the config map for it in the next step.

  2. Create a ConfigMap in Kubernetes referencing the appencryptor.json file. For example:

    sudo kubectl create configmap app-encryptor-decrypt --namespace keyfactor-acme --from-file=/opt/kyf_acme/appencryptor.json

  3. On your Kubernetes server, edit your values file to add a volume and volumeMount for the ConfigMap. The other configuration will vary depending on the encryption methodology you’re removing. For example, you need to retain the configuration for secrets to allow the data to be decrypted. The following shows a portion of the example values file (see Installing Keyfactor ACME in Containers Under Kubernetes) with the example root trusts volume and volumeMount alongside the ConfigMap volume and volumeMount and the secret configuration for Fortanix to allow the data to be decrypted from Fortanix.

    workloadDefaults:
  additionalEnvironmentVariables:
    - name: AppEncryptorInfo__Fortanix__Password
      valueFrom:
        secretKeyRef:
          name: fortanix-secret
          key: fortanix-password

  volumes:
    - name: root-cas
      configMap:
        name: ca-roots
        items:
          - key: ca-certificates.crt
            path: ca-certificates.crt
    - name: app-encryptor-info
      configMap:
        name: app-encryptor-decrypt
        items:
          - key: appencryptor.json
            path: appencryptor.json

  volumeMounts:
    - name: root-cas
      mountPath: /etc/ssl/certs/ca-certificates.crt
      subPath: ca-certificates.crt
    - name: app-encryptor-info
      mountPath: /app/Configuration/appencryptor.json
      subPath: appencryptor.jsonconfig:
  forceSecretReencryption: true

  4. To apply the new values and start the decryption, run a Helm uninstall/install. A Helm upgrade will not trigger the decryption. For example (referencing the deployment name, namespace, your customized values file, the helm chart, and version):

    sudo helm uninstall Helm_Deployment_Name --namespace keyfactor-acme
    sudo helm install Helm_Deployment_Name --namespace keyfactor-acme --values values.yaml oci://repo.keyfactor.com/charts/command/acme --version 1.0.0