CNE AWS Ready: Managing Secrets and Licenses

Liferay Cloud Native Experience (CNE) retrieves sensitive values from an external secrets provider. This approach prevents credentials, certificates, and licenses from being stored in GitOps repositories.

The External Secrets Operator synchronizes secrets from your configured vault into Kubernetes, where CNE consumes them during deployment.

Secrets Vault Configuration

CNE AWS Ready supports multiple secrets providers. By default, the platform integrates with AWS Secrets Manager.

AWS Secrets Manager (Default)

AWS Secrets Manager is the default secrets vault. The Cloud Native bootstrap process configures the required IAM Roles for Service Accounts (IRSA) so Kubernetes workloads can retrieve secrets.

The default IAM policy grants access to these secret paths:

{
   "Statement": [
      {
         "Action": [
            "secretsmanager:DescribeSecret",
            "secretsmanager:GetSecretValue"
         ],
         "Effect": "Allow",
         "Resource": [
            "arn:aws:secretsmanager:<region>:<accountid>:secret:liferay/certificates/*",
            "arn:aws:secretsmanager:<region>:<accountid>:secret:liferay/licenses/*",
            "arn:aws:secretsmanager:<region>:<accountid>:secret:liferay/credentials/gitops*"
         ]
      }
   ],
   "Version": "2012-10-17"
}

These paths enable CNE to retrieve TLS certificates, licenses, and GitOps credentials during deployment.

Using a Custom Secrets Vault

You can configure an alternative secrets provider such as HashiCorp Vault, Azure Key Vault, or Google Secret Manager.

To use a custom provider:

Create a service account with permission to read secrets from your vault.
Define the external_secret_store_provider_hcl variable in your Terraform configuration (gitops/resources/terraform.tfvars).

Example HashiCorp Vault configuration:

external_secret_store_provider_hcl={
   vault={
      auth={
         tokenSecretRef={
            key="token"
            name="vault-token"
         }
      }
      path="secret"
      server="http://my.vault.server:8200"
      version="v2"
   }
}

See External Secrets Operator for additional configuration options.

GitOps Repository Credentials

CNE requires credentials to access the GitOps repository that stores deployment configuration.

Store these credentials in your configured secrets vault. The default secret name is liferay/credentials/gitops.

To use a custom secret name, update the credentials_secret_name field in the git_repo_config section of config.json.

If you store your secret under company/credentials/gitops instead of the default, your configuration would look like this:

{
   "provider": "aws",
   "variables": {
      "deployment_name": "deployment-name",
      "liferay_git_repo_url": "https://github.com/your-org/your-gitops-repo",
      "liferay_helm_chart_version": "0.1.90",
      "region": "us-east-2",
      "liferay_git_repo_config": {
         "auth": {
            "credentials_secret_name": "company/credentials/gitops"
         },
         "source_paths": {},
         "target": {}
      }
   }
}

Note

Ensure the secret exists in the same AWS region specified in your configuration.

The secret structure depends on the authentication method.

Personal Access Token (HTTPS)

Create a secret containing these key/value pairs:

Key	Description
`git_machine_user_id`	Git username or machine account name
`git_access_token`	Personal Access Token (PAT)

Example:

Secret name	liferay/credentials/gitops
Key	Value
`git_machine_user_id`	user
`git_access_token`	ghp_abc…WxYZ

SSH Authentication

Create a secret containing this key/value pair:

Key	Description
`git_ssh_private_key`	Base64-encoded SSH private key

Example:

Secret name	liferay/credentials/gitops
Key	Value
`git_ssh_private_key`	LS0t…LSo=

TLS Certificates

Store TLS certificates in your secrets vault using this name prefix:

liferay/certificates/

Each certificate secret must contain:

Key	Description
`tls.crt`	Base64-encoded certificate
`tls.key`	Base64-encoded private key

Example:

Secret name	liferay/certificates/mydomain
Key	Value
`tls.crt`	LS0t…LSo=
`tls.key`	LS0t…LQo=

When encoding certificate files, disable line wrapping:

base64 -w 0 domain.cert.pem
base64 -w 0 private.key.pem

Liferay Licenses

Note

Before proceeding, ensure you have your Liferay .xml activation key. See Activating Liferay DXP to learn more.

CNE retrieves the Liferay license from the configured secrets vault during deployment.

Store licenses using the prefix liferay/licenses/.

Each secret must contain:

Key	Description
`license.xml`	Base64-encoded license file

Example:

Secret name	liferay/licenses/mylicense
Key	Value
`license.xml`	PD94…Pg==

Encode the license file without line wrapping:

base64 -w 0 license.xml

Configure the Liferay License

After storing the license, configure CNE to retrieve and mount it in the Liferay deployment.

Configure the External Secret Reference

Add the license reference to infrastructure.yaml:

license:
   externalSecretName: "liferay/licenses/mylicense"
   targetSecretName: "liferay-license"

externalSecretName identifies the secret in your vault.
targetSecretName defines the Kubernetes secret created in the cluster.

Configure Liferay to Consume the License

Update your environment’s liferay.yaml file to mount the license secret in the Liferay container. When providing a license, disable the default trial license to ensure Liferay uses the mounted license.

customEnv:
   x-license:
      - name: LIFERAY_DISABLE_TRIAL_LICENSE
         value: "true"

customVolumeMounts:
   x-license:
      - mountPath: /etc/liferay/mount/files/deploy
         name: license

customVolumes:
   x-license:
      - name: license
         secret:
            secretName: liferay-license
            items:
               - key: license.xml
                  path: license.xml

The secretName must match the targetSecretName defined in infrastructure.yaml.

After committing these changes, the External Secrets Operator synchronizes the license from the vault and mounts it in the Liferay container during deployment.

Capability: