How Secretless Works

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

The Secretless Broker authenticates with a secrets vault and obtains an identity credential. The identity credential is managed securely within the Secretless Broker, and is used to obtain a secret in order 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 are 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 Secretless 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 that 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 include:

  • 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, see the Secretless 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 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 Secretless architecture

Internally, when Secretless starts, it also starts the Proxy Services for each configured service and ensures that they are each listening on the appropriate socket.

When Secretless receives a new connection request on a given socket:

  1. The request is automatically received by the Proxy Service configured for that service.

  2. The Proxy Service invokes the appropriate Credential Provider(s) to retrieve the required credentials.

  3. The Proxy Service invokes the appropriate Service Connector to perform the authentication handshake.

  4. Secretless seamlessly streams the connection.