Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

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

Open
  • Is something wrong?
#192 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 2 days

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
38/100
Issue type
Feature
Clarity
Mostly clear
Activity status
Quiet
Tech stack
google-cloud
Domain
cloud, infrastructure, security

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.

Description

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.

Dominant language
HCL
Stars
51
Forks
21
Avg merge
1d 15h
Merged PRs (30d)
30

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from google/stellar-engine

All issues in google/stellar-engine

Similar issues

More Cloud issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.