Core Concepts

Understanding the CustomKeys hierarchy is essential for architecting a secure secrets strategy.

1. Organizations

The Organization is your top-level namespace. It owns all resources including projects, members, billing, and global audit logs.

• Most users belong to one organization.
• Billing plans and limits are applied at the organization level.

2. Projects

Projects are logical groupings of related secrets. Typically, you create a project for each microservice or monolithic application.

• Example: payment-gateway, user-api, frontend-dashboard.
• Projects act as the security boundary for member permissions.

3. Environments

Environments are isolated tiers within a project.

• Standard Tiers: development, staging, production.
• Custom Tiers: You can define custom environments like ci or qa.
• Protected Environments: Environments (like production) can be marked as protected, requiring Admin/Owner roles for access or enabling Approval Workflows.

4. Secrets

A Secret is a versioned key-value pair.

• Keys: Uppercased by convention (e.g., DATABASE_URL).
• Values: Encrypted with AES-256-GCM.
• References: Secrets can interpolate other secrets via ${secret:KEY} syntax.

5. API Tokens

API Tokens are the primary way to authenticate programmatic clients (SDKs, CLI, CI/CD).

• They are long-lived and scoped to specific permissions (e.g., secrets:read).
• Tokens are associated with an environment or project.

---

Role-Based Access Control (RBAC)