-
Notifications
You must be signed in to change notification settings - Fork 24
feat(core): introduce typed Secret with inline env/file/literal, BindServiceConfig; integrate in KAS #2799
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
/gemini review |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Code Review
This pull request introduces a Secret
type with support for inline environment variables, file paths, and literal values, enhancing configuration security. It also adds a BindServiceConfig
helper for simplified configuration binding and validation. The changes integrate these features into the KAS, improving environment handling and adding unit tests and documentation. The review focuses on correctness and potential issues in the new code.
/gemini review |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Code Review
This pull request introduces a robust Secret
type for managing sensitive configuration values, along with a BindServiceConfig
helper to streamline decoding and validation. The integration into KAS to handle the root_key
is a great use case. The changes are well-structured and include thorough testing, which is excellent.
My review includes a few suggestions to enhance the implementation:
- Improving the heuristic for redacting secrets in debug logs to prevent potential leaks.
- Clarifying the documentation for structured secret configuration.
- Minor improvements to error messages and code consistency for better maintainability.
…eral, BindServiceConfig; integrate in KAS - Add Secret type with redaction and safe JSON/log masking - Support inline secret directives: env:NAME, file:/path, literal:VALUE - Add BindServiceConfig helper with mapstructure decode hooks + validation - Implement file-based and env-based secret resolution (lazy/eager) - Integrate KAS: use Secret for root_key and BindServiceConfig - Improve env handling during reload to surface env-only keys - Add unit tests for Secret, BindServiceConfig, and inline decode forms - Update docs: “Secrets In Config” with examples and guidance - Remove temporary debug logs and experimental nested secret usage in KAS DX - Plain strings are literals by default; use literal: to disambiguate values starting with env:/file: - Example: - services.kas.root_key: "env:OPENTDF_SERVICES_KAS_ROOT_KEY" - services.kas.preview.key_management: true
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you avoid breaking compatibility with downstream users? Maybe print out a warning if the old root_key
field is set, and use a new name (suggestion: envelope_key
) from now on.
RSACertID string `mapstructure:"rsacertid" json:"rsacertid"` | ||
|
||
RootKey string `mapstructure:"root_key" json:"root_key"` | ||
RootKey config.Secret `mapstructure:"root_key" json:"root_key"` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Even changes to 'experimental' features shouldn't break builds downstream. Deprecate instead of removing to avoid blocking the next release of downstream integrations.
RootKey config.Secret `mapstructure:"root_key" json:"root_key"` | |
// Deprecated: Use EnvelopeKey | |
RootKey string `mapstructure:"root_key" json:"root_key"` | |
EnvelopeKey config.Secret `mapstructure:"envelope_key" json:"envelope_key"` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There shouldn't be downstream impact. This should still support a string literal in yaml without any prefix.
5041371
to
867b0d6
Compare
|
||
// If an environment loader is present, configure orderedViper to read env directly. | ||
for _, loader := range c.loaders { | ||
if loader.Name() == LoaderNameEnvironmentValue { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The env loader should already do this. And it should be configured by the consumer of the library.
// Discover environment variables with the configured prefix and convert them to dotted keys | ||
// Example: OPENTDF_SERVICES_KAS_ROOT_KEY -> services.kas.root_key | ||
// Note: Viper treats keys case-insensitively; we normalize to lower-case dotted form here | ||
prefix := l.envPrefix + "_" | ||
for _, env := range os.Environ() { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This bit looks like what Viper should be doing already. If it is adding additional keys we should cache those keys and values so they can be returned by Get
, otherwise we might hit this: https://github.com/opentdf/platform/blob/main/service/pkg/config/config.go#L219-L229
Proposed Changes
DX
Checklist
Testing Instructions