FabricFabricHarness
Operating

Private networking and egress

Enforce outbound policy at container, cluster, and cloud-provider boundaries, with proxy, DNS, custom CA, and mTLS support.

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.

Rendering diagram...

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, Vector 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.