Cloud permissions¶

The cloud identity Trust3 services assume to reach your bucket, your secret store, and your DNS zone.

Not needed on Trust3 AI Cloud

A Trust3 AI Cloud plane runs in Trust3AICloud, so Trust3AI provides all of this. See Deployment Options.

Deployment type	When you need it
Partially Managed (D2P)	Optional to start with. A cloud identity becomes required as soon as the runtime plane touches a cloud service — your own bucket, your own secret manager, or automatic DNS.
Self-Managed	Required. S3 and DNS access are always configured.

The wizard's Cloud Permissions step shows the same commands with your values filled in. Self-Managed runs on AWS only.

AWS — IAM role (IRSA)¶

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:

Bash
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):

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

OIDC provider not associated?

If your EKS cluster does not have an OIDC provider associated with IAM, create one first — see the AWS IRSA documentation:

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

Attach the permissions policy¶

Attach one inline policy named Trust3PermissionsPolicy, covering Secrets Manager (your own secret store), S3 (your own bucket), and Route 53 (automatic DNS).

On Partially Managed (D2P), include only the statements for the services you configured.
On Self-Managed, the S3 and Route 53 statements are always needed; include the Secrets Manager statement only when AWS Secrets Manager is your secret store.

Bash
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:

JSON
{
    "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:

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

Find your OIDC values

Bash
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>.

Azure — managed identity¶

Partially Managed (D2P) only. 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¶

Bash
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):

Bash
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:

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

Bash
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"

Workload Identity not enabled on your AKS cluster?

Enable it first — see the AKS Workload Identity documentation:

Bash
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 ContributorDNS Zone ContributorKey Vault Secrets User

When using your own blob container:

Bash
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>"

When using automatic DNS management:

Bash
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>"

When using Azure Key Vault as the secret store:

Bash
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)

Google Cloud — service account¶

Partially Managed (D2P) only. 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¶

Bash
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):

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

Workload Identity binding¶

Always required when using the service account:

Bash
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]"

Workload Identity not enabled on your GKE cluster?

Enable it first — see the GKE Workload Identity documentation:

Bash
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 AdminDNS AdministratorSecret Manager Secret Accessor

roles/storage.objectAdmin — when using your own GCS bucket:

Bash
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"

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

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

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

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

Prev topic: DNS and ingress
Next topic: Before You Begin