Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

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

Abierto
  • ¿Algo no está bien?
#2,444 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
35/100
Tipo de issue
Nueva funcionalidad
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
kubernetes, python
Área
backend, infrastructure, security

Línea de trabajo

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.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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.
Lenguaje dominante
Python
Estrellas
13
Forks
11
Merge medio
1 d 2 h
PR fusionados (30 d)
103

Preparar el entorno

  • Sin Dockerfile ni archivo de Docker Compose
  • Tiene una plantilla de pull request
  • Sin guía de contribución

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de rackerlabs/understack

Todos los issues de rackerlabs/understack

Issues similares

Más issues de Python

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.