On this page
Connection credentials
Configure the credential types consumed by supported Golden sources and destinations without exposing secret-storage details.
A credentials resource holds authentication material referenced by a source
or destination. Give each integration its own remote-system account and Golden
credential so it can be rotated or revoked independently.
Choose a supported type
| Credential type | Supported consumer |
|---|---|
NONE | A connection that deliberately sends no credential |
PASSWORD | JDBC and Kafka connections; HTTP sinks use it for basic authentication |
TOKEN | HTTP sinks, which send it as a bearer credential |
SSH | No currently supported source or destination consumes this type |
Do not select SSH merely because the editor accepts it. A saved credential is
not proof that the referenced source or destination can use it.
Configure a password credential
{
"type": "credentials",
"_id": "orders_credentials",
"description": "Orders database service account",
"credentialType": "PASSWORD",
"user": "golden_orders",
"password": "<secret-from-your-secret-process>"
}
Use a service account rather than a person’s account. The remote system records this user in its own connection and audit activity.
Configure an HTTP bearer credential
{
"type": "credentials",
"_id": "receiver_credentials",
"description": "Customer receiver token",
"credentialType": "TOKEN",
"token": "<token-value-only>"
}
Supply the token value without the Bearer prefix. The HTTP destination adds
the authorization scheme.
Validate and rotate
- Create the credential through the approved administrator workflow.
- Reference its
_idfrom the source or destination. - Test the consuming resource with controlled data.
- Rotate the secret in both systems and repeat the resource test.
- Remove credentials that no active resource references.
Keep credential values out of source control, logs, and support messages.