Before You Begin¶

Verify terminal access

1

kubectl config get-contexts

Ensure the asterisk (*) is next to the correct cluster name.

1

kubectl auth can-i '*' '*' --all-namespaces

This must return yes. If it returns no, you do not have sufficient permissions to proceed.

Install the Metrics Server

The Kubernetes Metrics Server provides resource metrics for pods and nodes, which are essential for monitoring and autoscaling. Check whether it is already installed:

1

kubectl get deployment metrics-server -n kube-system

If not, install it. For EKS, specific flags are needed to handle TLS certificates:

1

kubectl apply -f https://github.com/kubernetes-sigs/metrics-server/releases/latest/download/components.yaml

1
2

kubectl patch deployment metrics-server -n kube-system --type='json' \
  -p='[{"op": "add", "path": "/spec/template/spec/hostNetwork", "value": true}, {"op": "add", "path": "/spec/template/spec/containers/0/args/-", "value": "--kubelet-insecure-tls"}, {"op": "add", "path": "/spec/template/spec/containers/0/args/-", "value": "--kubelet-preferred-address-types=InternalIP,Hostname,ExternalIP"}]'

Verify (metrics may take 1–2 minutes to appear):

1

kubectl top nodes

Verify terminal access

Connect to your AKS cluster:

1

az aks get-credentials --resource-group <resource-group> --name <cluster-name>

1

kubectl config get-contexts

Ensure the asterisk (*) is next to the correct cluster name.

1

kubectl auth can-i '*' '*' --all-namespaces

This must return yes.

Install the Metrics Server

Check whether it is already installed:

1

kubectl get deployment metrics-server -n kube-system

If not, install it using the official manifest:

1

kubectl apply -f https://github.com/kubernetes-sigs/metrics-server/releases/latest/download/components.yaml

Verify (metrics may take 1–2 minutes to appear):

1

kubectl top nodes

Verify terminal access

Connect to your GKE cluster:

1

gcloud container clusters get-credentials <cluster-name> --zone <zone> --project <project-id>

1

kubectl config get-contexts

Ensure the asterisk (*) is next to the correct cluster name.

1

kubectl auth can-i '*' '*' --all-namespaces

This must return yes.

Install the Metrics Server

Check whether it is already installed:

1

kubectl get deployment metrics-server -n kube-system

If not, install it using the official manifest:

1

kubectl apply -f https://github.com/kubernetes-sigs/metrics-server/releases/latest/download/components.yaml

Verify (metrics may take 1–2 minutes to appear):

1

kubectl top nodes

S3 bucket

Trust3 uses an S3 bucket to store runtime data and configuration. Create a dedicated bucket in the same AWS region as your EKS cluster. Naming rules: 3–63 characters, lowercase letters, numbers, and hyphens only; globally unique across all AWS accounts.

1
2
3

aws s3api create-bucket \
  --bucket <bucket-name> \
  --region <region>

Keep server-side encryption (SSE-S3 or SSE-KMS) enabled and leave block-public-access enabled (the default). The IAM role from Cloud permissions must have S3 access to this bucket.

Verify access:

1

aws s3 ls s3://<bucket-name>

EFS file system + CSI driver — needed for connector persistent storage

Create an EFS file system in the same VPC and region as your EKS cluster, with security groups allowing NFS traffic (port 2049) between the EKS nodes and the EFS mount targets. Install the AWS EFS CSI Driver.

1

deleteAccessPointRootDir: true

1
2

args:
- --delete-access-point-root-dir=true

Verify the driver:

1

kubectl get pods -A -l 'app.kubernetes.io/name=aws-efs-csi-driver'

1

kubectl get csidriver efs.csi.aws.com

Find your file system ID (fs-...):

1

aws efs describe-file-systems --query 'FileSystems[*].{Name:Name,Id:FileSystemId}' --output table

The EFS ID cannot be changed after setup.

Secret store options

By default, no setup is needed — credentials are encrypted in your browser with a per-runtime public key, and only your runtime can decrypt them with its private key. To use your own store instead:

Kubernetes Secret — a single secret in the runtime namespace; each connector credential is one key in its data map. If a value changes later, restart the affected connector from the portal.

1
2
3
4

