Keep the personal half of the desktop in one place, and ask before installing it

Agent instructions, skills, SSH host aliases and expansion triggers are worth having identical on every machine one person owns, and belong in none of the shared configuration. They live in user/ now, with a manifest saying where each piece goes and a link-user stage that puts it there. That stage does nothing unless the machine said yes. Somebody who clones Panama to try the desktop keeps their own ~/.claude/CLAUDE.md exactly where it was; the question names the destinations and defaults to no. Anything displaced goes to config/old rather than being deleted. ~/.claude/CLAUDE.md and ~/.codex/AGENTS.md were byte-identical copies of one file, which is the drift this exists to prevent. Also adds the vitals toggles for the battery and Claude usage readouts, which had preferences and no way to reach them.
2026-08-22 08:54:43 -04:00
parent 8b96d907a1
commit 89761a7da3
156 changed files with 16439 additions and 6 deletions
@@ -0,0 +1,40 @@
+---
+name: infisical-dynamic-secrets
+description: "Guide for configuring Infisical Dynamic Secrets — on-demand, short-lived credentials for databases, cloud IAM, SSH, and Kubernetes. Covers 27 providers including PostgreSQL, MySQL, Redis, MongoDB, AWS IAM, GCP IAM, SSH certificates, Kubernetes service accounts, and more. Use this skill when someone asks about: dynamic secrets, ephemeral database credentials, short-lived tokens, rotating database users, dynamic PostgreSQL/MySQL/Redis credentials, SSH certificates, temporary AWS IAM users, or 'how do I generate temporary credentials with Infisical'."
+---
+
+# Infisical Dynamic Secrets Guide
+
+You are a setup assistant helping users configure Infisical Dynamic Secrets — on-demand, short-lived credentials that are unique per identity and automatically expire.
+
+## How to use this skill
+
+Start by understanding what resource the user needs dynamic credentials for, then guide them through:
+
+1. **Prerequisites** — What database user, IAM role, or service account needs to exist first
+2. **Provider selection** — Choose the right dynamic secret type
+3. **Configuration** — Host, port, credentials, TTL settings, creation statements
+4. **Lease management** — How to generate, renew, and revoke leases
+5. **Gateway setup** — If accessing private resources (databases behind VPNs/VPCs)
+
+Read the relevant reference file(s) for the user's provider, then walk them through step by step.
+
+## Reference files
+
+| File | When to read |
+|------|-------------|
+| `references/overview.md` | User asks general questions about how dynamic secrets work, concepts, or lease lifecycle |
+| `references/sql-databases.md` | User wants dynamic credentials for PostgreSQL, MySQL, MSSQL, Cassandra, Oracle, or other SQL databases |
+| `references/nosql-and-cache.md` | User wants dynamic credentials for Redis, MongoDB, or Elasticsearch |
+| `references/cloud-iam.md` | User wants dynamic AWS IAM users/credentials or GCP service account tokens |
+| `references/ssh-and-kubernetes.md` | User wants SSH certificates or Kubernetes service account tokens |
+
+## Guiding principles
+
+- **Short TTLs for security.** Recommend the shortest practical TTL. Dynamic secrets are meant to be ephemeral — minutes to hours, not days.
+- **Gateway for private networks.** If the database is in a VPC/private subnet, they need an Infisical Gateway deployed in the same network. This is an Enterprise feature.
+- **Pre-existing admin user required.** The user must have a database admin user (or IAM role) that Infisical can use to create/revoke dynamic credentials. Infisical doesn't create this for them.
+- **SQL statements matter.** For SQL databases, the default creation statements grant broad access. Recommend customizing them to follow least privilege (specific tables, read-only, etc.).
+- **Some tokens can't be revoked.** GCP service account tokens and Kubernetes tokens are JWTs with baked-in expiration — revoking the lease in Infisical removes the record but the token stays valid until TTL expiry. Emphasize short TTLs.
+- **SSH certificates can't be renewed.** The TTL is baked in at signing time. Users must create a new lease for a fresh certificate.
+- **AWS STS has duration limits.** AssumeRole: max 1 hour. Access Key/IRSA: max 12 hours. Infisical auto-adjusts if exceeded.
@@ -0,0 +1,139 @@
+# Dynamic Secrets: Cloud IAM
+
+## AWS IAM
+
+### Overview
+Generate on-demand AWS IAM credentials — either full IAM Users with access keys, or temporary STS credentials. Three authentication methods available.
+
+### Credential Types
+
+**IAM User** — Creates a real IAM user with long-lived access keys. User is deleted when the lease expires.
+
+**Temporary Credentials** — Generates short-lived STS credentials (access key + secret key + session token) via AssumeRole or GetSessionToken. No IAM user is created.
+
+### Authentication Methods
+
+#### 1. Assume Role (Recommended for Cloud)
+Infisical assumes an IAM role in your AWS account to create credentials.
+
+**Cloud Setup:**
+1. Create an IAM Role in your AWS account
+2. Trusted Entity: **Another AWS Account**
+3. Infisical Account ID: `381492033652` (US) or `345594589636` (EU)
+4. Recommended: Enable "Require external ID" with your Infisical Project ID
+5. Attach the required permissions policy (see below)
+6. Copy the Role ARN
+
+**Config fields:** AWS Role ARN, AWS Region
+
+#### 2. IRSA (EKS)
+For Infisical running on EKS — uses IAM Roles for Service Accounts.
+
+**Prerequisite:** Set `KUBERNETES_AUTO_FETCH_SERVICE_ACCOUNT_TOKEN=true` on the Infisical instance.
+
+**Setup:**
+1. Create IAM OIDC provider for your EKS cluster
+2. Create IAM Role trusting the OIDC provider with audience `sts.amazonaws.com`
+3. Annotate the Infisical service account with the role ARN
+
+**Config fields:** Same as Assume Role
+
+#### 3. Access Key (Self-hosted / non-AWS)
+Direct IAM access key authentication.
+
+**Config fields:** AWS Access Key, AWS Secret Key, AWS Region
+
+### IAM User Credential Config
+| Field | Required | Description |
+|-------|----------|-------------|
+| AWS IAM Path | No | IAM path prefix for created users |
+| Permission Boundary | No | IAM policy ARN to use as permission boundary |
+| AWS IAM Groups | No | Comma-separated group names to add user to |
+| AWS Policy ARNs | No | Comma-separated policy ARNs to attach |
+| AWS IAM Policy Document | No | Inline JSON policy document |
+| Tags | No | Key-value tags for the IAM user |
+
+### Required IAM Permissions
+
+**For IAM User credential type:**
+```json
+{
+  "Version": "2012-10-17",
+  "Statement": [{
+    "Effect": "Allow",
+    "Action": [
+      "iam:AttachUserPolicy", "iam:CreateAccessKey", "iam:CreateUser",
+      "iam:DeleteAccessKey", "iam:DeleteUser", "iam:DeleteUserPolicy",
+      "iam:DetachUserPolicy", "iam:GetUser", "iam:ListAccessKeys",
+      "iam:ListAttachedUserPolicies", "iam:ListGroupsForUser",
+      "iam:ListUserPolicies", "iam:PutUserPolicy",
+      "iam:AddUserToGroup", "iam:RemoveUserFromGroup", "iam:TagUser"
+    ],
+    "Resource": ["*"]
+  }]
+}
+```
+
+**For Temporary Credentials:**
+```json
+{
+  "Version": "2012-10-17",
+  "Statement": [{
+    "Effect": "Allow",
+    "Action": ["sts:GetSessionToken", "sts:AssumeRole"],
+    "Resource": ["*"]
+  }]
+}
+```
+
+### AWS STS Duration Limits
+| Method | Max Duration |
+|--------|-------------|
+| AssumeRole (temporary credentials) | **1 hour** (3600s) |
+| Access Key / IRSA (GetSessionToken) | **12 hours** (43200s) |
+
+Infisical auto-adjusts TTL if it exceeds these limits.
+
+### Lease Returns (IAM User)
+- `ACCESS_KEY` — AWS Access Key ID
+- `SECRET_ACCESS_KEY` — AWS Secret Access Key
+- `USERNAME` — IAM username
+
+### Lease Returns (Temporary Credentials)
+- `ACCESS_KEY` — AWS Access Key ID
+- `SECRET_ACCESS_KEY` — AWS Secret Access Key
+- `SESSION_TOKEN` — STS session token
+
+---
+
+## GCP IAM
+
+### Overview
+Generate on-demand GCP service account access tokens via service account impersonation.
+
+### Prerequisites
+- Enable **IAM API** and **IAM Credentials API** in your GCP project
+- Create a GCP Service Account with the roles you want tokens to inherit
+- Grant **Service Account Token Creator** role to Infisical's service account on your service account
+
+**Infisical Cloud service accounts:**
+- US: `[email protected]`
+- EU: `[email protected]`
+
+**Self-hosted:** Create a dedicated service account, download JSON key, set `INF_APP_CONNECTION_GCP_SERVICE_ACCOUNT_CREDENTIAL` env var.
+
+### Configuration
+| Field | Required | Description |
+|-------|----------|-------------|
+| Secret Name | Yes | Name for this dynamic secret |
+| Default TTL | Yes | Default lease duration |
+| Max TTL | Yes | Maximum lease duration |
+| Service Account Email | Yes | Email of the GCP service account to impersonate |
+
+### Lease Returns
+- Access token (OAuth2 bearer token)
+
+### Gotchas
+- **GCP tokens CANNOT be revoked.** Revoking a lease in Infisical removes the record, but the token remains valid until its TTL expires. Use short TTLs.
+- The generated token inherits all roles assigned to the impersonated service account
+- Two separate GCP APIs must be enabled (IAM API + IAM Credentials API)
@@ -0,0 +1,123 @@
+# Dynamic Secrets: NoSQL & Cache
+
+## Redis
+
+### Prerequisites
+- A Redis user with permissions to create ACL users (often the `default` or `admin` user)
+
+### Configuration
+| Field | Required | Description |
+|-------|----------|-------------|
+| Secret Name | Yes | Name for this dynamic secret |
+| Default TTL | Yes | Default lease duration |
+| Max TTL | Yes | Maximum lease duration |
+| Host | Yes | Redis hostname or IP address |
+| Port | Yes | Redis port (default: `6379`) |
+| User | Yes | Admin user (often `default` or `admin`) |
+| Password | No | Required if Redis is password-protected |
+| CA (SSL) | No | CA certificate (common for managed Redis like AWS ElastiCache, Azure Cache) |
+
+### Redis ACL Statements (Customizable)
+Default creates a user with broad access. Customize for least privilege:
+
+```
+-- Example: Read-only access to keys with prefix "app:"
+ACL SETUSER {{username}} on >{{password}} ~app:* +get +mget +scan +keys
+```
+
+**Template variables:** `{{username}}`, `{{password}}`
+
+### Lease Returns
+- `DB_USERNAME` — Generated username
+- `DB_PASSWORD` — Generated password
+
+### Gotchas
+- Requires Redis 6+ with ACL support
+- Managed Redis services (ElastiCache, Azure Cache) often require SSL — use the CA field
+
+---
+
+## MongoDB
+
+### Prerequisites
+- A MongoDB user with `userAdmin` or `userAdminAnyDatabase` role
+- **Important:** For MongoDB Atlas, use the separate **MongoDB Atlas** dynamic secret provider — standard MongoDB commands are not supported by Atlas
+
+### Configuration
+| Field | Required | Description |
+|-------|----------|-------------|
+| Secret Name | Yes | Name for this dynamic secret |
+| Default TTL | Yes | Default lease duration |
+| Max TTL | Yes | Maximum lease duration |
+| Host | Yes | MongoDB host URL |
+| Port | No | Omit if using a cluster/replica set connection string |
+| User | Yes | Admin user with userAdmin privileges |
+| Password | Yes | Admin user password |
+| Database Name | Yes | Target database for the dynamic user |
+| Roles | Yes | List of MongoDB roles to assign |
+| CA (SSL) | No | CA certificate for TLS connections |
+
+### MongoDB Roles
+Built-in roles include:
+- `read`, `readWrite` — Database-level
+- `dbAdmin`, `dbAdminAnyDatabase` — Admin
+- `readAnyDatabase`, `readWriteAnyDatabase` — Cross-database
+- `clusterMonitor`, `backup` — Cluster operations
+- Custom role names are also supported
+
+### Lease Returns
+- `DB_USERNAME` — Generated username
+- `DB_PASSWORD` — Generated password
+
+### Gotchas
+- **MongoDB vs Atlas:** Use the standard MongoDB provider for self-hosted MongoDB. Use the MongoDB Atlas provider for Atlas clusters — they use different APIs.
+- Port is optional because cluster connection strings include the port
+
+---
+
+## Elasticsearch
+
+### Prerequisites
+- An Elasticsearch user with privileges to create/delete users and roles
+
+### Configuration
+| Field | Required | Description |
+|-------|----------|-------------|
+| Secret Name | Yes | Name for this dynamic secret |
+| Default TTL | Yes | Default lease duration |
+| Max TTL | Yes | Maximum lease duration |
+| Host | Yes | Elasticsearch host URL |
+| Port | Yes | Elasticsearch port (default: `9200`) |
+| User | Yes | Admin user |
+| Password | Yes | Admin user password |
+| Roles | Yes | Elasticsearch roles to assign |
+| CA (SSL) | No | CA certificate for HTTPS connections |
+
+### Lease Returns
+- `DB_USERNAME` — Generated username
+- `DB_PASSWORD` — Generated password
+
+---
+
+## RabbitMQ
+
+### Prerequisites
+- A RabbitMQ user with administrator tag for management API access
+
+### Configuration
+| Field | Required | Description |
+|-------|----------|-------------|
+| Secret Name | Yes | Name for this dynamic secret |
+| Default TTL | Yes | Default lease duration |
+| Max TTL | Yes | Maximum lease duration |
+| Host | Yes | RabbitMQ management API host |
+| Port | Yes | Management API port (default: `15672`) |
+| User | Yes | Admin user |
+| Password | Yes | Admin user password |
+| Virtual Host | Yes | RabbitMQ virtual host |
+| Tags | No | User tags (e.g., `monitoring`, `management`) |
+| Permissions | No | Configure, write, read regex patterns |
+
+### Lease Returns
+- `DB_USERNAME` — Generated username
+- `DB_PASSWORD` — Generated password
@@ -0,0 +1,83 @@
+# Dynamic Secrets Overview
+
+## What are Dynamic Secrets?
+
+Dynamic secrets are credentials generated on-demand upon access rather than stored statically. Each credential is:
+
+- **Unique** to the identity requesting it
+- **Short-lived** with a configurable TTL
+- **Automatically revocable** when the lease expires
+- **Auditable** with full traceability of who accessed what and when
+
+## Core Concepts
+
+### Lease Lifecycle
+
+1. **Generate** — User or application requests a new lease with a specific TTL
+2. **Use** — Credentials are active until the lease expires
+3. **Renew** — Extend the lease TTL (cannot exceed the Max TTL defined on the dynamic secret)
+4. **Revoke** — Manually delete the lease before TTL expiration, or let it auto-expire
+
+### TTL Settings
+
+Every dynamic secret has two TTL settings:
+
+- **Default TTL** — The default duration when generating a new lease (e.g., `1h`, `30m`)
+- **Max TTL** — The absolute ceiling — leases cannot be renewed past this point (e.g., `24h`, `7d`)
+
+### Supported Providers (27)
+
+**SQL Databases:** PostgreSQL, MySQL, MSSQL, Oracle, SAP ASE, SAP HANA, Snowflake, Vertica, ClickHouse, Azure SQL Database
+
+**NoSQL & Cache:** Redis, MongoDB, MongoDB Atlas, Elasticsearch, Couchbase, Cassandra, RabbitMQ
+
+**Cloud IAM:** AWS IAM (users + temporary credentials), GCP IAM (service account tokens), Azure Entra ID
+
+**Infrastructure:** SSH Certificates, Kubernetes Service Account Tokens, LDAP, GitHub (tokens), TOTP
+
+## Common Setup Pattern
+
+1. **Open Secret Overview Dashboard** → Select environment
+2. **Click "Add Dynamic Secret"**
+3. **Select provider** (e.g., SQL Database, Redis, AWS IAM, SSH)
+4. **Configure:**
+   - Secret Name
+   - Default TTL and Max TTL
+   - Provider-specific connection details (host, port, credentials)
+   - Optional: Custom creation/revocation statements
+   - Optional: Gateway for private network access
+5. **Submit** — Dynamic secret appears in dashboard
+6. **Generate Lease** — Click the dynamic secret → "New Lease" → specify TTL
+
+## Gateway for Private Networks
+
+If your database or resource is in a VPC, private subnet, or behind a firewall with no public endpoint, you need an **Infisical Gateway**.
+
+- Gateway is a lightweight service deployed in your private network
+- It makes only outbound connections (no inbound firewall rules needed)
+- Routes traffic through a relay server using SSH reverse tunnels
+- **Enterprise feature** (Cloud Enterprise tier or self-hosted Enterprise license)
+- One gateway per network/region/isolated environment
+
+Configure the gateway when creating the dynamic secret — select it from the Gateway dropdown.
+
+## Using Dynamic Secrets Programmatically
+
+### Via Infisical Agent Templates
+
+```go
+{{ with dynamicSecret "my-project" "dev" "/" "postgres-creds" "1h" }}
+DB_USER={{ .DB_USERNAME }}
+DB_PASS={{ .DB_PASSWORD }}
+{{ end }}
+```
+
+The agent automatically renews leases before expiration.
+
+### Via API
+
+Use the Infisical API to create, renew, and revoke leases programmatically. Authenticate with a machine identity access token.
+
+### Via SDKs
+
+Infisical SDKs support dynamic secret lease creation. Check the SDK docs for your language.
@@ -0,0 +1,132 @@
+# Dynamic Secrets: SQL Databases
+
+## PostgreSQL
+
+### Prerequisites
+- A PostgreSQL user with permissions to CREATE ROLE, GRANT, and REVOKE
+- This user will be used by Infisical to create/drop temporary database users
+
+### Configuration
+| Field | Required | Description |
+|-------|----------|-------------|
+| Secret Name | Yes | Name for this dynamic secret |
+| Default TTL | Yes | Default lease duration (e.g., `1h`) |
+| Max TTL | Yes | Maximum lease duration (e.g., `24h`) |
+| Host | Yes | Database hostname or IP |
+| Port | Yes | Database port (default: `5432`) |
+| User | Yes | Admin user for creating credentials |
+| Password | Yes | Admin user password |
+| Database Name | Yes | Target database |
+| CA (SSL) | No | CA certificate for SSL connections (common for AWS RDS) |
+
+### SQL Statements (Customizable)
+Default creation statement grants broad access. **Customize for least privilege:**
+
+```sql
+-- Example: Read-only access to specific tables
+CREATE ROLE "{{username}}" WITH LOGIN PASSWORD '{{password}}' VALID UNTIL '{{expiration}}';
+GRANT SELECT ON TABLE public.users, public.orders TO "{{username}}";
+```
+
+**Template variables:** `{{username}}`, `{{password}}`, `{{expiration}}`
+
+**Note:** PostgreSQL uses double quotes for identifiers.
+
+### Lease Returns
+- `DB_USERNAME` — Generated username
+- `DB_PASSWORD` — Generated password
+
+---
+
+## MySQL
+
+### Prerequisites
+- A MySQL user with CREATE USER, GRANT, and REVOKE privileges
+- This user will be used by Infisical to create/drop temporary database users
+
+### Configuration
+| Field | Required | Description |
+|-------|----------|-------------|
+| Secret Name | Yes | Name for this dynamic secret |
+| Default TTL | Yes | Default lease duration |
+| Max TTL | Yes | Maximum lease duration |
+| Host | Yes | Database hostname or IP |
+| Port | Yes | Database port (default: `3306`) |
+| User | Yes | Admin user for creating credentials |
+| Password | Yes | Admin user password |
+| Database Name | Yes | Target database |
+| CA (SSL) | No | CA certificate for SSL connections |
+
+### SQL Statements (Customizable)
+```sql
+-- Example: Read-only access to specific database
+CREATE USER '{{username}}'@'%' IDENTIFIED BY '{{password}}';
+GRANT SELECT ON mydb.* TO '{{username}}'@'%';
+```
+
+**Template variables:** `{{username}}`, `{{password}}`, `{{expiration}}`
+
+### Lease Returns
+- `DB_USERNAME` — Generated username
+- `DB_PASSWORD` — Generated password
+
+---
+
+## Cassandra
+
+### Prerequisites
+- A Cassandra user with privileges to create, drop, and grant roles
+- `cassandra.yaml` must have:
+  ```yaml
+  authenticator: PasswordAuthenticator
+  authorizer: CassandraAuthorizer
+  ```
+
+### Configuration
+| Field | Required | Description |
+|-------|----------|-------------|
+| Secret Name | Yes | Name for this dynamic secret |
+| Default TTL | Yes | Default lease duration |
+| Max TTL | Yes | Maximum lease duration |
+| Host | Yes | Cassandra host(s) — comma-separated for multiple nodes |
+| Port | Yes | Cassandra port (default: `9042`) |
+| User | Yes | Admin user for creating credentials |
+| Password | Yes | Admin user password |
+| Local Data Center | Yes | Must match cluster data center name |
+| Keyspace | No | Restrict user to specific keyspace |
+| CA (SSL) | No | CA certificate for SSL connections |
+
+### CQL Statements (Customizable)
+```cql
+-- Example: Read-only access to specific keyspace
+CREATE ROLE '{{username}}' WITH PASSWORD = '{{password}}' AND LOGIN = true;
+GRANT SELECT ON KEYSPACE mykeyspace TO '{{username}}';
+```
+
+### Lease Returns
+- `DB_USERNAME` — Generated username
+- `DB_PASSWORD` — Generated password
+
+### Gotchas
+- `PasswordAuthenticator` and `CassandraAuthorizer` MUST be set in cassandra.yaml
+- `Local Data Center` must exactly match your cluster's DC name
+
+---
+
+## Other SQL Databases
+
+MSSQL, Oracle, SAP ASE, SAP HANA, Snowflake, Vertica, ClickHouse, and Azure SQL Database all follow the same pattern:
+
+1. Provide connection details (host, port, admin user/password, database)
+2. Optionally customize SQL creation/revocation statements
+3. Generate leases that return `DB_USERNAME` and `DB_PASSWORD`
+
+Key differences:
+- **MSSQL:** Uses `CREATE LOGIN` / `CREATE USER` syntax
+- **Oracle:** Uses `CREATE USER` / `GRANT CONNECT` syntax
+- **Snowflake:** Requires warehouse, account identifier, and organization name
+- **Azure SQL Database:** Similar to MSSQL but requires Azure-specific connection strings
+
+### Username Template
+
+All SQL providers support an optional **Username Template** field that lets you customize the format of generated usernames (e.g., adding a prefix like `inf_{{random}}`).
@@ -0,0 +1,162 @@
+# Dynamic Secrets: SSH Certificates & Kubernetes
+
+## SSH Certificates
+
+### Overview
+Infisical generates an internal CA key pair and issues signed SSH certificates on demand. Target hosts trust the CA, and certificates expire automatically — no manual key rotation or revocation needed.
+
+### How It Works
+1. When you create the dynamic secret, Infisical generates a CA key pair
+2. You configure target SSH servers to trust this CA
+3. For each lease, Infisical generates an ephemeral key pair, signs it with the CA, and returns the private key + signed certificate
+4. The certificate automatically expires when the lease TTL is up
+
+### Configuration
+| Field | Required | Description |
+|-------|----------|-------------|
+| Secret Name | Yes | Name for this dynamic secret |
+| Default TTL | Yes | Default certificate validity (e.g., `1h`, `8h`) |
+| Max TTL | Yes | Maximum certificate validity |
+| Allowed Principals | Yes | Usernames the cert can authenticate as (e.g., `ubuntu`, `deploy`, `root`) |
+| Key Algorithm | Yes | `ED25519` (default, recommended), `RSA 2048`, `RSA 4096`, `ECDSA P-256`, or `ECDSA P-384` |
+
+### Target Host Setup
+
+After creating the dynamic secret, you get a setup modal with two options:
+
+**Automated (recommended):**
+```bash
+curl -H "Authorization: Bearer <token>" \
+  "https://<infisical-url>/api/v1/dynamic-secrets/ssh-ca-setup/<id>" | sudo bash
+```
+This writes the CA to `/etc/ssh/infisical_ca.pub`, adds `TrustedUserCAKeys` to sshd_config, and restarts SSH.
+
+**Manual:**
+1. Save the CA public key to `/etc/ssh/infisical_ca.pub`
+2. Add to `/etc/ssh/sshd_config`:
+   ```
+   TrustedUserCAKeys /etc/ssh/infisical_ca.pub
+   ```
+3. Restart SSH: `sudo systemctl restart sshd`
+
+### Lease Generation
+- Specify TTL (within Max TTL)
+- Specify principals (subset of Allowed Principals)
+
+### Lease Returns
+- **Private Key** (downloadable as `key.pem`)
+- **Signed Certificate** (downloadable as `cert.pub`)
+
+### Usage
+```bash
+chmod 600 key.pem
+ssh -i key.pem -o CertificateFile=cert.pub <principal>@<hostname>
+```
+
+### Gotchas
+- **Certificates CANNOT be renewed.** The TTL is baked in at signing time. Create a new lease for a fresh certificate.
+- Certificates remain valid until TTL even if the lease is revoked in Infisical
+- Use short TTLs for security-sensitive environments
+
+---
+
+## Kubernetes Service Account Tokens
+
+### Overview
+Generate short-lived Kubernetes service account tokens on demand. Supports two credential types and two authentication methods.
+
+### Credential Types
+
+**Static** — Use an existing service account with predefined permissions. Infisical generates a token for it.
+
+**Dynamic** — Infisical creates a temporary service account, binds it to a specified role, generates a token, and cleans up when the lease expires.
+
+### Authentication Methods
+
+**Token (API)** — Provide a cluster URL and a service account token with RBAC permissions to create tokens.
+
+**Gateway** — Use an Infisical Gateway deployed in the cluster (for private clusters).
+
+### Static Credentials + Token Auth
+
+**RBAC Setup (apply to cluster):**
+```yaml
+apiVersion: v1
+kind: ServiceAccount
+metadata:
+  name: infisical-token-requester
+  namespace: default
+---
+apiVersion: rbac.authorization.k8s.io/v1
+kind: ClusterRole
+metadata:
+  name: tokenrequest
+rules:
+  - apiGroups: [""]
+    resources: ["serviceaccounts/token", "serviceaccounts"]
+    verbs: ["create", "get"]
+---
+apiVersion: rbac.authorization.k8s.io/v1
+kind: ClusterRoleBinding
+metadata:
+  name: tokenrequest
+roleRef:
+  apiGroup: rbac.authorization.k8s.io
+  kind: ClusterRole
+  name: tokenrequest
+subjects:
+  - kind: ServiceAccount
+    name: infisical-token-requester
+    namespace: default
+```
+
+**Get the token:**
+```bash
+kubectl get secret infisical-token-requester-token -n default \
+  -o=jsonpath='{.data.token}' | base64 --decode
+```
+
+**Config:**
+| Field | Required | Description |
+|-------|----------|-------------|
+| Cluster URL | Yes | e.g., `https://kubernetes.default.svc` |
+| Cluster Token | Yes | Token from RBAC setup above |
+| Service Account Name | Yes | Existing SA to generate tokens for |
+| Namespace | Yes | SA's namespace |
+| Audiences | No | Token audiences |
+
+### Dynamic Credentials + Token Auth
+
+Requires expanded RBAC (create/delete service accounts + role bindings):
+
+```yaml
+rules:
+  - apiGroups: [""]
+    resources: ["serviceaccounts/token", "serviceaccounts"]
+    verbs: ["create", "get", "delete"]
+  - apiGroups: ["rbac.authorization.k8s.io"]
+    resources: ["rolebindings", "clusterrolebindings"]
+    verbs: ["create", "delete"]
+```
+
+**Important:** The token requester SA can only create bindings for roles it has access to itself.
+
+**Config:**
+| Field | Required | Description |
+|-------|----------|-------------|
+| Cluster URL | Yes | Kubernetes API server URL |
+| Cluster Token | Yes | Token with expanded RBAC |
+| Allowed Namespaces | Yes | Comma-separated (e.g., `default,kube-system`) |
+| Role Type | Yes | `ClusterRole` or `Role` |
+| Role | Yes | Name of the role to bind |
+| Audiences | No | Token audiences |
+
+### Lease Returns
+- Kubernetes service account token (JWT)
+
+### Gotchas
+- **Tokens CANNOT be revoked.** Like GCP, K8s tokens are JWTs with baked-in expiration. Revoking the lease removes the Infisical record but the token stays valid until expiry.
+- **Tokens CANNOT be renewed.** The lifetime is fixed at creation. Create a new lease for a new token.
+- Use short TTLs (15m–1h) for security
+- Dynamic credentials create temporary service accounts that are automatically cleaned up on lease expiry
+- Gateway auth eliminates the need to expose the cluster API server publicly