📘

Using a KMS key

The agent never specifies an encryption method when it writes an object, so whatever you configure as the bucket's default encryption is what gets applied. To encrypt with a customer-managed KMS key, set it as the bucket default:

Bash

aws s3api put-bucket-encryption \
  --bucket mcd-agent-store \
  --server-side-encryption-configuration \
    '{"Rules":[{"ApplyServerSideEncryptionByDefault":{"SSEAlgorithm":"aws:kms","KMSMasterKeyID":"<your-kms-key-arn>"},"BucketKeyEnabled":true}]}'

The agent's identity then also needs access to the key — add this statement to the role you create in the next step, and make sure the key policy allows that role (directly, or by delegating to IAM policies in the account):

JSON

{
  "Effect": "Allow",
  "Action": ["kms:Decrypt", "kms:GenerateDataKey"],
  "Resource": "<your-kms-key-arn>"
}

Both actions are required: kms:GenerateDataKey to write objects (including multipart uploads) and kms:Decrypt to read them back. The agent never copies or re-encrypts objects, so kms:Encrypt and kms:ReEncrypt* — listed in the equivalent AWS data store policy — are not needed here.

📝

These steps assume the agent runs on AKS, with the cluster's OIDC issuer and workload identity features enabled. The agent authenticates to Blob Storage with a user-assigned managed identity through Microsoft Entra Workload ID — it never uses storage account keys or connection strings, so the account can keep shared key access disabled.

📘

Blob Storage encrypts data at rest by default. If you configure a customer-managed key on the storage account, the agent needs no additional permissions — the storage account uses its own identity to reach the key.

📘

The subject must match the namespace and service account the agent runs under. The chart always names the service account mcd-agent-service-account; adjust the namespace if you changed namespace in your values.yaml.

⚠️

Both the service account annotation and the azure.workload.identity/use pod label are required. The label is what tells the workload identity webhook to inject the projected token and the AZURE_CLIENT_ID environment variable into the pod.

Each one fails differently, and neither failure names the missing piece:

Annotation missing — the webhook injects everything except AZURE_CLIENT_ID, so the agent fails on startup, before contacting the storage account:

ValueError: 'client_id' is required. Please pass it in or set the AZURE_CLIENT_ID environment variable

Label missing — nothing is injected, and the agent authenticates as the cluster's node identity instead. That identity has no role on the storage account, so the failure looks like a missing role assignment:

ErrorCode:AuthorizationPermissionMismatch
This request is not authorized to perform this operation using this permission.

In either case, check the annotation and the label before revisiting role assignments. To confirm what the pod actually received:

Bash

kubectl exec -n mcd-agent deploy/mcd-agent-deployment -- env | grep AZURE_

A correctly configured pod lists AZURE_CLIENT_ID, AZURE_TENANT_ID, AZURE_FEDERATED_TOKEN_FILE, and AZURE_AUTHORITY_HOST.

📝

These steps assume the agent runs on GKE, with Workload Identity Federation enabled on the cluster. The agent authenticates to Cloud Storage as a Google service account bound to its Kubernetes service account — no service account keys are needed.

📘

Cloud Storage encrypts data at rest by default. If you configure a customer-managed encryption key (CMEK) on the bucket, the agent needs no additional permissions — Cloud Storage uses its own service agent to reach the key.

📘

Both roles are required. roles/storage.objectAdmin covers reading, writing, and deleting objects, but grants nothing at the bucket level. The agent resolves the bucket before every operation, so without storage.buckets.get even a write fails:

403 GET https://storage.googleapis.com/storage/v1/b/mcd-agent-store:
does not have storage.buckets.get access to the Google Cloud Storage bucket

roles/storage.legacyBucketReader (Storage Legacy Bucket Reader) adds it. Despite the name, these roles are not deprecated — they are the granular way to grant bucket-level reads. A custom role containing only storage.buckets.get works equally well if you prefer to avoid the predefined role.

📘

The member must match the namespace and service account the agent runs under. The chart always names the service account mcd-agent-service-account; adjust the namespace if you changed namespace in your values.yaml.

⚠️

This manifest is a reference for development and testing: it runs MinIO with the default minioadmin credentials over plain HTTP. For production, use a cloud-native storage service, or run MinIO with your own credentials, TLS, and a storage class suited to the workload.

📘

storageAccessKey and storageSecretKey end up in plain text in your values file. To keep them in a Kubernetes secret instead, create the secret:

Bash

kubectl create secret generic mcd-agent-storage-credentials -n mcd-agent \
  --from-literal=access-key=<your-access-key> \
  --from-literal=secret-key=<your-secret-key>

Then leave storageAccessKey and storageSecretKey unset, and pass the equivalent environment variables through container.extraEnv:

YAML

container:
  extraEnv:
    - name: MCD_STORAGE_ACCESS_KEY
      valueFrom:
        secretKeyRef:
          name: mcd-agent-storage-credentials
          key: access-key
    - name: MCD_STORAGE_SECRET_KEY
      valueFrom:
        secretKeyRef:
          name: mcd-agent-storage-credentials
          key: secret-key

Set them one way or the other — not both, or the pod ends up with duplicate environment variables.