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

# Credentials and Secrets

This page covers how credentials flow through the system and the guarantees we make about their handling.

## Credential Ownership

There are three categories of credentials in a deployment:

### Credentials You Provide

These are secrets the application needs from you - API keys, tokens, database passwords, webhook URLs. During setup, the interface tells you exactly what's required and gives you the commands to create them.

**How they flow:**

<Steps>
  <Step title="Run command">
    You run a command on your workstation (kubectl or AWS CLI).
  </Step>

  <Step title="Secret created locally">
    The secret goes directly from your terminal into your cluster or cloud secret manager.
  </Step>

  <Step title="Detection">
    The controller detects the secret exists.
  </Step>

  <Step title="Confirmation">
    The setup interface updates to show a checkmark.
  </Step>
</Steps>

At no point does the secret value pass through our systems. The path is: **your terminal - your infrastructure**. We see only the checkmark.

### Credentials We Provide

Some secrets come from us - internal service credentials, license keys, or pre-configured tokens. These are injected automatically during deployment. You don't need to create or manage them.

### Credentials Generated at Deploy Time

Some secrets are generated fresh during deployment - random passwords, internal tokens, auto-generated keys. These are created directly in your infrastructure by the controller. They never transit through our systems.

## Where Secrets Are Stored

<Tabs>
  <Tab title="Kubernetes">
    Kubernetes Secrets (in your namespace), created by you via kubectl.
  </Tab>

  <Tab title="AWS">
    AWS Systems Manager Parameter Store or AWS Secrets Manager (in your account), created by you via AWS CLI or console.
  </Tab>
</Tabs>

## During Part 2 Configuration

After the controller is online, some deployments have a second configuration step where you provide secrets and domain settings. This step uses a direct connection:

<Steps>
  <Step title="Start">
    You run a setup command on your workstation.
  </Step>

  <Step title="Local server">
    A local server starts on your machine (localhost only).
  </Step>

  <Step title="Direct connection">
    The server communicates directly with the controller **over your network**.
  </Step>

  <Step title="Secrets stay local">
    Secrets travel from your workstation to your controller.
  </Step>

  <Step title="No external transit">
    The connection never leaves your infrastructure.
  </Step>
</Steps>

This means even during interactive configuration, your secrets stay within your network perimeter.

## Secret Rotation

You can rotate any secret you created by replacing it in your secret store:

<Tabs>
  <Tab title="Kubernetes">
    ```bash theme={null}
    kubectl delete secret <name> -n <namespace>
    kubectl create secret generic <name> -n <namespace> --from-literal=key=<new-value>
    ```
  </Tab>

  <Tab title="AWS">
    **AWS Secrets Manager:**

    ```bash theme={null}
    aws secretsmanager update-secret --secret-id <name> --secret-string <new-value>
    ```

    **AWS Systems Manager Parameter Store:**

    ```bash theme={null}
    aws ssm put-parameter --name <name> --value <new-value> --type SecureString --overwrite
    ```
  </Tab>
</Tabs>

The controller detects the change automatically. In most cases, no application restart is needed.

## What We Guarantee

* **We never see your secret values** - only existence/absence status
* **We never store your credentials** on our infrastructure
* **We never transmit your secrets** over the network between your infrastructure and ours
* **You can rotate at any time** without coordinating with us

## Related

* [Secrets (Configuration)](/customer/configuration/secrets) - How to create secrets during setup
* [Security Model](/customer/security/security-model) - The overall security architecture