Issue Station
Sign In
Tools hereToolbox

openclaw - ✅(Solved) Fix [Feature]: support to use plugin to implement secret ref provider and cover core schemas [1 pull requests, 1 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
openclaw/openclaw#71593•Fetched 2026-04-26 05:10:57
View on GitHub
Comments
0
Participants
1
Timeline
2
Reactions
0
Author
ColstuwjxColstuwjx
Participants
ColstuwjxColstuwjx
Timeline (top)
cross-referenced ×1labeled ×1

Currently, if we want to cover some Zod fields to mask them as secret ref object, it would need to change their schema definition accordingly, e.g. the following fields might need to be masked as secret ref object:

  - channels.wea.* credentials                                                                                                                     
  - skills.entries.*.env values                                                                                                                    
  - plugins.entries.*.config sensitive paths

As a result, it may need to change the core schema fields frequently, which is not a good way. Instead, we could introduce an unified solution like K8s CNI did, just let the end users define their own secret ref provider and it could cover all of the schema fields, which is more complete solution.

Root Cause

Currently, if we want to cover some Zod fields to mask them as secret ref object, it would need to change their schema definition accordingly, e.g. the following fields might need to be masked as secret ref object:

  - channels.wea.* credentials                                                                                                                     
  - skills.entries.*.env values                                                                                                                    
  - plugins.entries.*.config sensitive paths

As a result, it may need to change the core schema fields frequently, which is not a good way. Instead, we could introduce an unified solution like K8s CNI did, just let the end users define their own secret ref provider and it could cover all of the schema fields, which is more complete solution.

Fix Action

Fixed

PR fix notes

PR #43643: feat(secrets): add AWS Secrets Manager provider

Description (problem / solution / changelog)

Summary

Adds AwsSecretProvider for resolving secrets from AWS Secrets Manager.

The AWS SDK (@aws-sdk/client-secrets-manager) is lazy-loaded as an optional peer dependency — no startup cost unless the provider is configured.

Authentication

Standard AWS credential chain: env vars → shared credentials file → IAM role → EC2 instance profile.

Features

  • Version pinning: ${aws:my-secret#AWSCURRENT}
  • Profile selection and role ARN assumption
  • External ID for cross-account access
  • Configurable TTL caching (default 5 min)

Config

{
  "secrets": {
    "providers": {
      "aws": {
        "region": "us-east-1",
        "profile": "prod",
        "roleArn": "arn:aws:iam::123456789:role/openclaw"
      }
    }
  }
}

Usage: ${aws:my-secret-name}

Notes

Split from #24272 per @vincentkoc's request.

Changed files

  • src/config/aws-secret-provider.test.ts (added, +330/-0)
  • src/config/aws-secret-provider.ts (added, +305/-0)

Code Example

- channels.wea.* credentials                                                                                                                     
  - skills.entries.*.env values                                                                                                                    
  - plugins.entries.*.config sensitive paths
RAW_BUFFERClick to expand / collapse

Summary

Currently, if we want to cover some Zod fields to mask them as secret ref object, it would need to change their schema definition accordingly, e.g. the following fields might need to be masked as secret ref object:

  - channels.wea.* credentials                                                                                                                     
  - skills.entries.*.env values                                                                                                                    
  - plugins.entries.*.config sensitive paths

As a result, it may need to change the core schema fields frequently, which is not a good way. Instead, we could introduce an unified solution like K8s CNI did, just let the end users define their own secret ref provider and it could cover all of the schema fields, which is more complete solution.

Problem to solve

The end users don't need to submit PR to change the core code any more, just define their own plugin to mask the openclaw json config fields to secret ref objects.

Proposed solution

Use OpenClaw Plugin implementation.

Alternatives considered

No response

Impact

It would still change the core code to support to use plugin to render the configurations by using secret ref objects.

Evidence/examples

No response

Additional information

No response

extent analysis

TL;DR

Introduce an OpenClaw Plugin implementation to allow end users to define their own secret ref provider without modifying the core schema.

Guidance

  • Identify the specific fields that need to be masked as secret ref objects, such as channels.wea.* credentials, skills.entries.*.env values, and plugins.entries.*.config sensitive paths.
  • Develop a plugin using the OpenClaw Plugin implementation that can dynamically mask these fields without requiring changes to the core schema.
  • Consider the impact of changing the core code to support plugin-based rendering of configurations using secret ref objects.
  • Evaluate the trade-offs between introducing a new plugin-based solution and modifying the existing core schema.

Example

No code example is provided due to the lack of specific implementation details in the issue.

Notes

The proposed solution relies on the OpenClaw Plugin implementation, which may have its own set of requirements and limitations. Additionally, the impact of changing the core code to support plugin-based rendering of configurations using secret ref objects should be carefully evaluated.

Recommendation

Apply the workaround by introducing an OpenClaw Plugin implementation, as it allows for a more flexible and user-defined solution without requiring frequent changes to the core schema.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…
#api#ssr#installation#tensor shape#request timeout

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING

openclaw - ✅(Solved) Fix [Feature]: support to use plugin to implement secret ref provider and cover core schemas [1 pull requests, 1 participants]