When configuring Sockets, sometimes it's needed to configure credentials. These credentials are needed for the connector to, for example authenticate to your upstream database. Credentials are sensitive, so instead of using Border0 to store your upstream credentials, we recommend keeping them local, and use environment variables, your favorite credential managers or secret vaults.
Border0 makes it easy for you to load credentials locally by the connector, so that you can integrate with existing secret managers and don't need to share your credentials with Border0. Instead, the connector can load them dynamically when needed, this way Border0 never sees your credentials.
The following credentials sources are supported. Note a dynamic credentials always starts with
|Credential source||credential format||details|
|Environment variable||the environment variable DB_USERNAME will be used as the credential.|
|File||the string found in the file /etc/database_username will be used as the credential.|
|AWS SSM parameter store||Here the secret is stored in AWS' SSM parameter store. Using the parameter path /my/path|
It's important the connector has proper IAM role to read from SSM parameter store
|AWS Secret manager||Here the secret is stored in AWS' Secret manager at the secret path /my/path|
It's important the connector has proper IAM role to read from AWS secret manager.
All fields in the "upstream" configuration settings for a particular socket accept the
Remember, If your secrets starts with
from:the Border0 connector will dynamically fetch the secret from the specified source.
Below are some typical examples of where you can use
from:to load your credentials locally on the connector in real time.
|SSH - Upstream connection type: standard SSH||SSH Username|
|AWS credentials||AWS Access Key ID|
AWS Secret Access Key
The screenshot below is an example configuration for a database socket. The credentials the Border0 connector needs to to communicate with the upstream database are dynamically loaded. Specifically the username is loaded from the environment variable
DATABASE_USERNAME while the password is loaded from AWS' SSM parameter store using the path
The Example below shows the upstream configuration for an SSH socket, using username and password authentication as the upstream authentication strategy. Here, instead of statically defining the actual username and password, the connector will load them dynamically. The username will be loaded from the file
/etc/ssh_usernameon the connector host. While the password is loaded from AWS' secret manager using the path
Updated 15 days ago