Ataccama ONE Agentic ONE Desktop ONE DQ&C ONE MDM ONE RDM ONE Runtime Server
Downloads

Prepare Azure Resources for Kubernetes Edge

This page describes the Azure resources the Kubernetes edge needs, how to set them up, and how to reference them in the Helm values. Complete it before you install the Kubernetes edge on Azure.

The Kubernetes edge doesn’t create or change any Azure resources. It only reads and writes blobs in your Azure Blob Storage container and uses the Key Vault key for encryption. You provide all of these values in your Helm values file; none of them are shared with Ataccama.

Prerequisites checklist

Resource Required Requirements

Blob container in a storage account

Yes

Must exist before installation. See Storage account and container.

RSA key in Azure Key Vault

Only if result encryption is enabled

An enabled RSA key that permits the wrapKey and unwrapKey operations. See Key Vault key.

Microsoft Entra ID app registration

Yes

Has a client secret and the permissions the Kubernetes edge needs. See App registration.

Storage account and container

The Kubernetes edge uses one blob container in one storage account. On this page, "container" always means an Azure Blob Storage container, not a Kubernetes container. The container holds the results of data quality jobs (profiling results, invalid samples, and anomaly detection results) and temporary job data.

The results stay in the container. When users view them in Ataccama ONE, they’re read from the container by the DQ results reader, decrypted if you enabled result encryption, and sent to the platform over TLS.

Storage account settings

Create a standard general-purpose v2 (StorageV2) storage account with the following settings:

  • Redundancy: Choose locally redundant (LRS), zone-redundant (ZRS), or geo-redundant (GRS) storage based on your durability and disaster recovery requirements. The container holds the only copy of your data quality (DQ) results; Ataccama doesn’t keep one. If the container is lost, the results are no longer available in ONE.

  • Minimum TLS version: 1.2.

  • Anonymous blob access: Disabled.

  • Shared key access: We recommend disabling it. The Kubernetes edge authenticates with Microsoft Entra ID only and doesn’t use account keys, connection strings, or SAS tokens.

  • Hierarchical namespace: Not required.

  • Network access: The storage account must be reachable from the cluster, as the Kubernetes edge connects to it directly rather than through the Ataccama Edge gateway. If you use private endpoints, make sure the cluster can resolve the private DNS name.

Blob container

Create the container before you install the Kubernetes edge. The Kubernetes edge doesn’t create it, and jobs fail if it’s missing.

Every blob name starts with the edge instance name, so several edge instances could share one container. However, we recommend using a separate container for each instance, so that you can limit each instance’s access to its own container.

The Kubernetes edge writes the following blobs and deletes them when they are no longer needed:

Blob prefix Written by Read by Deleted by

<edge>/executor/data/<job_id>/request.protobuf (job requests)

Plane manager

Job pods

Plane manager, after the job finishes

<edge>/dqstorage/…​ (DQ results)

Job pods

DQ results reader

DQ results reader, when the results are deleted in ONE
Don’t configure retention or immutability policies on the container, and don’t apply lifecycle management rules to <edge>/dqstorage/, because they can delete or lock blobs that the Kubernetes edge or ONE still needs.

Job requests can be left behind, for example when a job can’t be started or a delete fails. To clean them up, you can add a lifecycle management rule that deletes blobs under <edge>/executor/data/ after seven days or more. Choose an age longer than your longest-running job and longer than any period the plane manager might be down. If a job request is deleted while its job is pending or running, the job fails, and ONE never receives its final status.

Key Vault key

If you enable result encryption (keyManagement.enabled: true), the Kubernetes edge encrypts DQ results before writing them to the container. It uses envelope encryption, where each result is encrypted with a data key, and the data key is wrapped with the public part of your RSA key. When the results are read, the data key is unwrapped in Key Vault.

Without result encryption, the results are protected only by Azure Storage encryption at rest.

Create an RSA key with the following properties:

  • Key type: RSA, either software-protected or backed by a hardware security module (HSM), 2048 bits or more.

  • Permitted operations: wrapKey and unwrapKey.

  • State: Enabled and within its activation and expiration dates.

In the Helm values, reference the key by name only, without a version.

Encrypted results are bound to the tenant, the edge instance name, the Key Vault, and the key name. Changing any of them makes existing results unreadable.

Rotate the Key Vault key

