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

Drop blockOwnerDeletion on proxy-runner owned Services

Abierto
  • ¿Algo no está bien?
#6,836 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
3/5
Tiempo estimado
1-2 días
Aptitud para principiantes
28/100
Tipo de issue
Refactorización
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
go, kubernetes
Área
authorization, infrastructure

Línea de trabajo

Start in pkg/container/kubernetes/client.go, at ensureBackendServices and the service apply helper, where BlockOwnerDeletion is set, then check the two assertions in client_test.go. The RBAC change touches defaultRBACRules and its kubebuilder marker, followed by regenerating role.yaml. The issue asks a maintainer to decide whether to drop the flag or keep the finalizers grant, so confirm that choice in the thread before editing. Done means the tests pass and role.yaml matches the chosen approach.

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

Descripción

kubernetes needs-triage operator

Proposal

Stop setting blockOwnerDeletion: true on the owner reference the proxy runner puts on the headless and ClusterIP Services pointing at their StatefulSet. Once that's done, drop the apps/statefulsets/finalizers grant that #6756 adds.

Background

On OpenShift, OwnerReferencesPermissionEnforcement rejects a blockOwnerDeletion: true owner reference unless the caller has update on the owner's /finalizers (#6835). #6756 fixes that by granting statefulsets/finalizers to the proxy-runner Role and to the operator ClusterRole. The operator needs it too because Kubernetes won't let it grant a permission it doesn't hold.

That's the standard fix, but it's RBAC we may not need. The flag only does something when the owner is deleted with foreground propagation: the StatefulSet would wait until its Services are gone. We never delete that way:

  • RemoveWorkload deletes the StatefulSet with empty DeleteOptions (background) in pkg/container/kubernetes/client.go.
  • finalizeMCPServer deletes the StatefulSet and both Services by name.
  • Nothing in production code sets PropagationPolicy or DeletePropagationForeground.

GC still removes the Services once the StatefulSet is gone, with or without the flag.

Change

  • pkg/container/kubernetes/client.go, ensureBackendServices: drop BlockOwnerDeletion: ptr.To(true) from the StatefulSet owner reference.
  • pkg/container/kubernetes/client.go, the service apply helper: drop the hardcoded WithBlockOwnerDeletion(true). It ignores whatever the owner passed in says anyway.
  • pkg/container/kubernetes/client_test.go: update the two assertions that expect true.
  • Revert the apps/statefulsets/finalizers entry in defaultRBACRules and its +kubebuilder:rbac marker, then regenerate role.yaml.

Why it's safe

  • Admission rules: the plugin only asks for the finalizers permission when an owner reference is newly blocking or flipped to blocking (source). Removing the flag, or leaving it out, never triggers that check. Any change to owner refs also needs delete on the object itself, and the proxy-runner Role already has delete on services.
  • Existing Services on vanilla clusters: the next Force apply drops the field. That passes even with the plugin on.
  • OpenShift: nothing to migrate, because Service creation has failed there since #3992.
  • Recreated StatefulSet (new UID): under B this needs no extra permission. Under the current grant approach it needs the finalizers permission every time.
  • Coverage: this is the only owner reference the proxy runner sets. The runner creates the StatefulSet with no owner, and the operator later adopts it under the MCPServer.

What B buys over the RBAC grant alone

  • Least privilege: with the grant, every MCPServer's runner service account can set blocking owner references on any StatefulSet in its namespace.
  • Mixed versions: a newer runner works against an older operator chart that lacks statefulsets/finalizers.

Related

  • Enable OwnerReferencesPermissionEnforcement in test/e2e/thv-operator/kind-config.yaml (apiServer.extraArgs). The chainsaw job in operator-ci.yml creates its kind cluster without a config and would need one too. This would have caught #3992, and it would prove B in CI. Ideally it lands with or before B.

Open question

@ChrisJBurns, what do you think? Is it worth dropping the flag and shrinking the RBAC footprint, or should we stick with the conventional /finalizers grant from #6756?

Refs #6756, #6835

Lenguaje dominante
Go
Estrellas
2.3k
Forks
318
Merge medio
2 d 3 h
PR fusionados (30 d)
104

Preparar el entorno

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 stacklok/toolhive

Todos los issues de stacklok/toolhive

Issues similares

Más issues de Go

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.