google / google/stellar-engine
[Feature Request] No FedRAMP Moderate blueprint family — the platform supports FRM but every workload blueprint is still FedRAMP High or IL5 only
- Dominant language
- HCL
- Stars
- 49
- Forks
- 20
- Avg merge
- 3d 14h
- Merged PRs (30d)
- 28
Description
## 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
* [x] 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
* [x] I have checked if this functionality can be achieved by extending an existing module or blueprint.
* [x] 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](https://github.com/google/stellar-engine/issues/102) is open and covers **only** the `gemini-enterprise` blueprint; [#101](https://github.com/google/stellar-engine/issues/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](https://github.com/google/stellar-engine/issues/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.
Contributor guide
Research direction
Start with blueprints/ and compare the four existing families at v2.13.0 and v3.0.0, then read the FAST stages 0-bootstrap, 1-resman, 2-networking, and 3-security plus the networking-stage README. Done means the repository has a decided, documented approach for FedRAMP Moderate workload coverage and identifies which existing blueprints are safe or require changes.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- google-cloud
- Domain
- cloud, infrastructure, security
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 38/100