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.
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:
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.
Internally, when the Secretless Broker receives a new connection request: