Skip to content

Feat: leverage the secret to read authorization token #229

Open
anishbista60 wants to merge 1 commit into
kubevela:mainfrom
anishbista60:lfx-issue-1
Open

Feat: leverage the secret to read authorization token #229
anishbista60 wants to merge 1 commit into
kubevela:mainfrom
anishbista60:lfx-issue-1

Conversation

@anishbista60

@anishbista60 anishbista60 commented Jun 21, 2026

Copy link
Copy Markdown

Description of your changes

  • This PR support to pass the authorization header as the part of kubernetes secret. Previously, we have to hardcode the token in the Application CR and now we can pass the reference of the secret and it take that token from k8s secret.

Fixes kubevela/kubevela#7104

I have:

  • Read and followed KubeVela's contribution process.
  • Related Docs updated properly. In a new feature or configuration option, an update to the documentation is necessary.
  • Run make reviewable to ensure this PR is ready for review.
  • Added backport release-x.y labels to auto-backport this PR if necessary.

How has this code been tested

Special notes for your reviewer


Summary by cubic

Allow pkg/providers/http to read HTTP headers (e.g., Authorization) from Kubernetes Secrets instead of hardcoding tokens in Application CRs. This improves security and simplifies configuration.

  • New Features
    • Added headersFromSecret to the CUE schema and Go Request to map header names to Secret secret/key (optional namespace).
    • Resolves header values at runtime via KubeClient; defaults namespace to the process context when not provided.
    • Returns clear errors when the Secret/key is missing or when KubeClient is not provided.
    • Added tests covering success, missing Secret, missing key, and namespace defaulting.

Written for commit 8fa7e21. Summary will update on new commits.

Review in cubic

@cubic-dev-ai cubic-dev-ai Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

1 issue found across 3 files

Reply with feedback, questions, or to request a fix.

Fix all with cubic | Re-trigger cubic

Comment thread pkg/providers/http/http.go
@codecov

codecov Bot commented Jun 21, 2026

Copy link
Copy Markdown

Codecov Report

❌ Patch coverage is 91.30435% with 2 lines in your changes missing coverage. Please review.
✅ Project coverage is 67.69%. Comparing base (d7db9c4) to head (8fa7e21).
⚠️ Report is 12 commits behind head on main.

Files with missing lines Patch % Lines
pkg/providers/http/http.go 91.30% 1 Missing and 1 partial ⚠️
Additional details and impacted files
@@            Coverage Diff             @@
##             main     #229      +/-   ##
==========================================
+ Coverage   62.49%   67.69%   +5.20%     
==========================================
  Files          62       65       +3     
  Lines        4415     5429    +1014     
==========================================
+ Hits         2759     3675     +916     
- Misses       1324     1367      +43     
- Partials      332      387      +55     
Flag Coverage Δ
e2etests 21.26% <0.00%> (?)
unit-test 61.72% <91.30%> (-0.77%) ⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

Signed-off-by: anish bista <anishbista053@gmail.com>
@anishbista60

anishbista60 commented Jun 21, 2026

Copy link
Copy Markdown
Author

Testing locally:

I switched to PR kubevela/kubevela#7194. Then I changed to go mod file

replace (
	github.com/kubevela/workflow => /home/anish60/workflow
)

Ran make core-install, def-install, core-run

Once, controller is ready, Apply the manifest

  apiVersion: v1
  kind: Secret
  metadata:
    name: api-credentials
    namespace: default
  type: Opaque
  stringData:
    token: "Bearer sk-supersecret-12345"

---  
  apiVersion: apps/v1
  kind: Deployment
  metadata:
    name: httpbin
    namespace: default
  spec:
    replicas: 1
    selector:
      matchLabels: {app: httpbin}
    template:
      metadata:
        labels: {app: httpbin}
      spec:
        containers:
          - name: httpbin
            image: kennethreitz/httpbin
            ports:
              - containerPort: 80
---
  apiVersion: v1
  kind: Service
  metadata:
    name: httpbin
    namespace: default
  spec:
    selector: {app: httpbin}
    ports:
      - port: 80  
        targetPort: 80
---

  apiVersion: core.oam.dev/v1beta1
  kind: Application
  metadata:
    name: demo-request-step
    namespace: default
  spec:
    components: []
    workflow:
      steps:
        - name: notify
          type: request
          outputs:
            - name: authHeader
              valueFrom: response
          properties:
            url: http://localhost:8081/headers
            method: GET
            headersFromSecret:
              - name: Authorization
                secret: api-credentials
                key: token
                namespace: default

