Static Control Plane config silently ignores sharedSSOName/userGroups under projects[], and there's no API/CLI/IaC way to set them
I maintainer di solito rispondono entro 2 giorni
Nessuno ha ancora preso questa issue.
Valutazione
- Difficoltà
- 5/5
- Tempo stimato
- Più di una settimana
- Idoneità per principianti
- 38/100
- Tipo di issue
- Funzionalità
- Chiarezza
- Abbastanza chiara
- Stato di attività
- Attiva
- Stack tecnologico
- go, terraform, yaml
- Ambito
- authentication, authorization
Direzione di ricerca
Start with ControlPlaneProject in pkg/config/control_plane.go and the SSO login path in pkg/app/server/httpapi/login.go; compare those with the datastore Project model and existing project RPCs in pkg/app/server/service/webservice/service.proto. First determine which proposed fix to pursue, since the issue lists several independent options. Done means static config or a supported API/CLI/IaC path can manage the project SSO and group mappings, with unsupported config handled explicitly.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
Summary:
The Control Plane's static YAML config accepts sharedSSOName and userGroups keys under spec.projects[], but ControlPlaneProject (pkg/config/control_plane.go) only defines id, desc, and staticAdmin. These extra keys parse without error and are silently dropped — nothing in the config ever reaches the project's actual datastore record, and no validation warns that they're unsupported. Separately, even if you set a project up correctly via the ops console, there is no scripted/API way to populate userGroups (SSO group → role mappings) — this can currently only be done by clicking through the web console UI after logging in as that project's admin. Together, these make it effectively impossible to manage a PipeCD project (with SSO + RBAC group mappings) as code.
Steps to reproduce
- Add a project to the Control Plane config with sharedSSOName and userGroups set, e.g.:
apiVersion: pipecd.dev/v1beta1
kind: ControlPlane
spec:
projects:
- id: my-project
staticAdmin:
username: admin
passwordHash: "<bcrypt hash>"
sharedSSOName: gitlab
userGroups:
- ssoGroup: my-org/my-team
role: Admin
sharedSSOConfigs:
- name: gitlab
provider: OIDC
oidc: {...}
-
Start the Control Plane. Config loads with no error.
-
Log in via static admin for my-project — this succeeds (served from the in-memory projectsInConfig map).
-
Try to log in via SSO for my-project — this fails with: auth-handler: Unable to find project my-project {"error": "not found"} because handleSSOLogin (pkg/app/server/httpapi/login.go) only ever calls projectGetter.Get() against the datastore, with no fallback to projectsInConfig the way handleStaticAdminLogin has.
Root cause (traced in source)
-
ControlPlaneProject struct (pkg/config/control_plane.go:53) has only 3 fields: ID, Desc, StaticAdmin. sharedSSOName/userGroups in the YAML have nowhere to deserialize into, so they're silently discarded by the YAML/JSON decoder.
-
The real model.Project (datastore record, pkg/model/project.pb.go) does have SharedSsoName and UserGroups fields — but a project only gets a datastore row via the ops console's "Add Project" form (pkg/app/ops/handler/handler.go, handleAddProject), and that form only has 4 fields: ID, Description, SharedSSO, AllowStrayAsViewer. There is no form field, CLI command, or API for userGroups.
-
AddProjectUserGroup/DeleteProjectUserGroup do exist as gRPC WebService RPCs (pkg/app/server/service/webservice/service.proto), callable only after SSO or static-admin login — but this is a chicken-and-egg problem for the very first group mapping (you need SSO working to easily reach the UI as a non-static-admin, and SSO won't work until a group mapping exists... though static-admin login can reach the same settings page, so it's workable, just entirely manual).
-
pipectl has no project subcommand at all (confirmed against cmd/pipectl/main.go's registered command packages: application, deployment, encrypt, event, migrate, piped, planpreview, plugin, transfer — no project).
-
The official terraform-provider-pipecd only implements pipecd_piped and pipecd_application resources — no pipecd_project resource exists to manage SSO config or user groups.
Impact
-
Operators following the documented static-config format for sharedSSOName/userGroups will have SSO silently broken with no indication that the config fields they set have no effect.
-
There is no way to manage project SSO/RBAC configuration as code (Terraform, a pipectl command, a CI script, etc.) — it is a fully manual, UI-only, per-project, post-creation step.
Suggested fixes (any subset would help)
-
Validation: reject or warn on unrecognized keys under spec.projects[] at config-load time, so sharedSSOName/userGroups typos/misunderstandings fail loudly instead of silently.
-
Docs: clarify in the Control Plane config reference that sharedSSOName and userGroups are datastore-only properties, not static-config properties, and link to how to set them (ops console + web UI).
-
CLI: add a pipectl project command group wrapping the existing AddProjectUserGroup/DeleteProjectUserGroup/UpdateProjectSSOConfig gRPC calls, and ideally a project add wrapping the ops console's project-creation flow too.
-
Terraform provider: add a pipecd_project (or pipecd_project_user_group) resource to terraform-provider-pipecd wrapping the same RPCs, enabling real IaC management of project RBAC.
Environment
- PipeCD version: 0.56.0
- Confirmed the same on master as of 2026-10-26 by reading source directly.
- Lingua principale
- Go
- Stelle
- 1.4k
- Fork
- 391
- Merge medio
- 4g 1h
- PR unite (30g)
- 58
Preparare l'ambiente
- Nessun Dockerfile né file Docker Compose
- Ha un modello di pull request
- Leggi la guida per i contributori
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di pipe-cd/pipecd
-
Applications at the repository root are not triggered by new commitsForse già presa @Daksha1611 l’ha presa oggi. Aperta
Difficoltà 2/5 1-3 ore Idoneità per principianti 62/100
I maintainer di solito rispondono entro 2 giorni
-
pipedv1 kubernetes plugins ignore trafficRouting.istio.host in K8S_TRAFFIC_ROUTINGForse già presa @Dhirenderchoudhary l’ha presa oggi. Aperta
Difficoltà 2/5 Mezza giornata Idoneità per principianti 74/100
pipe-cd/pipecd#7626 · 1 commento ·
I maintainer di solito rispondono entro 2 giorni
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 72/100
I maintainer di solito rispondono entro 2 giorni
-
pipectl transfer restore application drops backed-up labelsForse già presa @bhavishyajain545 l’ha presa 1 giorno fa. Aperta
Difficoltà 2/5 1-3 ore Idoneità per principianti 86/100
pipe-cd/pipecd#7622 · 1 commento ·
I maintainer di solito rispondono entro 2 giorni
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 83/100
I maintainer di solito rispondono entro 2 giorni
Tutte le issue di pipe-cd/pipecd
Issue simili
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 68/100
I maintainer di solito rispondono entro 1 giorno
-
docker-compose: postgres healthcheck should probe TCP (pg_isready -h localhost)Forse già presa @zezo-mohamed22 l’ha presa oggi. Aperta
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 82/100
OneBusAway/watchdog#305 · 1 commento ·
I maintainer di solito rispondono entro 1 giorno
-
self-care self-care:agent-discoverability
Difficoltà 2/5 1-3 ore Idoneità per principianti 62/100
githubnext/gh-cao#20928 ·
I maintainer di solito rispondono entro 1 giorno
-
automation documentation
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 70/100
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 85/100
SocialGouv/iterion#3287 ·
I maintainer di solito rispondono entro 1 giorno