Private networking and egress

Fabric applies URL, DNS-answer, and redirect policy before supported HTTP calls. Production deployments also need a boundary outside the agent process. That second layer prevents a custom tool, dependency, or direct socket from bypassing the application policy.

flowchart LR
  A[Agent process] -->|policy-checked request| P[Internal egress proxy]
  A -. direct socket denied .-> X[Public or private service]
  P -->|domain and port allowlist| D[Databricks workspace APIs]
  P -->|private DNS| E[Private endpoints]

  subgraph Boundary[Container, cluster, or provider boundary]
    A
    P
  end

  classDef runtime fill:#e8f0fe,stroke:#2563eb,color:#172554
  classDef control fill:#fff4d6,stroke:#d97706,color:#451a03
  classDef service fill:#dcfce7,stroke:#16a34a,color:#052e16
  classDef denied fill:#fee2e2,stroke:#dc2626,color:#450a0a
  class A runtime
  class P control
  class D,E service
  class X denied

Require an enforceable boundary

assertEnforceableNetworkPolicy() rejects a network policy backed only by process-level checks. Call it during production startup after creating the sandbox:

import {
  DockerSandboxEnv,
  assertEnforceableNetworkPolicy,
  type CapabilityPolicy,
} from '@fabric-harness/sdk';

const policy: CapabilityPolicy = {
  network: {
    mode: 'allowlist',
    protocols: ['https:'],
    hosts: ['*.azuredatabricks.net', '*.databricks.com'],
    resolveDns: true,
  },
};

const sandbox = new DockerSandboxEnv({
  workspacePath: process.cwd(),
  network: 'fabric-agent-internal',
  networkBoundary: {
    enforcement: 'container',
    reference: 'docker-network:fabric-agent-internal+egress-proxy',
  },
});

assertEnforceableNetworkPolicy(policy, sandbox, {
  deployment: 'production',
});

The networkBoundary value is an operator assertion, not a network provisioner. Create the Docker network with internal: true, connect the agent only to that network, and connect an independently configured proxy to both the internal and destination networks. The private-networking example contains a runnable Compose topology that proves a proxied request succeeds while a direct request fails.

Proxy, custom CA, and mTLS

Use one transport factory for connectors that require enterprise TLS settings:

import { readFile } from 'node:fs/promises';
import { createPrivateNetworkFetch } from '@fabric-harness/node';

const client = createPrivateNetworkFetch({
  proxy: {
    url: process.env.HTTPS_PROXY!,
    authorization: `Bearer ${process.env.EGRESS_PROXY_TOKEN!}`,
  },
  tls: {
    ca: await readFile('/var/run/fabric-secrets/private-ca.pem'),
    cert: await readFile('/var/run/fabric-secrets/client.crt'),
    key: await readFile('/var/run/fabric-secrets/client.key'),
  },
  policy,
});

try {
  const response = await client.fetch(`${process.env.DATABRICKS_HOST}/api/2.0/clusters/list`);
  if (!response.ok) throw new Error(`Workspace request failed: ${response.status}`);
} finally {
  await client.close();
}

Keep proxy authorization and PEM material in a secret provider or mounted secret volume. Proxy URLs with embedded credentials are rejected so credentials cannot appear in URL logs. rejectUnauthorized defaults to true; do not disable certificate verification in production.

Kubernetes and AKS

createKubernetesEgressNetworkPolicy() emits deny-by-default egress with only three permitted paths:

1. selected cluster DNS pods on TCP/UDP 53;
2. a selected egress proxy on one TCP port;
3. explicitly listed private CIDRs and ports.

import {
  createKubernetesEgressNetworkPolicy,
  kubernetesSandbox,
} from '@fabric-harness/connectors/k8s';

const manifest = createKubernetesEgressNetworkPolicy({
  namespace: 'fabric-agents',
  podSelector: { 'app.kubernetes.io/name': 'fabric-agent' },
  egressProxy: {
    namespaceSelector: { 'kubernetes.io/metadata.name': 'networking' },
    podSelector: { 'app.kubernetes.io/name': 'fabric-egress-proxy' },
    port: 3128,
  },
  privateCidrs: [{ cidr: '10.40.0.0/24', ports: [443] }],
});

// Apply `manifest` with the cluster API before attaching the pod.
const sandbox = kubernetesSandbox(pod, {
  networkPolicy: {
    namespace: manifest.metadata.namespace,
    name: manifest.metadata.name,
  },
});

The generator rejects public CIDRs. Route public destinations through the proxy, where FQDN and certificate policy can be enforced. On AKS, combine this policy with Azure CNI, private clusters, Private Link, private DNS zones, workload identity, and an Azure Firewall or proxy route. Mount custom trust bundles and client certificates through the Secrets Store CSI Driver.

Databricks private connectivity

For Databricks Apps, keep the workspace identity supplied by the platform and configure connectivity at the workspace/account layer:

• use workspace private connectivity for front-end and back-end API paths;
• route SQL Warehouse, Model Serving, AI Search, Lakebase, and Unity Catalog traffic through approved private endpoints where the workspace feature supports them;
• use workspace DNS names in the Fabric allowlist and resolve them through the private DNS path;
• exchange the App identity for short-lived Lakebase credentials instead of storing a database password;
• store attachments in Unity Catalog Volumes and use service-principal or on-behalf-of identity, never embedded cloud storage keys.

See Databricks architecture, enterprise Databricks controls, and Databricks Apps deployment for the complete identity and data flow.

Verification checklist

• A direct request with proxy settings disabled cannot reach its destination.
• An allowed proxied request succeeds; a non-allowlisted hostname is denied by the proxy.
• Private DNS resolves only to the expected private ranges.
• An untrusted server certificate fails, while the configured private CA succeeds.
• The server requires and validates the expected client certificate.
• assertEnforceableNetworkPolicy() passes with a named container, cluster, or provider boundary.
• Logs, traces, errors, and build artifacts contain no proxy credentials, client keys, or workspace tokens.