Make sure to portforward the service at port 8081

After that Application CR would look like below

apiVersion: core.oam.dev/v1beta1
kind: Application
metadata:
  annotations:
    kubectl.kubernetes.io/last-applied-configuration: |
      {"apiVersion":"core.oam.dev/v1beta1","kind":"Application","metadata":{"annotations":{},"name":"demo-request-step","namespace":"default"},"spec":{"components":[],"workflow":{"steps":[{"name":"notify","outputs":[{"name":"authHeader","valueFrom":"response"}],"properties":{"headersFromSecret":[{"key":"token","name":"Authorization","namespace":"default","secret":"api-credentials"}],"method":"GET","url":"http://localhost:8081/headers"},"type":"request"}]}}}
    oam.dev/kubevela-version: UNKNOWN
  creationTimestamp: "2026-06-21T07:56:33Z"
  finalizers:
  - app.oam.dev/resource-tracker-finalizer
  generation: 1
  name: demo-request-step
  namespace: default
  resourceVersion: "780838"
  uid: e52942ef-fedf-4a36-b24e-6e0d01ed37da
spec:
  components: []
  workflow:
    steps:
    - name: notify
      outputs:
      - name: authHeader
        valueFrom: response
      properties:
        headersFromSecret:
        - key: token
          name: Authorization
          namespace: default
          secret: api-credentials
        method: GET
        url: http://localhost:8081/headers
      type: request
status:
  conditions:
  - lastTransitionTime: "2026-06-21T07:56:33Z"
    reason: Available
    status: "True"
    type: Parsed
  - lastTransitionTime: "2026-06-21T07:56:33Z"
    reason: Available
    status: "True"
    type: Revision
  - lastTransitionTime: "2026-06-21T07:56:33Z"
    reason: Available
    status: "True"
    type: Policy
  - lastTransitionTime: "2026-06-21T07:56:33Z"
    reason: Available
    status: "True"
    type: Render
  - lastTransitionTime: "2026-06-21T07:56:33Z"
    reason: Available
    status: "True"
    type: Workflow
  - lastTransitionTime: "2026-06-21T07:56:33Z"
    reason: ReconcileSuccess
    status: "True"
    type: Ready
  latestRevision:
    name: demo-request-step-v1
    revision: 1
    revisionHash: 819fb21900658cb0
  observedGeneration: 1
  status: running
  workflow:
    appRevision: demo-request-step-v1
    contextBackend:
      apiVersion: v1
      kind: ConfigMap
      name: workflow-demo-request-step-context
      namespace: default
      uid: 6ccd4e9e-08ed-498a-944d-c3ea65bfb823
    endTime: "2026-06-21T07:56:33Z"
    finished: true
    mode: StepByStep-DAG
    startTime: "2026-06-21T07:56:33Z"
    status: succeeded
    steps:
    - firstExecuteTime: "2026-06-21T07:56:33Z"
      id: zj77pshkwv
      lastExecuteTime: "2026-06-21T07:56:33Z"
      name: notify
      phase: succeeded
      type: request
    suspend: false
    terminated: false

This creates the configmap as well with data field that contain token

Name:         workflow-demo-request-step-context
Namespace:    default
Labels:       <none>
Annotations:  vela.io/startTime: 2026-06-21 13:26:33.096781116 +0530 IST m=+62.769867856

Data
====
vars:
----
authHeader: {
  headers: {
    "Accept-Encoding": "gzip"
    Authorization:     "Bearer sk-supersecret-12345"
    "Content-Type":    "application/json"
    Host:              "localhost:8081"
    "User-Agent":      "Go-http-client/1.1"
  }
}



BinaryData
====

Events:  <none>

@anishbista60 anishbista60 marked this pull request as ready for review June 21, 2026 07:51

@cubic-dev-ai cubic-dev-ai Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

1 issue found across 3 files

Reply with feedback, questions, or to request a fix.

Fix all with cubic | Re-trigger cubic

Comment thread pkg/providers/http/http.go
@anishbista60

Copy link
Copy Markdown
Author

@anishbista60 anishbista60 changed the title Feat: leverage the secret to read authorizatoin header Feat: leverage the secret to read authorization token Jun 21, 2026
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.

[LFX Mentorship] Strengthen KubeVela's Secret & Configuration Handling: Secret-sourced HTTP Headers + CRD-based Config Management

1 participant