[Bug] 2-networking-a-fedramp: the hierarchical firewall policy defaults to the unprefixed name net-default, which is unique per organization — a second deployment in the same org (a redeploy under a new prefix) fails at apply
Los mantenedores suelen responder en 2 días
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 3/5
- Tiempo estimado
- 1-2 días
- Aptitud para principiantes
- 78/100
- Tipo de issue
- Error
- Claridad
- Bien especificado
- Estado de actividad
- Activo
- Stack tecnológico
- google-cloud, terraform
- Área
- cloud, infrastructure
Línea de trabajo
Start with fast/stages-aw/2-networking-a-fedramp/main.tf:44-47 and variables.tf:78, then compare the naming guidance in docs/ddg.md, the stage README, and terraform.tfvars.sample. Reproduce the Stage 2 redeployment with a second prefix and inspect the hierarchical firewall policy failure. Done means deployments in one organization no longer collide, or the required organization-unique setting is documented in the named guides and sample.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
Bug Description
fast/stages-aw/2-networking-a-fedramp/main.tf:44-47 creates the stage's hierarchical firewall policy with
name = var.factories_config.firewall_policy_name, whose default (variables.tf:78) is "net-default". A hierarchical firewall policy's short name must be unique within the organization, and every other resource the stage names carries var.prefix. So the second deployment of the stage in an organization — the case the project's own guidance creates, since project IDs are never reusable and a rebuild has to use a new prefix — fails at apply, 320 of 322 resources in:
Error: Error creating FirewallPolicy: googleapi: Error 400: Invalid value for field 'resource.shortName': 'net-default'. The display name is already used. Please choose another one, invalid
with module.firewall-policy-default.google_compute_firewall_policy.hierarchical[0],
on ../../../modules/net-firewall-policy/hierarchical.tf line 17, in resource "google_compute_firewall_policy" "hierarchical":
The operator can set factories_config.firewall_policy_name in terraform.tfvars, but nothing in docs/ddg.md, the stage README or terraform.tfvars.sample says the name is org-unique or that a second deployment must change it.
Environment and Deployment Context
- Stellar Engine Version/Commit:
v4.0.0(6d7d08c0); unchanged onmain(20830097, 2026-09-18). - Deployment Type:
- US Region Restricted (e.g., Access Policy constraint)
- FedRAMP Moderate
- FedRAMP High
- DoD IL4
- DoD IL5
- Stand-alone / Custom
- FAST Stage (if applicable):
- Stage 0 (Bootstrap)
- Stage 1 (Resource Management)
- Stage 2 (Networking)
- Stage 3 (Security)
Steps to Reproduce
- Deploy Stages 0–2 in an organization with prefix A.
- Deploy Stages 0–2 again in the same organization with prefix B (a rebuild, or a second landing zone for testing), following
docs/ddg.md. - Stage 2's
terraform applyfor prefix B fails onmodule.firewall-policy-default.google_compute_firewall_policy.hierarchical[0]with the error above; everything else in the stage applies.
Expected Behavior
The policy name carries the prefix like the stage's other resources ("${var.prefix}-net-default"), so two deployments in one organization do not collide — or the guide states that factories_config.firewall_policy_name must be unique per organization and must be set for a second deployment.
Actual Behavior
The default collides; the operator discovers factories_config.firewall_policy_name by reading variables.tf.
Relevant Logs and Errors
See above.
Additional Context
- Suggested fix:
firewall_policy_name = optional(string)with the stage defaulting it to"${var.prefix}-net-default"when unset (the same pattern as the stage's VPC, subnet and NVA names); or, at minimum, a note indocs/ddg.mdunder Stage 2.1 and interraform.tfvars.sample. - Related: #228 (the prefix's length arithmetic) is about the same design principle — the prefix is what keeps one organization's deployments apart.
- Lenguaje dominante
- HCL
- Estrellas
- 51
- Forks
- 21
- Merge medio
- 1 d 17 h
- PR fusionados (30 d)
- 29
Preparar el entorno
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Más de google/stellar-engine
-
documentation Level of Effort - High Priority - Medium
Dificultad 1/5 1-3 horas Aptitud para principiantes 88/100
google/stellar-engine#232 ·
Los mantenedores suelen responder en 2 días
-
Bug Gemini - Government Level of Effort - Low Priority - Low
Dificultad 2/5 1-3 horas Aptitud para principiantes 78/100
google/stellar-engine#135 ·
Los mantenedores suelen responder en 2 días
-
[Feature Request] gem4gov: implement BigQuery import in the standalone datastore import commandAbiertoEnhancement Gemini - Government Level of Effort - Medium Priority - Medium
Dificultad 2/5 1-3 horas Aptitud para principiantes 84/100
google/stellar-engine#122 ·
Los mantenedores suelen responder en 2 días
-
documentation Level of Effort - Medium Priority - Medium
Dificultad 2/5 Medio día Aptitud para principiantes 72/100
google/stellar-engine#117 · 1 comentario ·
Los mantenedores suelen responder en 2 días
-
[Feature Request] No research blueprint family — the README names universities as a target audience, every blueprint is FedRAMP High, FedRAMP Moderate or IL5Posiblemente ocupada @Calvin-Cheng1 la tomó hace 21 días. Abiertoenhancement
google/stellar-engine#239 · 2 comentarios · 1 asignado ·
Los mantenedores suelen responder en 2 días
Todos los issues de google/stellar-engine
Issues similares
-
Bump up AWS SDK to 2.54.3Abierto
Dificultad 2/5 1-3 horas Aptitud para principiantes 68/100
jenkinsci/ec2-plugin#2041 ·
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 72/100
buildkite/elastic-ci-stack-for-aws#1905 ·
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 74/100
spiffe/helm-charts-hardened#976 ·
Los mantenedores suelen responder en 1 día
-
[Bug]: object delete is reported as failed on S3-compatible stores that answer DeleteObject with HTTP 200Posiblemente ocupada Un pull request vinculado a esta issue está abierto o ya se fusionó. Abiertokind/bug
Dificultad 2/5 1-3 horas Aptitud para principiantes 72/100
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 90/100
cloudposse/atmos#3284 ·
Los mantenedores suelen responder en 1 día