How it works

In a Secretless Broker deployment, when a client needs access to a Target Service it doesn't try to make a direct connection to it. Instead, it sends the request through its Secretless Broker.

The Secretless Broker authenticates with a secrets vault and obtains an identity credential. This identity credential is managed securely within the Secretless Broker, and used to obtain a secret to access the Target Service such as a database password from the secrets vault. The connection secrets are managed entirely within the Secretless Broker process, and never exposed to the client. The Secretless Broker uses the connection secret to establish a connection to the Target Service and then transmits data between the client and the target.

Standard Workflow

  1. A Client (user or code) connects to the Secretless Broker (a local service) to obtain a connection to the Target Service (a database, server or web service).

  2. If needed, the Secretless Broker authenticates with an external vault to obtain an identity credential, which is managed securely within the Secretless Broker process.

  3. The Secretless Broker uses the identity credential to obtain secrets which allow access to the Target Service. Secrets are managed securely by the Secretless Broker process.

  4. Secretless Broker uses the secrets to open a connection to the Target Service.

  5. Secretless Broker pipes traffic between the Client and the Target Service.

  6. If a secret is changed either manually or with a rotator, the Broker automatically obtains the new secret and uses it when establishing new connections.

    Secretless eliminates the need to restart any service when a secret is rotated.

The Secretless Broker is a proxy that intercepts traffic to the Target Service and performs the authentication phase of the back-end protocol. The data-transfer phases of the protocol are direct pass-through between the client and Target Service.

Examples of protocols that can be brokered:

  • Database protocols such as Oracle, Postgresql, MySQL, NoSQL flavors, etc.

  • HTTP via Authorization header

  • SSH, via MITM or by implementing an ssh-agent

Any published protocol can be supported in the Secretless Broker. Software code in the Secretless Broker is generally required for each new protocol. For a list of currently supported Target Services, visit the Service Connectors.

The Secretless Broker typically runs locally alongside the client application. Authentication between the Client and the Secretless Broker is managed by the operating system, e.g. local connection via Unix socket or HTTP connection to In container-managed environments such as Kubernetes, the Secretless Broker can be a "sidecar" container which is securely networked to the application container.

Internal Architecture

Internally, when the Secretless Broker receives a new connection request:

  1. The Proxy determines the Service Connector to send the request to, based on the port / socket the request was sent to.

  2. The Service Connector receives the connection request and retrieves credentials using a Credential Provider

  3. The Service Connector injects the credentials into a new connection request and opens a new connection to the Target Service

  4. The Service Connector streams the connection