Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

IronicRunbook: allow step args to be loaded from a Secret via valueFrom.secretKeyRef

Aperta
  • Qualcosa non va?
#2,444 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
35/100
Tipo di issue
Funzionalità
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
kubernetes, python
Ambito
backend, infrastructure, security

Direzione di ricerca

Start in plugins/ironic/runbooks/reconcile.py and trace how IronicRunbook step args are copied and how cloudCredentialsRef Secrets are read. Inspect the CRD definition and existing reconcile tests or entry points to determine schema and error-handling conventions. Done means malformed or missing references fail clearly without exposing values, while valid references reach Ironic and the documented drift, rotation, and logging behavior is covered.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

Problem

IronicRunbook step args are copied verbatim into the Ironic runbook
(plugins/ironic/runbooks/reconcile.py). Some steps need a sensitive value,
such as a token or password. Today the only way to provide one is to put it
in plain text in the CR spec, which means it ends up in git and anywhere the
manifest is rendered or displayed.

The CRD already references a Secret for cloudCredentialsRef, but nothing
equivalent exists for step arguments.

Proposal

Allow a step argument to be loaded from a Kubernetes Secret in the CR's
namespace, using the familiar valueFrom.secretKeyRef shape:

spec:
  steps:
  - interface: management
    step: some_step
    order: 1
    args:
      plain_arg: value
      sensitive_arg:
        valueFrom:
          secretKeyRef:
            name: my-secret
            key: some-key

At reconcile time the operator resolves each reference and sends the
resolved value to Ironic. The Secret itself can be populated by any means,
for example an ExternalSecret, so the sensitive value never needs to live
in the manifest.

Things to consider

  • Schema / CRD: args is currently free-form
    (x-kubernetes-preserve-unknown-fields). Decide whether to recognise
    valueFrom anywhere in args (including nested values) or only on
    top-level arguments, and reject a valueFrom that is malformed.
  • Missing Secret or key: fail the reconcile with a clear status
    condition and message rather than sending a partial runbook.
  • RBAC: the operator needs get on Secrets in the namespaces it
    reconciles. It already reads the cloudCredentialsRef Secret, so this may
    already be covered.
  • Rotation: the hook only watches the IronicRunbook kind, so a changed
    Secret is only picked up by the scheduled resync. Consider also binding on
    referenced Secrets, or document the resync interval as the propagation
    delay.
  • Drift detection: Ironic masks sensitive-looking values (for example
    keys containing token or password) as ****** when it returns runbook
    steps, so they never compare equal to the desired value and /steps is
    PATCHed on every reconcile. That already happens for literal values today
    (see the note in reconcile.py), but resolved secrets will make it more
    common. Comparing a hash of the resolved steps, stored in the ownership
    markers in extra, would avoid needless rewrites.
  • Logging and status: never write resolved values into operator logs,
    status messages or events.
  • Docs: note that the resolved value is still stored in Ironic's
    database as part of the runbook, so this protects the manifest, not
    Ironic.
Lingua principale
Python
Stelle
13
Fork
11
Merge medio
1g 2h
PR unite (30g)
103

Preparare l'ambiente

  • Nessun Dockerfile né file Docker Compose
  • Ha un modello di pull request
  • Nessuna guida per i contributori

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di rackerlabs/understack

Tutte le issue di rackerlabs/understack

Issue simili

Altre issue su Python

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.