feat(issue-559): allow sensitive values to be passable as plaintext#610
feat(issue-559): allow sensitive values to be passable as plaintext#610Breee wants to merge 1 commit into
Conversation
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (4)
🚧 Files skipped from review as they are similar to previous changes (4)
📝 WalkthroughWalkthroughThis change adds plaintext support for sensitive fields. It introduces alternate-field metadata, updates validation and required-field tracking for plaintext or secret-reference input, and skips secret-reference handling when plaintext already exists in Terraform state. ChangesPlaintext-sensitive field flow
Sequence Diagram(s)sequenceDiagram
participant SensitiveConfig
participant FieldBuilder
participant ValidationBuilder
participant ResourceProcessor
participant TerraformState
SensitiveConfig->>FieldBuilder: AllowPlaintextValue = true
FieldBuilder->>FieldBuilder: create alternate regular field
FieldBuilder->>ValidationBuilder: AlternateFieldName
ValidationBuilder->>ValidationBuilder: build primary OR alternate XValidation
ResourceProcessor->>TerraformState: GetValue(tfPath)
alt plaintext value exists
ResourceProcessor->>ResourceProcessor: skip secret-reference handling
else no plaintext value
ResourceProcessor->>ResourceProcessor: process sensitive parameters
end
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~22 minutes Suggested reviewers
🚥 Pre-merge checks | ✅ 7✅ Passed checks (7 passed)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
|
|
|
this would be extremely helpful to have |
|
I'll rebase onto Main and search in the upjet chat for someone that gives Feedback |
…s well. Signed-off-by: Julian Löffler <julian@corewire.de>
allow sensitive values to be passable as plaintext
Draft for #559 to have a base for discussion. This shall give you an idea of the requirement i have.
This was the easiest implementation approach I found that is fully backwards compatible.
However, it does add some complexity to the builder logic and generated code, so I'm open to suggestions on how to make it cleaner or if we want to take a different approach.
In general i need some more flexibility with what i can pass in as secret and what i can pass in as plaintext for the provider-keycloak, as OIDC / SAML clients and tools vary alot in what they support and need.
Problem
Sensitive fields currently only support secret references. Users must create a Kubernetes Secret even if they just want to pass a value directly. This is inflexible and doesn't match how the underlying Terraform providers work (which accept plaintext).
Potential Solution
I Added a
AllowPlaintextValueconfig flag. When enabled, generates both the regular field AND the secret reference field for sensitive parameters. Users pick which one to use via OR validation (provide one or the other, not both).Runtime checks the plaintext field first, falls back to secret reference if not set. Its Backwards compatible so existing secret-only resources work unchanged.
Usage
Provider configuration:
See https://github.com/crossplane-contrib/provider-keycloak/blob/feat/upjet-test/config/oidc/config.go#L30
Generated CRD types will then look like this:
see https://github.com/crossplane-contrib/provider-keycloak/blob/feat/upjet-test/apis/cluster/oidc/v1alpha1/zz_identityprovider_types.go#L43
Example
After enabling
AllowPlaintextValue, users can choose:Testing
I Tested in provider-keycloak with both plaintext and secret reference patterns.
Both resources successfully created and synced in a dev cluster.