> ## Documentation Index
> Fetch the complete documentation index at: https://docs.planasonix.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Credentials management

> Securely manage connection credentials, OAuth tokens, and API keys.

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:

| Type         | Contains                                                     | Typical use                                              |
| ------------ | ------------------------------------------------------------ | -------------------------------------------------------- |
| **AWS**      | Access key ID and secret, or role ARN for assume-role chains | S3, Glue, Kinesis, Redshift IAM auth                     |
| **Azure**    | Client secret, certificate, or managed identity binding      | Blob, Synapse, Fabric, Microsoft Graph                   |
| **GCP**      | Service account JSON or workload federation config           | GCS, BigQuery, Vertex AI                                 |
| **Database** | Username and password, sometimes with SSH tunnel keys        | PostgreSQL, MySQL, SQL Server, Oracle                    |
| **API key**  | Single or multi-part keys, optional custom headers           | REST vendors, AI providers, webhook verification secrets |
| **OAuth**    | Client ID/secret plus stored refresh material after consent  | Salesforce, Google, HubSpot, many SaaS apps              |
| **Password** | Generic password material for protocols that are not SQL     | FTP, legacy HTTP basic, some LDAP bridges                |

<Info>
  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.
</Info>

## 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

<Steps>
  <Step title="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.
  </Step>

  <Step title="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.
  </Step>

  <Step title="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.
  </Step>

  <Step title="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.
  </Step>
</Steps>

## Best practices for security

<AccordionGroup>
  <Accordion title="Rotate on a schedule">
    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.
  </Accordion>

  <Accordion title="Prefer short-lived credentials">
    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.
  </Accordion>

  <Accordion title="Scope OAuth and API keys narrowly">
    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).
  </Accordion>

  <Accordion title="Monitor and alert">
    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.
  </Accordion>

  <Accordion title="Break glass for emergencies">
    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.
  </Accordion>
</AccordionGroup>

<Tip>
  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.
</Tip>

## Related topics

<CardGroup cols={2}>
  <Card title="Connections overview" icon="plug" href="/connections/overview">
    How connections reference credentials across pipelines.
  </Card>

  <Card title="Databases" icon="database" href="/connections/databases">
    Database logins and IAM database authentication patterns.
  </Card>

  <Card title="Data warehouses" icon="warehouse" href="/connections/data-warehouses">
    Snowflake key pairs, BigQuery service accounts, Databricks tokens, and more.
  </Card>

  <Card title="SaaS applications" icon="building-2" href="/connections/saas-applications">
    OAuth consent flows and scoped SaaS access.
  </Card>
</CardGroup>