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

[Feature Request] No FedRAMP Moderate blueprint family — the platform supports FRM but every workload blueprint is still FedRAMP High or IL5 only

Abierto
  • ¿Algo no está bien?
#192 0 comentarios 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
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
38/100
Tipo de issue
Nueva funcionalidad
Claridad
Bastante claro
Estado de actividad
Tranquilo
Stack tecnológico
google-cloud
Área
cloud, infrastructure, security

Línea de trabajo

Comienza con blueprints/ y compara las cuatro familias existentes en v2.13.0 y v3.0.0; después, lee las etapas de FAST 0-bootstrap, 1-resman, 2-networking y 3-security, además del README de networking-stage. El trabajo estará terminado cuando el repositorio tenga un enfoque decidido y documentado para la cobertura de workloads de FedRAMP Moderate e identifique qué blueprints existentes son seguros o requieren cambios.

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

Descripción

enhancement Level of Effort - High Priority - Medium

Feature Description

blueprints/ contains four families — fedramp-high, il5, stand-alone and third-party-solutions. There is no fedramp-moderate family, and the tree is identical at v2.13.0 and v3.0.0. Meanwhile the platform itself gained FedRAMP Moderate support in v3.0.0: kms_protection_level is now a variable across 0-bootstrap, 1-resman, 2-networking and 3-security, and the networking stage README is now "FedRAMP High / Moderate Network".

So an operator can now stand up a FedRAMP Moderate landing zone and then has no blueprint written for that regime to deploy a workload into it.

Use Case

FedRAMP Moderate is the larger share of federal and state workloads, and the reason to choose it over High is usually cost and operational burden — Moderate permits SOFTWARE protection level where High typically requires HSM, for example. Today that saving stops at the landing-zone boundary: the moment a team deploys Cloud SQL, App Engine, Cloud Run or Gemini Enterprise, the only blueprints available are the FedRAMP High ones, which carry High's controls and costs.

The practical outcomes are all bad: deploy the High blueprint into a Moderate environment and inherit controls (and spend) the regime does not require; hand-roll a Moderate variant and lose the reusability the repository exists to provide; or fall back to High for the whole deployment and lose the reason for choosing Moderate.

Proposed Solution

Either a blueprints/fedramp-moderate/ family, or — probably better given the overlap — a regime input on the existing blueprints so one blueprint can emit the correct posture per regime, in the same spirit as kms_protection_level in the FAST stages. A statement of intent would help on its own: even a README note saying which blueprints are safe to use unmodified under Moderate, and which are not, would unblock planning.

Compliance & Deployment Context

  • Target Deployment Type(s):
    • US Region Restricted (e.g., Access Policy constraint)
    • FedRAMP Medium
    • FedRAMP High
    • FedRAMP Moderate
    • DoD IL4
    • DoD IL5
    • All / General
  • Relevant NIST 800-53r5 Controls: SC-12 / SC-13 (key management and protection level are where High and Moderate visibly diverge today); CM-6 for the baseline the blueprints encode.

Reusability Check

  • I have checked if this functionality can be achieved by extending an existing module or blueprint.
  • I have verified that this does not duplicate existing functionality.

Extending the existing blueprints is exactly what is proposed above — a new parallel tree is the alternative, not the preference. On duplication: #102 is open and covers only the gemini-enterprise blueprint; #101, the platform-level request, is closed as completed. Nothing covers the rest of the blueprint library.

Alternatives Considered

Deploying the FedRAMP High blueprints into a Moderate environment — works, but over-controls and over-spends, and misrepresents the deployed posture in an SSP. Forking a blueprint per customer — loses reusability and drifts from upstream fixes. Widening #102 to cover all blueprints — possible, but its title and body are scoped to Gemini Enterprise, so a separate request tracks better.

Additional Context

Verified against the repository tree at v2.13.0 (8f5b67a6) and v3.0.0 (f64ce6cd): the four blueprint families are unchanged between the two tags.

Lenguaje dominante
HCL
Estrellas
51
Forks
21
Merge medio
1 d 17 h
PR fusionados (30 d)
29

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 google/stellar-engine

Todos los issues de google/stellar-engine

Issues similares

Más issues de Cloud

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.