kubectl create secret generic <runtime-name>-secrets \
  -n <runtime-name> \
  --from-literal=my-credential='dummy-value' \
  --dry-run=client -o yaml | kubectl apply -f -

AWS Secrets Manager — a secret in the same region as your cluster; connector credentials are keys in its JSON payload. Access is granted through the IAM role in Cloud permissions.

1
2
3
4

aws secretsmanager create-secret \
  --name <secret-name> \
  --region <region> \
  --secret-string '{}'

Blob storage — for audit logs in your own storage

You need a storage account and a blob container inside it, both in the same Azure region as your AKS cluster.

1
2
3
4
5

az storage account create \
  --name <storage-account-name> \
  --resource-group <resource-group> \
  --location <location> \
  --sku Standard_LRS

1
2
3

az storage container create \
  --name <container-name> \
  --account-name <storage-account-name>

The managed identity from Cloud permissions needs the Storage Blob Data Contributor role on this container.

Secret store options

By default, no setup is needed — credentials are encrypted in your browser and only your runtime can decrypt them. To use your own store instead:

Kubernetes Secret — same as on other clouds:

1
2
3
4

kubectl create secret generic <runtime-name>-secrets \
  -n <runtime-name> \
  --from-literal=my-credential='dummy-value' \
  --dry-run=client -o yaml | kubectl apply -f -

Azure Key Vault — create a vault in the same region as your AKS cluster; each connector credential is an individual secret in the vault. The vault name must be globally unique (3–24 characters, alphanumeric and hyphens only). If a secret changes later, restart the affected connector from the portal.

1
2
3
4

az keyvault create \
  --name <key-vault-name> \
  --resource-group <resource-group> \
  --location <location>

The managed identity from Cloud permissions needs the Key Vault Secrets User role on the vault.

GCS bucket — for audit logs in your own storage

Create a bucket in the same GCP region as your GKE cluster. Naming rules: 3–63 characters — lowercase letters, numbers, hyphens, and underscores; globally unique across all GCP projects. Uniform bucket-level access is recommended; keep public access prevention enabled.

1
2
3
4

gcloud storage buckets create gs://<bucket-name> \
  --location=<region> \
  --uniform-bucket-level-access \
  --public-access-prevention

The service account from Cloud permissions needs Storage Object Admin on this bucket.

Verify access:

1

gcloud storage ls gs://<bucket-name>

Secret store options

By default, no setup is needed — credentials are encrypted in your browser and only your runtime can decrypt them. To use your own store instead:

Kubernetes Secret — same as on other clouds:

1
2
3
4

kubectl create secret generic <runtime-name>-secrets \
  -n <runtime-name> \
  --from-literal=my-credential='dummy-value' \
  --dry-run=client -o yaml | kubectl apply -f -

Google Secret Manager — a secret in the same project as your GKE cluster. If a value changes later, restart the affected connector from the portal.

1
2
3

echo -n '{}' | gcloud secrets create <secret-name> \
  --data-file=- \
  --replication-policy=automatic

The service account from Cloud permissions needs Secret Manager Secret Accessor.

AWS Load Balancer Controller

Required for managing ingress traffic: it provisions Application Load Balancers based on Kubernetes Ingress resources. Install it following the AWS Load Balancer Controller guide, then verify:

1

kubectl get pods -n kube-system -l app.kubernetes.io/name=aws-load-balancer-controller

You should see the pods in Running state (typically 2 replicas).

Route 53 hosted zone

Trust3 uses a Route 53 hosted zone to manage DNS records for the service endpoints (for example *.trust3.yourdomain.com).

• Automatic DNS: Trust3 creates, updates, and deletes the records for you. Requires the IAM role from Cloud permissions to have Route 53 access.
• Manual DNS: you create the records yourself after deployment; Trust3 provides the required record values.

Find your hosted zone:

1

aws route53 list-hosted-zones --query "HostedZones[*].{Name:Name,Id:Id}" --output table

If you do not have a hosted zone yet, create one in Route 53 and delegate it from your parent domain's DNS — common for a subdomain like trust3.yourdomain.com.

ACM certificate

The certificate must cover the service endpoint domain (for example *.trust3.yourdomain.com) and be in the same AWS region as your EKS cluster. It can be a public certificate issued by ACM or an existing certificate imported into ACM. Find its ARN:

1

aws acm list-certificates --region <region>

ARN format: arn:aws:acm:<region>:<account-id>:certificate/<certificate-id>

ALB subnets — at least two subnet IDs where the Application Load Balancers will reside.

ALB group name (optional) — ingresses in the same group share one Application Load Balancer. Defaults to trust3ai.

Azure DNS zone

Trust3 uses an Azure DNS zone to manage DNS records for the service endpoints (for example *.trust3.yourdomain.com).

• Automatic DNS: Trust3 creates, updates, and deletes the records for you. Requires the managed identity from Cloud permissions to have the DNS Zone Contributor role.
• Manual DNS: you create the records yourself after deployment; Trust3 provides the required record values.

Find your DNS zone:

1

az network dns zone list --query "[].{Name:name,ResourceGroup:resourceGroup}" --output table

If you do not have one yet, create it and delegate from your parent domain's DNS:

1

az network dns zone create --resource-group <resource-group> --name trust3.yourdomain.com

TLS certificate (Kubernetes secret)

You need a CA-signed TLS certificate and key — a single wildcard certificate (for example *.corp.example.com) covers all Trust3 service endpoints on your domain. Have the certificate and key ready before installation, then create the TLS secret in your cluster. The secret name privacera-external-tls and the runtime namespace are fixed.

1

kubectl create namespace <runtime-name>

PEM format:

1
2
3
4

kubectl create secret tls privacera-external-tls \
  --cert="<cert-path>" \
  --key="<key-path>" \
  -n <runtime-name>

PFX/P12 format — conversion needs OpenSSL (check with openssl version; drop the -legacy flag on OpenSSL versions below 3.x):

1
2
3
4
5
6
7

openssl pkcs12 -legacy -in "<pfx-path>" \
  -nokeys -out chain.pem
openssl pkcs12 -legacy -in "<pfx-path>" \
  -nocerts -nodes -out key.pem

kubectl create secret tls privacera-external-tls \
  --cert=chain.pem --key=key.pem -n <runtime-name>

On certificate renewal, replace the secret:

1
2
3
4
5

kubectl create secret tls privacera-external-tls \
  --cert="<cert-path>" \
  --key="<key-path>" \
  -n <runtime-name> \
  --dry-run=client -o yaml | kubectl replace -f -

Cloud DNS managed zone

Trust3 uses a Cloud DNS managed zone to manage DNS records for the service endpoints (for example *.trust3.yourdomain.com).

• Automatic DNS: Trust3 creates, updates, and deletes the records for you. Requires the service account from Cloud permissions to have the DNS Admin role.
• Manual DNS: you create the records yourself after deployment; Trust3 provides the required record values.

Find your managed zone:

1

gcloud dns managed-zones list --format="table(name,dnsName,visibility)"

If you do not have one yet, create it and delegate from your parent domain's DNS:

1
2
3
4
5

gcloud dns managed-zones create trust3-zone \
  --dns-name="trust3.yourdomain.com." \
  --description="Trust3 managed zone" \
  --visibility=public \
  --project=<project-id>

TLS certificate (Kubernetes secret)

You need a CA-signed TLS certificate and key — a single wildcard certificate (for example *.corp.example.com) covers all Trust3 service endpoints on your domain. Have the certificate and key ready before installation, then create the TLS secret in your cluster. The secret name privacera-external-tls and the runtime namespace are fixed.

1

kubectl create namespace <runtime-name>

PEM format:

1
2
3
4

kubectl create secret tls privacera-external-tls \
  --cert="<cert-path>" \
  --key="<key-path>" \
  -n <runtime-name>

PFX/P12 format — conversion needs OpenSSL (check with openssl version; drop the -legacy flag on OpenSSL versions below 3.x):

1
2
3
4
5
6
7

openssl pkcs12 -legacy -in "<pfx-path>" \
  -nokeys -out chain.pem
openssl pkcs12 -legacy -in "<pfx-path>" \
  -nocerts -nodes -out key.pem

kubectl create secret tls privacera-external-tls \
  --cert=chain.pem --key=key.pem -n <runtime-name>

On certificate renewal, replace the secret:

1
2
3
4
5

kubectl create secret tls privacera-external-tls \
  --cert="<cert-path>" \
  --key="<key-path>" \
  -n <runtime-name> \
  --dry-run=client -o yaml | kubectl replace -f -

