Skip to main content
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.
Use the Secrets Service whenever your agents or automation need to read sensitive credentials at runtime without hard-coding them into configuration files. It lets you centralize where secrets live, enforce access controls from the Control Plane, and build safety checks or audits around which secrets exist and how they are used.

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
From the SDK you typically combine these operations to implement workflows like pre-flight checks (“are all required secrets present?”), inventory reports for security teams, and tightly scoped retrieval of individual values just before they are used.
The Secrets Service provides read-only access via the SDK. Secret creation, updates, and deletion must be performed through the Kubiya Dashboard or CLI to ensure proper security controls.

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

Always handle secret values with care:
  • Never log secret values
  • Never store secrets in version control
  • Use secrets only when necessary
  • Clear sensitive data from memory after use

Basic Usage

List All Secrets

The list() method returns secret metadata only. Actual secret values are not included in list responses for security reasons.

Get Secret Value

Security Warning: Always clear secret values from memory after use and never log, print, or store them insecurely.

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 handle ControlPlaneError 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.
Security Note: Only cache secrets when absolutely necessary and always use short TTLs. Cached secrets in memory are a security risk if the process is compromised.

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