Each result records the key version it was encrypted with, and is decrypted with that version. When you rotate the key:

  • Keep the previous key versions enabled for as long as you need the results encrypted with them. A disabled or deleted version makes those results unreadable.

  • New results use the new version automatically, because each job looks up the current key version when it first writes an encrypted result.

App registration

The Kubernetes edge authenticates to the storage account and the Key Vault with a single Microsoft Entra ID identity, shared by the plane manager, job pods, and the DQ results reader. Create an app registration with a client secret, grant it the permissions listed in Required permissions, and reference it in the Helm values as described in Authentication modes.

Required permissions

The app registration requires the following permissions. How you grant them is up to you: through the built-in roles, custom roles, or direct role assignments.

Resource Operations Azure data actions Purpose

Blobs in the container

Read, write, delete

  • Microsoft.Storage/storageAccounts/blobServices/containers/blobs/read

  • Microsoft.Storage/storageAccounts/blobServices/containers/blobs/write

  • Microsoft.Storage/storageAccounts/blobServices/containers/blobs/delete

Store and read job data and DQ results, and delete them when they are no longer needed.

Key in the Key Vault

Get key, unwrap key

  • Microsoft.KeyVault/vaults/keys/read

  • Microsoft.KeyVault/vaults/keys/unwrap/action

Read the public key and unwrap data keys.

The built-in roles Storage Blob Data Contributor on the container and Key Vault Crypto Service Encryption User on the key cover these operations. If your Key Vault uses access policies instead of Azure RBAC, grant the Get and Unwrap Key key permissions.

No management plane permissions are needed, as the Kubernetes edge doesn’t list or create containers and doesn’t read account keys.

Authentication modes

Set the authentication mode in global.customerResources.azure.auth.type.

Use the clientSecret mode, which is the only supported mode. See Kubernetes Edge Limitations.

Mode What you set up

clientSecret

An app registration with a client secret, stored in a Kubernetes Secret. Rotate the secret before it expires.

Configure the Helm values

All Azure settings go under global.customerResources in the Helm values. The chart applies them to every component.

The tenant ID and client ID are set under the selected authentication type; there is no shared azure.auth.clientId key.

If a required value is missing, helm install fails and reports it. The chart doesn’t check that the resources exist or that the identity has access to them.

Keys in the following table are relative to global.customerResources.

Key Description Required

provider

Set to azure.

Yes

azure.auth.type

Authentication mode. Set to clientSecret (default), the only supported mode.

No

azure.auth.<type>.tenantId

Your Microsoft Entra tenant ID.

Yes

azure.auth.<type>.clientId

Client ID of the app registration.

Yes

azure.auth.<type>.authorityHost

Microsoft Entra sign-in endpoint. Defaults to https://login.microsoftonline.com; change it only for sovereign clouds.

No

azure.auth.clientSecret.existingSecret

Kubernetes Secret that holds the client secret.

For clientSecret, unless you provide the secret inline

azure.auth.clientSecret.existingSecretKeys.clientSecret

Key in that secret that holds the client secret. Defaults to ATACCAMA_EDGE_JOB_CUSTOMER_AZURE_CLIENT_SECRET.

No

azure.resultStorage.storageAccountName

Storage account name.

Yes

azure.resultStorage.containerName

Container name.

Yes

azure.keyManagement.enabled

Set to true to encrypt DQ results with your key. Defaults to false.

No

azure.keyManagement.keyVaultUri

Key Vault URI, for example https://<vault>.vault.azure.net.

For result encryption

azure.keyManagement.keyName

Name of the RSA key, without a version.

For result encryption

Example: client secret

Create a Kubernetes Secret that holds the client secret:

Create the client secret
kubectl create secret generic local-edge-azure -n <NAMESPACE> \
  --from-literal=ATACCAMA_EDGE_JOB_CUSTOMER_AZURE_CLIENT_SECRET='<CLIENT_SECRET>'

Reference it in the Helm values:

Helm values for client secret authentication
global:
  customerResources:
    provider: azure
    azure:
      auth:
        type: clientSecret
        clientSecret:
          tenantId: "<TENANT_ID>"
          clientId: "<CLIENT_ID>"
          existingSecret: local-edge-azure
      resultStorage:
        storageAccountName: "<STORAGE_ACCOUNT>"
        containerName: "<CONTAINER>"
      keyManagement:
        enabled: true
        keyVaultUri: "https://<VAULT>.vault.azure.net"
        keyName: "<RSA_KEY>"

The plane manager, job pods, and the DQ results reader use this one Secret.

Next steps

Was this page useful?