Create an IAM role named trust3-<runtime-name>-role that Trust3 services assume through the cluster's OIDC provider (IRSA). You can use an existing role if the trust relationship and policy match.

Create the role

Set your EKS cluster name, then create the role with the OIDC trust policy:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30

K8S_CLUSTER_NAME="<cluster-name>"

OIDC_URL=$(aws eks describe-cluster --name "$K8S_CLUSTER_NAME" \
  --query "cluster.identity.oidc.issuer" --output text | sed 's|https://||')

ACCOUNT_ID=$(aws sts get-caller-identity --query "Account" --output text)

OIDC_ARN="arn:aws:iam::${ACCOUNT_ID}:oidc-provider/${OIDC_URL}"

TRUST_POLICY=$(cat <<EOF
{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Principal": {"Federated": "${OIDC_ARN}"},
    "Action": "sts:AssumeRoleWithWebIdentity",
    "Condition": {
      "StringLike": {
        "${OIDC_URL}:aud": "sts.amazonaws.com",
        "${OIDC_URL}:sub": "system:serviceaccount:<runtime-name>:*"
      }
    }
  }]
}
EOF
)

aws iam create-role \
  --role-name "trust3-<runtime-name>-role" \
  --assume-role-policy-document "$TRUST_POLICY"

Retrieve the role ARN (this is what you enter in the wizard):

1
2
3

aws iam get-role \
  --role-name "trust3-<runtime-name>-role" \
  --query "Role.Arn" --output text

1

eksctl utils associate-iam-oidc-provider --cluster <cluster-name> --approve

Attach the permissions policy

Attach one inline policy named Trust3PermissionsPolicy. Include only the statements for the services you configured — Secrets Manager (your own secret store), S3 (your own bucket), Route 53 (automatic DNS):

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39

POLICY_DOC=$(cat <<'EOF'
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "secretsmanager:GetSecretValue",
        "secretsmanager:DescribeSecret"
      ],
      "Resource": [
        "arn:aws:secretsmanager:<region>:*:secret:<secret-name>-*",
        "arn:aws:secretsmanager:<region>:*:secret:<secret-name>"
      ]
    },
    {
      "Effect": "Allow",
      "Action": "s3:*",
      "Resource": [
        "arn:aws:s3:::<bucket-name>",
        "arn:aws:s3:::<bucket-name>/*"
      ]
    },
    {
      "Effect": "Allow",
      "Action": "route53:*",
      "Resource": [
        "arn:aws:route53:::hostedzone/<hosted-zone-id>"
      ]
    }
  ]
}
EOF
)

aws iam put-role-policy \
  --role-name "trust3-<runtime-name>-role" \
  --policy-name Trust3PermissionsPolicy \
  --policy-document "$POLICY_DOC"

Trust relationship for an existing role

If you reuse an existing role, set its trust policy — replace <oidc-arn> and <oidc-url> with your cluster's OIDC provider values:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "Federated": "<oidc-arn>"
            },
            "Action": "sts:AssumeRoleWithWebIdentity",
            "Condition": {
                "StringLike": {
                    "<oidc-url>:aud": "sts.amazonaws.com",
                    "<oidc-url>:sub": "system:serviceaccount:<runtime-name>:*"
                }
            }
        }
    ]
}

Apply it — put the JSON above in a TRUST_POLICY variable, then:

1
2
3

aws iam update-assume-role-policy \
  --role-name "trust3-<runtime-name>-role" \
  --policy-document "$TRUST_POLICY"

Find your OIDC values:

1

aws eks describe-cluster --name <cluster-name> --query "cluster.identity.oidc.issuer" --output text

Remove https:// from the output to get <oidc-url>; the matching <oidc-arn> is arn:aws:iam::<account-id>:oidc-provider/<oidc-url>.

Create a User-Assigned Managed Identity named trust3-<runtime-name>-identity and a federated credential so Kubernetes service accounts in the runtime namespace can authenticate as it via Workload Identity. You can use an existing identity if the configuration matches.

Create the managed identity

1
2
3
4

az identity create \
  --resource-group <resource-group> \
  --name trust3-<runtime-name>-identity \
  --location <location>

