Access Broker Deployment

The Britive Access Broker is a small service — a single static binary, no runtime to install — that runs inside your infrastructure and lets the Britive platform manage just-in-time access to resources that aren’t reachable as cloud applications: servers, databases, network devices, and Kubernetes clusters. The broker opens an outbound connection to Britive, so no inbound firewall rules or public endpoints are required.

Deploy it once, then point any broker-based integration (Linux, Windows, databases, Cisco, VyOS, and more) at the broker pool it registers with.

How It Works

    flowchart LR
    subgraph YourInfra["Your Infrastructure"]
        Broker["Access Broker<br/>(runs in your env)<br/>Runs checkout / checkin scripts against targets"]
    end

    subgraph BritivePlatform["Britive Platform"]
        SaaS["Britive SaaS<br/>&lt;tenant&gt;.britive-app.com"]
    end

    Broker -->|"outbound HTTPS + MQTT over TLS, port 443"| SaaS

At startup the broker bootstraps against your tenant with a broker pool token, then holds one long-lived MQTT-over-TLS connection on which it receives checkout, check-in and scan requests. Tenant subdomain and token are all it needs; they are passed as environment variables (BRITIVE_BROKER_TENANT_SUBDOMAIN, BRITIVE_BROKER_AUTH_TOKEN). A broker-config.yml is optional and only restricts resource types or configures a proxy. Several brokers can share a pool; Britive load-balances across them.

Network requirement: outbound 443 to <tenant>.britive-app.com, to the MQTT host under .britive-app.com returned by bootstrap, and to the presigned Amazon S3 URLs scripts are fetched from. No inbound rules needed.

These guides deploy Broker 3.x. Broker 2.0 and below (the Java JAR) are deprecated by Britive and not supported by the templates. The broker package is downloaded from your tenant under System Administration → Brokers and Broker Pools → Download Brokers; there is no public download URL.

Choose a Deployment Option

Option	Platform	Kubernetes required	Secret storage	Best for
ECS Fargate	AWS	No	AWS Secrets Manager	AWS-native, serverless, no cluster to manage
EKS	AWS	Yes	Kubernetes Secret, or External Secrets / Secrets Store CSI	Existing AWS EKS clusters
AKS	Azure	Yes	Kubernetes Secret, or External Secrets / Secrets Store CSI	Existing Azure AKS clusters
GKE	Google Cloud	Yes	Kubernetes Secret, or External Secrets / Secrets Store CSI	Existing Google GKE clusters

The three Kubernetes options use the same Helm chart and the same container image; only the registry and the workload identity differ. The onboarding repository also covers a Linux VM with systemd and Docker Compose for evaluations.

No Kubernetes cluster yet? Use ECS Fargate — two CloudFormation stacks, with the token in AWS Secrets Manager. Already running Kubernetes? Use the deployment that matches your cloud.

Upgrading from 2.x to 3.x

Follow the runbook to upgrade from Access Broker 2.x to 3.x.

In This Section

Deploy on ECS Fargate
Run the Britive Access Broker as a serverless container on AWS ECS Fargate with two CloudFormation stacks from the onboarding repository, the pool token in AWS Secrets Manager.
Deploy on EKS
Run the Britive Access Broker on an existing Amazon EKS cluster with the Helm chart from the onboarding repository, the image in ECR and the pool token in a Kubernetes Secret.
Deploy on AKS
Run the Britive Access Broker on an existing Azure AKS cluster with the Helm chart from the onboarding repository, the image in Azure Container Registry and the pool token in a Kubernetes Secret.
Deploy on GKE
Run the Britive Access Broker on an existing Google GKE cluster with the Helm chart from the onboarding repository, the image in Artifact Registry and the pool token in a Kubernetes Secret.
Upgrade Broker 2.x to 3.x
Runbook for upgrading the Britive Access Broker in place from the Java-based 2.x release to the native 3.x binary on Linux (rpm, deb) and Windows (MSI).

Last updated on October 13, 2026