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

Kubernetes Edge Network Access Requirements

The Kubernetes edge only makes outbound connections: it needs no inbound ports or ingress, and its pods don’t communicate with each other.

This page lists the connections you need to allow, so that you can prepare firewall rules and egress allowlists before you install the Kubernetes edge on Azure.

Kubernetes edge workloads

The Kubernetes edge runs four workloads in your cluster: edge-plane-manager, job pods, edge-interactive-jobs, and dq-results-reader. For what each of them does, see How the Kubernetes edge works.

Connections to data sources use each source’s own port. All other traffic is HTTPS on port 443, either to your Azure resources or through the Ataccama Edge gateway.

Required connections

Allow these outbound connections from the Kubernetes edge namespace. The chart doesn’t include any NetworkPolicies, so add your own egress policies to match this table. Placeholders in angle brackets are values you set in the Helm chart or in Ataccama ONE.

Source Destination Port Purpose Required

Job pods, edge-interactive-jobs

Your data sources (databases, file stores, warehouses)

The data source’s own port, for example 1433 or 5432

Read and write the data being processed

Yes

edge-plane-manager, job pods, dq-results-reader

<storage_account>.blob.core.windows.net

443

Job requests, job results, invalid samples

Yes

Job pods, dq-results-reader

<key_vault>.vault.azure.net (encryption key)

443

Wrap and unwrap data encryption keys

When encryption is on

Job pods, edge-interactive-jobs

<key_vault>.vault.azure.net (credentials)

443

Read data source credentials

When credentials are kept in your Azure Key Vault

All workloads that call Azure services

login.microsoftonline.com

443

Microsoft Entra ID tokens

Yes

All four workloads

Ataccama Edge gateway, <ring>-<region>.connect-azure.ataccama.one

443

Tasks, replies, platform credentials, result uploads, and logs and telemetry

Yes

All four workloads

<tenant_host>.ataccama.one

443

Sign-in to the Ataccama identity provider (IDP)

Yes, unless global.agentic.gateway.keycloakEnabled is true; see Sign-in to the Ataccama identity provider

edge-plane-manager

Kubernetes API server

In-cluster

Create and watch Jobs

Yes

Cluster nodes

ataccama.azurecr.io and its data endpoints (hostnames are listed in the Ataccama Cloud Portal)

443

Pull Ataccama container images

Yes, unless you mirror the images

Data sources

Job pods and edge-interactive-jobs must reach every data source you connect in ONE, on its own host and port. edge-plane-manager and dq-results-reader don’t connect to data sources.

These connections go directly from the pod through your own network, not through the Ataccama Edge gateway. Job pods get a new name for every task, so allow the traffic by namespace or pod label rather than by pod name or IP.

Connectors and JDBC drivers are included in the container images, so no driver is downloaded from the internet.

Some drivers need additional settings other than the data source host and port. For example, the Snowflake JDBC driver also checks certificates over HTTP (port 80) and reads and writes Snowflake internal stage storage. To get every host a Snowflake account needs, run SELECT SYSTEM$ALLOWLIST() in Snowflake and allow the returned hosts.

Azure Blob Storage and Key Vault

Three workloads use the storage container and encryption key in your Azure subscription. All calls are HTTPS on port 443, authenticated with the identity you configure under global.customerResources.azure.auth.

Workload Blob Storage container Key Vault encryption key

edge-plane-manager

Writes, reads, and deletes job requests

Not used

Job pods

Read job requests, write results and invalid samples

Encrypts results (reads the public key once)

dq-results-reader

Reads and deletes results and samples

Decrypts results (unwraps the data key)

  • Hostnames: <storage_account>.blob.core.windows.net and, when encryption is on, <key_vault>.vault.azure.net. Every authentication type also signs in at login.microsoftonline.com, or the authorityHost you set for sovereign clouds.

  • Firewalls and private endpoints: If the storage account or Key Vault restricts public network access, allow your cluster’s egress IP or subnet. Alternatively, add private endpoints with the privatelink.blob.core.windows.net and privatelink.vaultcore.azure.net DNS zones, resolvable from the cluster.

For the Helm values and the permissions to grant, see Prepare Azure Resources for Kubernetes Edge.

Data source credentials in your Key Vault

This section applies only if you keep data source credentials in your own Azure Key Vault and configure it as a secret management service in ONE. In that case, ONE instructs the edge which vault and secret to use for each connection.

  • Workloads: Job pods and edge-interactive-jobs, the same workloads that open the data source connection.

  • Hosts: The vault URL you entered in ONE, typically https://<credentials_vault>.vault.azure.net, plus login.microsoftonline.com, both on port 443.

  • Identity: The Microsoft Entra ID application you configured for the secret management service in ONE, not the Helm chart’s customerResources identity.

  • Permissions: get on secrets, and list if you want Test connection in ONE to enumerate secrets. The built-in Key Vault Secrets User role covers both.

The credentials vault can be the same one that holds the encryption key, or a separate vault. Keeping them apart lets you grant the two identities only what each needs.

Ataccama Edge gateway and platform connectivity

The Ataccama Edge gateway is mandatory: no other path from the edge to the platform is supported.

The workloads use it to pull tasks, send replies, obtain short-lived platform credentials, and upload results, over HTTPS on port 443. Logs and telemetry also go through it to Ataccama observability.

  • Endpoint: <ring>-<region>.connect-azure.ataccama.one:443. Ataccama provides the exact hostname for your tenant.

  • Private connectivity: The gateway is available only through Azure Private Link. See Connect to the gateway over Private Link.

  • Protocol: An HTTP CONNECT forward proxy with basic authentication. The username is your edge instance name and the password is a token Ataccama issues for it. The connection is encrypted with TLS end to end, from the pod to the Ataccama service, so don’t apply TLS inspection to it.

  • Helm values: global.agentic.gateway.enabled: true, url, port (443), and the credentials in existingSecret. For the value reference and an example, see Ataccama Edge gateway.

Ataccama runs the gateway as an Azure Private Link service and approves each connection to it. When you onboard, Ataccama gives you the Private Link service alias and the gateway hostname for your tenant.

To connect your cluster:

  1. In the cluster’s virtual network, create a private endpoint that targets the Private Link service alias.

  2. Wait until Ataccama approves the connection.

    If Ataccama has pre-authorized your Azure subscription, the connection is approved automatically.

  3. In a private DNS zone linked to the virtual network, create an A record that maps the gateway hostname to the private endpoint’s IP address.

Always connect to the gateway by its hostname, not by IP address, because the gateway’s TLS certificate is issued for that hostname.

Sign-in to the Ataccama identity provider

Each workload also signs in to your tenant’s IDP at https://<tenant_host>.ataccama.one. By default, this call goes directly to the IDP, not through the gateway.

The IDP accepts only allowlisted source IPs, so add your cluster’s public egress IPs to the IP allowlist in the tenant settings in the Cloud Portal. To send the call through the gateway instead, set global.agentic.gateway.keycloakEnabled: true, as described in Ataccama Edge gateway.

Inbound and pod-to-pod traffic

  • Inbound traffic: None. The chart creates no Ingress or LoadBalancer resources.

  • Pod-to-pod traffic: None. Job pods don’t call edge-plane-manager or each other; the plane manager tracks them through the Kubernetes API. A default-deny NetworkPolicy between Kubernetes edge pods is safe as long as health probes and the egress listed in Required connections stay open.

Checklist before installation

Confirm the following before you install the Kubernetes edge:

  • Each data source can be reached from the Kubernetes edge namespace on its own port.

  • <storage_account>.blob.core.windows.net:443 can be reached and the identity has the permissions listed in Required permissions.

  • <key_vault>.vault.azure.net:443 can be reached and the identity can get and unwrap the key (if encryption is on).

  • The credentials vault can be reached and the secret management service application has Key Vault Secrets User (if you keep credentials there).

  • login.microsoftonline.com:443 can be reached.

  • The private endpoint to the Ataccama Edge gateway is approved, and the gateway hostname resolves to its private IP from a pod.

  • <tenant_host>.ataccama.one:443 can be reached and your egress IPs are on the IDP allowlist in the Cloud Portal, or keycloakEnabled is set.

  • Cluster nodes can pull from ataccama.azurecr.io, or the images are mirrored to your registry.

Next steps

Was this page useful?