Skip to main content
Credentials are encrypted secret bundles that connections reference by ID. Keeping secrets out of pipeline definitions lets you rotate keys, revoke OAuth grants, and audit access without redeploying every job.

​
Credential types

Planasonix models credentials by how they authenticate external systems:
TypeContainsTypical use
AWSAccess key ID and secret, or role ARN for assume-role chainsS3, Glue, Kinesis, Redshift IAM auth
AzureClient secret, certificate, or managed identity bindingBlob, Synapse, Fabric, Microsoft Graph
GCPService account JSON or workload federation configGCS, BigQuery, Vertex AI
DatabaseUsername and password, sometimes with SSH tunnel keysPostgreSQL, MySQL, SQL Server, Oracle
API keySingle or multi-part keys, optional custom headersREST vendors, AI providers, webhook verification secrets
OAuthClient ID/secret plus stored refresh material after consentSalesforce, Google, HubSpot, many SaaS apps
PasswordGeneric password material for protocols that are not SQLFTP, legacy HTTP basic, some LDAP bridges
The UI may show only the credential types enabled for your organization. If you need a new pattern (for example HashiCorp Vault dynamic secrets), contact your Planasonix administrator about enterprise integrations.

​
Sharing and permissions

Credentials live in a workspace or organization boundary depending on your tenancy model. You control:
  • Who can create new credentials (often restricted to integration engineers or admins).
  • Who can attach existing credentials to new connections (broader builder role).
  • Who can read secret values after creation—typically nobody can view the plaintext again; users rotate by replacing the credential.
Connections reference credentials; pipelines reference connections. That layering means you can grant a developer permission to build jobs with a shared prod-snowflake connection without handing them the underlying warehouse password. Use environment tags or naming conventions (dev-, staging-, prod-) so accidental attachment to the wrong connection is visible in reviews.

​
Credential lifecycle

1

Create the credential in the right scope

Open Credentials, choose the type that matches the target system, and enter secrets once. Label with environment, system, and owner team so future audits stay readable.
2

Link from a connection

Edit or create a connection and select the credential. Run Test connection to confirm the secret works from Planasonix workers before you schedule pipelines.
3

Rotate before expiry or after incidents

Create a new credential or update in place per product behavior, then test dependent connections. Revoke the old secret in the vendor or cloud console only after successful runs.
4

Review attachments quarterly

Export or view which connections use each credential and remove unused credentials. For OAuth, confirm authorized users still match headcount and role changes.

​
Best practices for security

Database passwords, cloud keys, and API keys should rotate at least as often as your security policy requires. After rotation, update the credential in Planasonix and run Test connection on dependent connections before decommissioning the old secret in the upstream system.
Where your cloud supports IAM roles, workload identity, or OIDC federation, use those instead of long-lived access keys. For databases, explore IAM database authentication or vault-generated dynamic credentials if your edition supports them.
Create separate OAuth apps or API keys per environment and workload. For Stripe-style restricted keys or GCP service accounts, grant the minimum IAM roles on the smallest resource scope (single bucket, single dataset).
Enable audit logs for credential creation, attachment, and failed authentication spikes. Tie alerts to your SIEM so revoked or expired credentials trigger incident workflows instead of silent job failures.
Document how to disable a compromised credential in Planasonix (revoke attachment, delete credential) and in the vendor console in parallel. Keep on-call runbooks outside the secret store itself.
When a team member leaves, review OAuth authorizations they performed and reauthorize SaaS connections under a service account or shared integration user where your policy allows automated jobs to continue uninterrupted.

Connections overview

How connections reference credentials across pipelines.

Databases

Database logins and IAM database authentication patterns.

Data warehouses

Snowflake key pairs, BigQuery service accounts, Databricks tokens, and more.

SaaS applications

OAuth consent flows and scoped SaaS access.