The Secrets Service provides secure access to secrets stored in the Kubiya Control Plane, enabling agents and integrations to retrieve credentials, API keys, and other sensitive data at runtime.
Overview
Secrets in Kubiya are securely stored credentials, tokens, API keys, and other sensitive data used by agents and integrations. The Secrets Service allows you to:- List Secrets: View secret metadata (names, types, scopes) without exposing values
- Retrieve Values: Securely access secret values when needed by agents or workflows
Quick Start
Core Concepts
Secret Types
Kubiya supports various secret types:- API Keys: Third-party service API keys (GitHub, AWS, etc.)
- Tokens: OAuth tokens, personal access tokens
- Credentials: Username/password pairs
- Certificates: TLS certificates and private keys
- Environment Variables: Sensitive configuration values
Secret Scopes
Secrets can have different scopes:- Organization: Available to all agents and users in the organization
- Team: Available to specific teams
- User: Personal secrets for individual users
Security Best Practices
Basic Usage
List All Secrets
Example Response
Example Response
The
list() method returns secret metadata only. Actual secret values are not included in list responses for security reasons.Get Secret Value
Example Response
Example Response
Practical Examples
The following examples show how to use the Secrets Service for real-world scenarios, such as auditing secret inventory, securely retrieving secret values, and handling sensitive data. Each example includes a short explanation of when and why you might use it.1. Secret Inventory
Use this pattern to generate an inventory for security reviews or cleanup projects, so you know which secrets exist, where they are scoped, and which integrations they are tied to. List all secrets with categorization:2. Secret Usage Validator
Use this validator as a pre-flight check for environments, CI pipelines, or new projects to ensure all required secrets have been created before anything runs. Check if required secrets exist:3. Secure Secret Accessor
Use this context manager in any code path that must touch raw secret values, so you minimize how long secrets stay in memory and centralize cleanup behavior. Safely retrieve and use secrets with automatic cleanup:4. Secret Rotation Checker
Use this helper to identify long-lived secrets that may be overdue for rotation, and to generate reports you can share with security or platform teams. Identify secrets that may need rotation:5. Integration Secrets Checker
Use this checker to verify that each integration (GitHub, AWS, Slack, etc.) has all of the secrets it needs before enabling agents or workflows that depend on it. Verify secrets for specific integrations:Error Handling
Secret operations can fail because a secret does not exist, the caller lacks permission, or network and authentication problems prevent the Control Plane from returning data. The following patterns show how to handleControlPlaneError alongside common SDK errors, and how to distinguish between not-found and permission-denied cases.
Best Practices
These patterns help you use secrets safely from code: avoid leaking values, keep access tightly scoped, validate requirements up front, and only cache when you have a clear operational need.1. Never Log Secret Values
Never print or log raw secret values. If you need to log something, prefer high-level metadata like secret names or counts instead of the underlying data.2. Use Context Managers for Secret Access
Wrap secret access in context managers so you have a single, well-reviewed place where values are loaded and then cleared from memory once the work is done.3. Validate Secret Availability Before Use
Validate that required secrets exist before starting jobs or deployments so failures happen early and clearly instead of deep inside business logic.4. Implement Secret Caching Carefully
If you must cache secrets for performance reasons, keep the cache in memory only, use short TTLs, and provide an explicit way to clear cached values.API Reference
Methods
Secret creation, updates, and deletion must be performed through the Kubiya Dashboard or CLI for security reasons.
Secret Metadata Structure
Secret Value Structure
Security Considerations
Secret Access Logging
All secret access is logged by the Control Plane for security auditing:- Who accessed which secret
- When the secret was accessed
- From which service or agent
Permissions
Secret access is governed by:- Organization roles: Admins have full access
- Team membership: Team secrets require team membership
- User ownership: User-scoped secrets are personal
Rotation Recommendations
- API Keys: Rotate every 90 days
- Tokens: Rotate every 60 days
- Credentials: Rotate every 90 days
- Certificates: Follow certificate expiry dates
Next Steps
Integrations Service
Manage integration configurations
Workers Service
Monitor and manage workers
Error Handling
Handle SDK exceptions
Best Practices
SDK security best practices