Skip to content

feat(issue-559): allow sensitive values to be passable as plaintext#610

Open
Breee wants to merge 1 commit into
crossplane:mainfrom
Breee:feat/issue-559
Open

feat(issue-559): allow sensitive values to be passable as plaintext#610
Breee wants to merge 1 commit into
crossplane:mainfrom
Breee:feat/issue-559

Conversation

@Breee

@Breee Breee commented Mar 12, 2026

Copy link
Copy Markdown

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 AllowPlaintextValue config 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:

p.AddResourceConfigurator("keycloak_oidc_identity_provider", func(r *config.Resource) {
    r.ShortGroup = "oidc"
    
    // Mark fields as sensitive in Terraform schema
    if s, ok := r.TerraformResource.Schema["client_id"]; ok {
        s.Sensitive = true
    }
    if s, ok := r.TerraformResource.Schema["client_secret"]; ok {
        s.Sensitive = true
    }
    
    // Enable plaintext AND secret reference support
    r.Sensitive.AllowPlaintextValue = true
})

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:

type IdentityProviderParameters struct {
    // [...more stuff...]
    // Plaintext field (new!)
    ClientID *string `json:"clientId,omitempty"`
    
    // Secret reference field (existing)
    ClientIDSecretRef v1.SecretKeySelector `json:"clientIdSecretRef,omitempty"`
    
    ClientSecret *string `json:"clientSecret,omitempty"`
    ClientSecretSecretRef *v1.SecretKeySelector `json:"clientSecretSecretRef,omitempty"`
   // [...more stuff...]
}

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:

# Option 1: Plaintext (new)
spec:
  forProvider:
    clientId: "my-client-id"
    clientSecret: "my-secret"

# Option 2: Secret references 
spec:
  forProvider:
    clientIdSecretRef:
      name: my-secret
      key: client_id
    clientSecretSecretRef:
      name: my-secret
      key: client_secret
      [... other fields ...]

Testing

I Tested in provider-keycloak with both plaintext and secret reference patterns.
Both resources successfully created and synced in a dev cluster.

@Breee Breee marked this pull request as ready for review March 12, 2026 16:25
@coderabbitai

coderabbitai Bot commented Mar 12, 2026

Copy link
Copy Markdown

Review Change Stack

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info
⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

Run ID: 5bd11f35-a1a8-4480-9ff5-501d6b66b033

📥 Commits

Reviewing files that changed from the base of the PR and between a98b1a0 and 318eb5f.

📒 Files selected for processing (4)
  • pkg/config/resource.go
  • pkg/resource/sensitive.go
  • pkg/types/builder.go
  • pkg/types/field.go
🚧 Files skipped from review as they are similar to previous changes (4)
  • pkg/config/resource.go
  • pkg/types/builder.go
  • pkg/types/field.go
  • pkg/resource/sensitive.go

📝 Walkthrough

Walkthrough

This 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.

Changes

Plaintext-sensitive field flow

Layer / File(s) Summary
Config and field shapes
pkg/config/resource.go, pkg/types/field.go
Sensitive gains AllowPlaintextValue, Field gains AlternateFieldName, and sensitive field generation marks the secret-reference schema optional when plaintext is allowed.
Validation and required-parameter tracking
pkg/types/builder.go
The builder adds alternate regular fields, records alternate paths in required-parameter tracking, and emits OR-based XValidation rules for primary or alternate field presence.
Sensitive parameter runtime skip
pkg/resource/sensitive.go
GetSensitiveParameters checks Terraform state for an existing plaintext value and skips secret-reference handling for that field path when one is found.

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
Loading

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~22 minutes

Suggested reviewers

  • sergenyalcin
  • erhancagirici
🚥 Pre-merge checks | ✅ 7
✅ Passed checks (7 passed)
Check name Status Explanation
Title check ✅ Passed The title is concise, under 72 characters, and clearly describes the plaintext support change.
Description check ✅ Passed The description is directly about the same sensitive-value plaintext feature and its implementation.
Linked Issues check ✅ Passed Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check ✅ Passed Check skipped because no linked issues were found for this pull request.
Configuration Api Breaking Changes ✅ Passed Only additive config API change: Sensitive.AllowPlaintextValue was added; no exported types/functions/fields were removed, renamed, or re-signed in pkg/config.
Generated Code Manual Edits ✅ Passed The PR diff only touches generator inputs in pkg/config/resource.go, pkg/resource/sensitive.go, pkg/types/builder.go, and pkg/types/field.go; no zz_*.go files were modified.
Template Breaking Changes ✅ Passed No pkg/controller/external*.go template files were changed; the diff is limited to config/types/resource logic, so this template-breaking check is not triggered.

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.

❤️ Share

Comment @coderabbitai help to get the list of available commands.

@Breee Breee changed the title feat(issue-559): allow sensitive values to be passable as plaintext as well feat(issue-559): allow sensitive values to be passable as plaintext Mar 13, 2026
@Upbound-CLA

Upbound-CLA commented Apr 30, 2026

Copy link
Copy Markdown

CLA assistant check
All committers have signed the CLA.

@Upbound-CLA

Copy link
Copy Markdown

CLA assistant check
Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.
You have signed the CLA already but the status is still pending? Let us recheck it.

@vrabbi

vrabbi commented Jun 30, 2026

Copy link
Copy Markdown

this would be extremely helpful to have

@Breee

Breee commented Jun 30, 2026

Copy link
Copy Markdown
Author

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>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants