---
title: "Secret Management"
slug: "secret-management-configuration-1"
status: "update"
updated: 2026-06-29T12:23:59Z
published: 2026-06-29T12:24:34Z
canonical: "docs.plainid.io/secret-management-configuration-1"
---
> ## Documentation Index
> Fetch the complete documentation index at: https://docs.plainid.io/llms.txt
> Use this file to discover all available pages before exploring further.
# Secret Management
The Secret Management Service acts as a centralized component responsible for securely retrieving and serving Secrets to other PlainID components. By default, this service is not included in the Policy Authorization Agent (PAA) deployment and must be explicitly enabled and configured.
This guide walks you through enabling the Secret Management Service within your PAA deployment by modifying the values-custom.yaml file. You will learn how to activate the service, configure core parameters such as ports and logging, and define one or more Secret Stores that the service will use to fetch Secrets like private keys, tokens, and credentials.
Proper configuration of the Secret Management Service ensures secure, seamless access to sensitive data while enabling advanced features like secret rotation and multi-store management. The example and settings below illustrate typical configuration options and serve as a foundation to tailor the service to your environment’s needs.
Currently, the service supports these use cases:
- Passwords/secrets for data source connections in the PIP-Operator
- In addition to the OAuth configuration that supports using Secret Management, REST-based PIP Data Sources use the same Secret Store support as other PIP connections. REST authentication headers and credentials are covered under the [REST Services Source](/v1/docs/rest-services-source#secrets-management-for-rest-headers){target=`_blank`} documentation.
- Passwords for the PDP Authorization Audit Database connection settings
- REDIS authentication passwords for PAA services
- A private key for the PDP to sign Authorization Decisions returned as JWTs
The Secret Management Service can also be configured through the UI. For more information, refer to [About Secret Stores](/v1/docs/about-secret-stores){target=`_blank`}.
| Use Case | HashiCorp Vault | AWS Secrets Manager | AWS RDS IAM | Azure Key Vault Secret Store | CyberArkCCP | Microsoft Entra ID Authentication |
| ------------------------------------------------ | --------------- | ------------------- | ----------- | ---------------------------- | ----------- | --------------------------------- |
| Private Keys for PDP JWT signing | ✓ | ✓ | - | ✓ | ✓ | - |
| AWS ElastiCache for Redis Passwords | - | ✓ | - | - | - | - |
| Using Secrets for PIP Connections | ✓ | ✓ | - | ✓ | ✓ | - |
| AWS RDS Database Connection for PIP Data Source | - | - | ✓ | - | ✓ | - |
| Authorization Database Audit Connection | ✓ | ✓ | ✓ | ✓ | ✓ | - |
| PIP OAuth Connections | ✓ | ✓ | - | ✓ | - | - |
| Azure Redis Authentication with Entra Tokens | - | - | - | - | - | ✓ |
:::(Info) (Additional Integrations)
For additional Secret store integrations or use cases, contact PlainID to discuss options.
:::
Refer to the following documentation for more information:
- [Deployment and Installation](/v1/docs/deployment-and-installation){target=`_blank`}
- [Stores](/v1/docs/stores){target=`_blank`}
* [Hashicorp](/v1/docs/hashicorp){target=`_blank`}
* [AWS Secret Manager](/v1/docs/aws-secret-manager){target=`_blank`}
* [AWS RDS IAM Authentication](/v1/docs/aws-rds-iam-authentication){target=`_blank`}
* [Azure Key Vault](/v1/docs/azure-key-vault){target=`_blank`}
* [CyberArk CCP](/v1/docs/cyberark-ccp){target=`_blank`}
* [Microsoft Entra ID Authentication](/v1/docs/microsoft-entra-id-authentication){target=`_blank`}
* [Use-cases and Examples](/v1/docs/use-cases-and-examples){target=`_blank`}
* [AWS ElastiCache Redis Authentication](/v1/docs/aws-elasticache-redis-authentication){target=`_blank`}
* [Defining RDS Secrets Using the AWS RDS IAM Authetication Store](/v1/docs/defining-rds-secrets-using-the-aws-rds-iam-authentication-store){target=`_blank`}
* [Using Secrets for PIP Data Source Connections](/v1/docs/using-secrets-for-pip-data-source-connections){target=`_blank`}
* [PDP JWT Signing](/v1/docs/using-secret-manager-for-pdp-jwt-signing){target=`_blank`}
* [Azure Managed Redis Authentication](/v1/docs/azure-managed-redis-authentication){target=`_blank`}
## Configuring the Secret Management Service
By default, the Secret Management Service is not included in the PAA deployment. To enable it, add a `secretsMgmt` section to the values-custom.yaml file and follow the configuration instructions.
### Enabling and Configuring the Service
After adding to the values-custom.yaml file the `secret-mgmt` section, set it as `enabled: true` and define additional configuration parameters, such as ports, logging, and most importantly, `secretStore` definitions.
**To use managed stores defined in the Platform in the PAA Store Manager**, ensure that that the `redisIntegration` is set to `enabled: true`.
**Example**:
```yaml
secretsMgmt:
enabled: true
## Enable Redis integration to use cloud secret stores
redisIntegration:
enabled: false ## set to true if using managed stores
replicaCount: 1
command: []
# Allows you to add any config files to /app/config
plainIDConfig:
config.yaml:
server:
port: 8080
# Which IP is allowed to make requests to secret-mgmt
bindIp: 0.0.0.0
management:
port: 8081
log:
level: "info" #debug,trace
format: "json"
logTo: "console" # rolling, file
rabbitmq:
enabled: false
gin:
mode: release # debug, release
# Secret Store configuration
secretStore:
- id: fileSecret
type: File
isDefault: true
decoder: Base64
details:
path: /app/config/filename.txt
# Examples below for HashiCorp Vault based Secret Store
# - id: vault
# type: Vault
# isDefault: true
# decoder: None # Base64, None
# details:
# PathPrefix: prefix
# defaultPath: vault_
# skipVerify: true
# url: vault
# timeout: 3s
# enginePath: custom
#
# Authentication method should use a Token
# auth:
# method: Token # Token, Kubernetes
# tokenValue: token
# tokenFileName: ${ VAULT_TOKEN } - instead of token value
#
# OR Authentication method should use vault Kubernetes authentication
# auth:
# method: Kubernetes
# path: /var/path-to-file/file.txt
# role: secrets-mgmt
# Examples below for Environment Variables based on the Secret Store
# - id: ENV_VAR_SECRET
# type: Environment
# isDefault: false
# decoder: Base64
# details:
# name: ENV_VAR_SECRET
```
**Optional Settings for the Secret Management Service**
| Section | Parameter | Value | Description |
| ---------- | --------- | --------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| server | port | `8080` | The port number that the server listens to for incoming requests. |
| server | bindIp | `0.0.0.0` | The IP address authorized to make requests to the Secret management service.
Use 0.0.0.0 to allow connections from every IP address on the local machine |
| management | port | `8081` | The port number that the management service listens to for incoming requests. |
| log | level | `info` | The Application logging level. |
| log | format | `json` | The Application logging format. |
| log | logTo | `console` | The logging output destination. |
| gin | mode | `release` | The mode that Gin (the HTTP framework) should run in. |
The Environment Variable Store allows secrets to be retrieved from environment variables—commonly used for simpler, local, or container-based deployments. This store is often used for private keys or credentials that are injected at runtime via deployment configurations or Kubernetes manifests.
### Environment Variable Secret Store-specific Parameters
**To configure a Secret Store that reads private keys from Environment Variables, use the following configuration**:
| Parameter | Value | Description |
| ------------ | ---------------- | ------------------------------------------------------------------------- |
| type | `Environment` | Set the type of the Secret store to Environment Variables |
| details.name | `ENV_VAR_SECRET` | The name of the Environment Variable from which to obtain the private key |
#### Example
The following example is based on the [general store](/v1/docs/stores){target=`_blank`} and store-specific parameters.
```yaml
secretsMgmt:
...
plainIDConfig:
...
# Secret Store configuration
secretStore:
- id: ENV_VAR_SECRET
type: Environment
isDefault: true
decoder: Base64
details:
name: ENV_VAR_SECRET
```
## Error Logging for External Secret Providers
Errors from external secret providers are now logged in a consistent structure. This standardization improves troubleshooting and observability by making it easier to collect, filter, and monitor provider-related issues.
**Format**
```
ERROR "secret provider error from {store type} - {error context}: {provider inner error}"
```
**Log Components**
| Component | Description |
| ------------------------ | ----------------------------------------------------------------------- |
| **store type** | The type of secret store (e.g., Vault, AKV, AWS Secrets Manager, etc.). |
| **error context** | The specific failure scenario (e.g., connection error, timeout). |
| **provider inner error** | The detailed error message returned by the external provider. |
**Example**
```go
log.Errorf("secret provider error from Vault - unable to connect to vault: %s", clientErr)
```
## Secret Management Logger Endpoints
Access or update Secret Management logger configurations through the management API.
### Retrieve Loggers
Fetch the available loggers and their configured levels.
```http
GET https://api.{region}.plainid.io/pip-mgmt/1.0/monitor/loggers/runtime/{PAA_ID}
GET https://api.{region}.plainid.io/pip-mgmt/1.0/monitor/loggers/runtime/{PAA_ID}/{LOGGER_NAME}
```
**Example Response**
```json
{
"data": {
"levels": ["ALL", "TRACE", "DEBUG", "INFO", "WARN", "ERROR", "FATAL", "OFF"],
"loggers": {
"": {
"configuredLevel": "INFO",
"effectiveLevel": "INFO"
},
"root": {
"configuredLevel": "INFO",
"effectiveLevel": "INFO"
}
}
}
}
```
| Field | Type | Description |
| ----------------- | ------ | --------------------------------------- |
| `configuredLevel` | string | Level set via configuration or API |
| `effectiveLevel` | string | Actual level applied (may be inherited) |
---
### Modify Log Levels
Change the logging level of a specific logger at runtime.
```http
POST https://api..plainid.io/pip-mgmt/1.0/monitor/loggers/{SERVICE_NAME}/{PAA_ID}/{LOGGER_NAME}
```
**Example Request**
```json
{
"configuredLevel": "DEBUG"
}
```
**Example Response**
```json
{
"data": {
"configuredLevel": "DEBUG",
"effectiveLevel": "DEBUG"
}
}
```