How Does It Work?

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 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, the Broker automatically obtains the new secret and uses it when establishing new connections.

The Secretless Broker is a proxy that intercepts traffic to the Target Service and performs the authentication phase of the backend 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, please see our documentation on Handlers.

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 127.0.0.1. 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 Listener to send the request to, based on the port / socket the request was sent to (there is a Listener for each potential connection to a Target Service)
2. The Listener receives the connection request, and forwards it to its Handler
3. The Handler retrieves credentials using a Credential Provider
4. The Handler injects the credentials into a new connection request and opens a new connection to the Target Service
5. The Handler streams the connection