[Feature Request] Streamline FAST stage IAM impersonation tooling to reduce cross-stage 403 errors
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
- Active
- Tech stack
- shell, terraform
- Domain
- cloud, devops, infrastructure, security
Research direction
Start by inspecting the existing tooling in scripts/ or fast/, especially deploy.sh, and review how stage-specific .tfvars and impersonation environment variables are handled. Compare the proposed helper, pre-flight authorization check, and docs/ddg.md troubleshooting section with current workflows; done means the selected scope is implemented and cross-stage 403 recovery is documented.
Written by the indexing model from the issue text.
Description
Feature Description
Provide developer experience utilities, active-context indicators, and streamlined helper tooling for managing service account impersonation across Fabric FAST deployment stages.
Use Case
Fabric FAST enforces least-privilege architecture by dedicating separate service accounts to each deployment stage (0-bootstrap, 1-resman, 2-networking, 3-security). Operators must switch service account impersonation contexts each time they transition between stages or inspect cross-stage resources.
In practice, this frequent context switching causes recurring authorization errors (403 Forbidden) when operators run commands against a stage while still impersonating a previous stage's service account. This creates cognitive overload, friction during cross-stage troubleshooting, and client frustration.
Proposed Solution
- Stage Activation / Context Helper: Provide a lightweight helper script or shell function (e.g., within
scripts/orfast/) that exports the appropriateGOOGLE_IMPERSONATE_SERVICE_ACCOUNT/CLOUDSDK_AUTH_IMPERSONATE_SERVICE_ACCOUNTenvironment variable, checks credentials, and prepares stage-specific.tfvarsin one command. - Pre-flight Stage Authorization Verification: Add a check in stage tooling or
deploy.shthat validates whether the currently active identity has permission to impersonate the target stage service account before runningterraform planorapply. - Enhanced Cross-Stage Debugging Documentation: Add an explicit cross-stage IAM impersonation matrix and troubleshooting section in
docs/ddg.mdexplaining how to debug permissions and recover from common 403 scenarios.
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: AC-02 (Account Management), AC-06 (Least Privilege), IA-02 (Identification and Authentication)
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.
Alternatives Considered
- Consolidating into a single administrative service account: Rejected because it violates least privilege, separation of duties, and FedRAMP / DoD IL5 compliance requirements.
- Manual variable exports only: Currently causes frequent 403 errors and developer confusion when switching stages.
Additional Context
Improving the developer experience around multi-stage impersonation preserves strict security boundaries while eliminating the primary source of authorization errors during deployments.
- Dominant language
- HCL
- Stars
- 51
- Forks
- 21
- Avg merge
- 1d 15h
- Merged PRs (30d)
- 30
Getting set up
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from google/stellar-engine
-
documentation Level of Effort - High Priority - Medium
Difficulty 1/5 1-3 hours Newbie friendliness 88/100
google/stellar-engine#232 ·
Maintainers usually reply within 2 days
-
Bug Gemini - Government Level of Effort - Low Priority - Low
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
google/stellar-engine#135 ·
Maintainers usually reply within 2 days
-
[Feature Request] gem4gov: implement BigQuery import in the standalone datastore import commandOpenEnhancement Gemini - Government Level of Effort - Medium Priority - Medium
Difficulty 2/5 1-3 hours Newbie friendliness 84/100
google/stellar-engine#122 ·
Maintainers usually reply within 2 days
-
documentation Level of Effort - Medium Priority - Medium
Difficulty 2/5 Half a day Newbie friendliness 72/100
google/stellar-engine#117 · 1 comment ·
Maintainers usually reply within 2 days
-
bug documentation
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
google/stellar-engine#91 ·
Maintainers usually reply within 2 days
All issues in google/stellar-engine
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
earendil-works/pi#10324 · 1 comment ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
Maintainers usually reply within 1 day
-
Cloudfront-rocoptiq): stable-staging: extras-rocoptiq origin missing OS-profile CloudFront rewriteOpen
Difficulty 1/5 Under an hour Newbie friendliness 92/100
Maintainers usually reply within 1 day
-
hfile_s3: reading to EOF fails with EINVAL when object size is a multiple of the read part sizeOpen
Difficulty 2/5 1-3 hours Newbie friendliness 84/100
Maintainers usually reply within 3 days
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
boostorg/website-v2#2841 ·
Maintainers usually reply within 1 day