# Credential

Credential features let Sandbox0 authenticate outbound traffic without placing raw secret material inside the sandbox process.

<Callout variant="info">
Credential sources are team-scoped objects. In Sandbox0 Cloud, sign in with `s0 auth login`, select the correct current team, and create API keys only when you need SDK or raw HTTP access.
</Callout>

## The Three Objects

| Object | What it stores | Where it lives |
|-------|----------------|----------------|
| `credential source` | Secret material such as tokens, headers, client certificates, or username/password pairs | Team-scoped credential source API |
| `credential binding` | A stable local `ref` plus projection rules that map a source into a runtime auth shape | `network.credentialBindings` |
| `credential rule` | Destination match rules that decide when outbound auth should be injected | `network.egress.credentialRules` |

These objects work together: create a source, expose it through a stable binding `ref`, and then match outbound traffic with `credentialRules` that reference that `ref`. Keep traffic control separate with `trafficRules`.

<Callout variant="info">
`trafficRules` and `credentialRules` are orthogonal. `trafficRules` decide whether traffic is allowed. `credentialRules` decide whether matching traffic gets outbound authentication.
</Callout>

## Where You Configure It

`credentialBindings` now live under the same `network` object everywhere:

- Template defaults: `spec.network`
- Claim-time config: `config.network`
- Runtime update: `PUT /api/v1/sandboxes/{id}/network`

That public shape is `SandboxNetworkPolicy` in all three places.

## Supported Projections

| Projection type | Typical use |
|----------------|-------------|
| `http_headers` | Inject HTTP or gRPC headers such as `Authorization` |
| `placeholder_substitution` | Replace sandbox-visible placeholders in HTTP headers, query values, or request bodies at the egress boundary |
| `tls_client_certificate` | Present a client certificate during TLS terminate-reoriginate flows |
| `username_password` | Provide username/password material for protocols such as SOCKS5 or MQTT |
| `ssh_proxy` | Proxy SSH authentication without writing the upstream private key into the sandbox |

## Supported Source Types

| Resolver kind | Purpose |
|--------------|---------|
| `static_headers` | Store named header values or tokens |
| `static_tls_client_certificate` | Store certificate PEM, private key PEM, and optional CA PEM |
| `static_username_password` | Store a username/password pair |
| `static_ssh_private_key` | Store a private key for SSH transparent proxy upstream auth |

## Credential Storage

Credential source storage is configured by the Sandbox0 platform. Sandbox0 supports encrypted PostgreSQL storage and Vault-compatible storage backends. API users create and use credential sources through the same public API in either mode; backend selection is not part of the credential source request.

For self-hosted backend configuration, see [Self-hosted Configuration](/docs/sandbox/self-hosted/configuration#credential-source-storage).

## Next Steps

<CardGroup>
  <Card title="Sources" href="/docs/sandbox/credential/sources" cta="Continue">
    Create reusable credential sources for runtime projection.
  </Card>

  <Card title="Egress Auth" href="/docs/sandbox/credential/egress-auth" cta="Continue">
    Inject destination-scoped outbound credentials through network policy.
  </Card>
</CardGroup>