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

Azure Bucket: anonymous access to public containers is unreachable since #1875

Abierto
  • ¿Algo no está bien?
#2,136 1 comentario 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 2 días

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
55/100
Tipo de issue
Error
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
azure, go
Área
backend, cloud

Línea de trabajo

Empieza en internal/bucket/azure/blob.go, en chainCredentialWithSecret y en la ruta de selección del cliente; después inspecciona auth/azure.NewTokenCredential y los casos anónimos en blob_test.go. Ejecuta staticcheck ./internal/... y make test para confirmar el flujo de control y la cobertura existente. Se considera terminado cuando un Bucket sin secretRef puede acceder de forma anónima en producción y las pruebas cubren esa ruta.

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

Descripción

Since #1875 (04ab27b42a4ab3bc989accdd8e958e189c60370c, merged 2025-09-02), a Bucket with provider: azure and no secretRef can no longer get an unauthenticated client. Both paths that would produce one are unreachable on main (99d894dd).

Why

chainCredentialWithSecret appends a credential that is never nil:

https://github.com/fluxcd/source-controller/blob/main/internal/bucket/azure/blob.go#L518

if token := azureauth.NewTokenCredential(ctx, opts...); token != nil {
    creds = append(creds, token)
}

auth/azure.NewTokenCredential returns &tokenCredential{ctx, opts} — a non-nil pointer in a non-nil interface, unconditionally. So the guard is always true, creds is never empty, len(creds) > 0 always holds, and the documented return nil, nil ("If no valid token is created, it returns nil") is dead code.

That propagates to the caller, where token != nil is then always true:

token, err = chainCredentialWithSecret(ctx, o.secret, o.authOpts...)
...
if token != nil {
    c.Client, err = azblob.NewClient(obj.Spec.Endpoint, token, clientOpts)
    return
}

// Fallback to simple client.
c.Client, err = azblob.NewClientWithNoCredential(obj.Spec.Endpoint, clientOpts)  // unreachable

The other unauthenticated path, the o.withoutCredentials early return, is gated on an unexported withoutCredentials() option that is only ever called from blob_test.go (4 call sites) and never from production code. So the anonymous behaviour that tests exercise is reached through a door the reconciler does not have, which is why the tests still pass.

Before #1875 this worked: creds only received NewEnvironmentCredential when that returned non-nil, so an empty chain — and therefore the nil, nil return and the no-credential fallback — was reachable.

Impact

A public/anonymously-readable Azure container configured without a secretRef gets an azblob client carrying a token credential instead of a no-credential client. At request time that calls auth.GetAccessToken, which fails when no Azure identity is configured, so the fetch fails rather than falling back to anonymous access.

I have verified the control flow and the regression point by reading the source; I have not reproduced it against a live public container, so please treat the runtime symptom as inferred from the code path rather than observed.

Found by

staticcheck ./internal/... flags it as SA4023, "this comparison is always true". The repo has no .golangci.yaml and CI runs make test only, so the check does not currently run anywhere.

Possible fixes
  • Drop the always-true token != nil guard and decide the chain on whether any credential source is actually configured, so chainCredentialWithSecret can return nil, nil again as documented.
  • Or make the intent explicit at the caller and have the reconciler pass the existing withoutCredentials() option when no secretRef is set, which would also give the anonymous path production coverage rather than test-only coverage.

Happy to open a PR for whichever direction you prefer.

Lenguaje dominante
Go
Estrellas
283
Forks
252
Merge medio
1 h 6 min
PR fusionados (30 d)
12

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 fluxcd/source-controller

Todos los issues de fluxcd/source-controller

Issues similares

Más issues de Go

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.