Retrieve the Client ID (this is what you enter in the wizard):

1
2
3
4

az identity show \
  --resource-group <resource-group> \
  --name trust3-<runtime-name>-identity \
  --query clientId -o tsv

Create the federated identity credential

Find your AKS OIDC issuer URL:

1

az aks show --resource-group <resource-group> --name <cluster-name> --query "oidcIssuerProfile.issuerUrl" --output tsv

1
2
3
4
5
6
7

az identity federated-credential create \
  --name "trust3-<runtime-name>-federated" \
  --identity-name "trust3-<runtime-name>-identity" \
  --resource-group <resource-group> \
  --issuer "<aks-oidc-issuer-url>" \
  --subject "system:serviceaccount:<runtime-name>:<runtime-name>-sa" \
  --audiences "api://AzureADTokenExchange"

1

az aks update --resource-group <resource-group> --name <cluster-name> --enable-oidc-issuer --enable-workload-identity

Role assignments

Assign only the roles for the services you configured:

Storage Blob Data Contributor — when using your own blob container:

1
2
3
4

az role assignment create \
  --assignee "<managed-identity-client-id>" \
  --role "Storage Blob Data Contributor" \
  --scope "/subscriptions/<subscription-id>/resourceGroups/<resource-group>/providers/Microsoft.Storage/storageAccounts/<storage-account>/blobServices/default/containers/<container-name>"

DNS Zone Contributor — when using automatic DNS management:

1
2
3
4

az role assignment create \
  --assignee "<managed-identity-client-id>" \
  --role "DNS Zone Contributor" \
  --scope "/subscriptions/<subscription-id>/resourceGroups/<resource-group>/providers/Microsoft.Network/dnszones/<dns-zone-name>"

Key Vault Secrets User — when using Azure Key Vault as the secret store:

1
2
3
4

az role assignment create \
  --role "Key Vault Secrets User" \
  --assignee <managed-identity-client-id> \
  --scope $(az keyvault show --name <key-vault-name> --query id -o tsv)

Create a GCP service account named trust3-<runtime-name>-sa and bind it to the runtime's Kubernetes service account via Workload Identity. You can use an existing service account if the email and bindings match.

Create the service account

1
2
3

gcloud iam service-accounts create trust3-<runtime-name>-sa \
  --display-name="Trust3 Service Account for <runtime-name>" \
  --project=<project-id>

Retrieve the service account email (this is what you enter in the wizard — format trust3-<runtime-name>-sa@<project-id>.iam.gserviceaccount.com):

1
2
3

gcloud iam service-accounts list \
  --filter="name:trust3-<runtime-name>-sa" \
  --project=<project-id>

Workload Identity binding — always required when using the service account:

1
2
3
4

gcloud iam service-accounts add-iam-policy-binding trust3-<runtime-name>-sa@<project-id>.iam.gserviceaccount.com \
  --project=<project-id> \
  --role="roles/iam.workloadIdentityUser" \
  --member="serviceAccount:<project-id>.svc.id.goog[<runtime-name>/<runtime-name>-sa]"

1
2
3

gcloud container clusters update <cluster-name> \
  --workload-pool=<project-id>.svc.id.goog \
  --region=<region>

Role bindings

Grant only the roles for the services you configured:

Storage Object Admin (roles/storage.objectAdmin) — when using your own GCS bucket:

1
2
3

gcloud storage buckets add-iam-policy-binding gs://<bucket-name> \
  --member="serviceAccount:trust3-<runtime-name>-sa@<project-id>.iam.gserviceaccount.com" \
  --role="roles/storage.objectAdmin"

DNS Administrator (roles/dns.admin) — when using automatic DNS management:

1
2
3

gcloud projects add-iam-policy-binding <project-id> \
  --member="serviceAccount:trust3-<runtime-name>-sa@<project-id>.iam.gserviceaccount.com" \
  --role="roles/dns.admin"

Secret Manager Secret Accessor (roles/secretmanager.secretAccessor) — when using Google Secret Manager as the secret store:

1
2
3

gcloud projects add-iam-policy-binding <project-id> \
  --member="serviceAccount:trust3-<runtime-name>-sa@<project-id>.iam.gserviceaccount.com" \
  --role="roles/secretmanager.secretAccessor"