bug: Restore GCP metadata server support #3860

Activity

1. feloy

   added the

   Bug

   issue type on Sep 29, 2026
2. github-actions

   added

   state:triage-neededOpened without agent diagnostics and needs triageOpened without agent diagnostics and needs triage

   on Sep 29, 2026
3. elezar commented on Sep 30, 2026

   

   elezar

   on Sep 30, 2026

   Member

   More actions

   📋 triage-agent

   Triage Assessment

   Classification: validated-bug

   Summary

   The documented GCP metadata emulator was removed during the sandbox/supervisor runtime split and has not been restored in the inspected code. This is a regression of an implemented capability, rather than a new provider feature. The report contains enough information to validate the defect despite the missing exact build, OS, and compute driver.

   Investigation

   • Original capability: feat: emulate GCE metadata server for Google SDK access in sandboxes #1706 was implemented by merged PR feat(sandbox): add GCE metadata emulator for Google Cloud #1763. The emulator supplied project and service-account metadata, including token placeholders, and SDK discovery used injected GCE_METADATA_HOST / GCE_METADATA_IP values pointing to 127.0.0.1:8174.
   • Removal: PR feat(isolation): implement the RFC 0012 sandbox architecture #2942 merged on September 16, 2026, as c1f2e7189f837f98d00fb3821b6fb8d1253ceec3. Its diff deletes crates/openshell-sandbox/src/google_cloud_metadata.rs (622 lines) and metadata_server.rs (231 lines). The inspected checkout (be4790c32bbe1b26d2fc4a0abfc78608b20fff31) has no replacement metadata handler/listener; the remaining provider and credential code still references the loopback discovery environment. docs/how-it-works/providers/google.mdx still promises the emulator, and providers/google-cloud.yaml still describes SDK compatibility through it. The current main tree (21fea95935035c09f76dc1f2b1f82dd5d4196fac) also lacks the removed runtime modules.
   • Important reproduction distinction: required_platform_adapter: gcp-metadata and the explicit unavailable-adapter rejection belong to still-open PR refactor(providers)!: declare imported profile behavior safely #3775, inspected at b13c130e3d8368d69db0294bb0c616e18ab10e8f. Its ProviderProfile::ensure_platform_adapter_available() rejects this adapter. The main profile inspected during triage does not declare that requirement. Therefore the exact quoted import/attachment error should not be attributed to every released post-split build; the missing emulator is the independently confirmed defect. A maintainer also requested this restoration bug in the PR discussion.
   • Endpoint scope: A direct request to metadata.google.internal is not a faithful test of the former emulator flow. The documented flow targets the injected loopback endpoint. Restoration criteria should verify SDK discovery through the configured emulator, project/service-account responses, and placeholder-token behavior on explicitly identified supported runtimes. They should not require opening access to the host's real cloud metadata service.
   • Known fixes / related reports: Latest stable release is v0.1.2 (September 28, 2026); its release notes contain no metadata restoration. Searches of open/closed GCP issues and metadata PRs found the original implemented feature (feat: emulate GCE metadata server for Google SDK access in sandboxes #1706 / feat(sandbox): add GCE metadata emulator for Google Cloud #1763), but no separate canonical restoration report or fixing change. PR refactor(providers)!: declare imported profile behavior safely #3775 detects the unavailable capability; it does not restore it.
   • Validation limits and ownership: This assessment is based on implementation history, current source, documentation, and independent reviewer analysis. No live gateway/sandbox or GCP SDK reproduction was run, so exact failure output and the driver/SDK compatibility matrix remain unverified. Runtime service lifecycle/reachability across the sandbox/supervisor boundary and provider environment/capability handling own this behavior. A concrete SDK version, compute driver, build SHA, and redacted probe against the injected metadata address would resolve that remaining runtime uncertainty.

   Impact Signals

   • Affected users/scope: Workloads relying on the documented Google Cloud provider's metadata-based SDK discovery. Exact driver/SDK combinations and number of affected users are unknown.
   • Regression: Confirmed removal of the previously implemented emulator in feat(isolation): implement the RFC 0012 sandbox architecture #2942.
   • Workaround: Manual project/account configuration or an alternative authentication flow may work for some applications, but does not preserve metadata-dependent discovery. No equivalent workaround was validated here.
   • Evidence quality: High for the source-level regression and documentation mismatch; limited for live runtime behavior because no end-to-end reproduction was performed.

   Human Decision Required

   Decide whether OpenShell should address this issue. If yes, apply state:accepted, associate it with a roadmap item, or do both, and decide whether the work remains human-owned. Acceptance and sequencing remain maintainer decisions. To queue investigation or planning for an unattended agent, also apply agent:plan-requested; alternatively, directly request create-spike or build-from-issue on this issue. If declining, close as not planned with the rationale.
4. elezar

   added

   state:validated

   area:providers

   area:supervisorProxy and routing-path workProxy and routing-path work

   area:sandboxSandbox runtime and isolation workSandbox runtime and isolation work

   and removed

   state:triage-neededOpened without agent diagnostics and needs triageOpened without agent diagnostics and needs triage

   on Sep 30, 2026
5. feloy commented on Sep 30, 2026

   

   feloy

   on Sep 30, 2026

   Last edited by feloy

   ContributorAuthor

   More actions

   🏗️ build-plan

   Implementation Plan

   Issue type: fix
   Complexity: Medium
   Confidence: High for architecture; SDK compatibility requires Linux E2E validation

   Summary

   Restore the GCP metadata emulator in the supervisor, relaying the reserved 127.0.0.1:8174 destination over the existing authenticated network mediation transport. Serve non-secret project/account metadata and credential placeholders from the live provider state, without moving real credentials into the sandbox.

   Scope

   • crates/openshell-core/src/google_cloud.rs and provider_credentials.rs: shared exact metadata destination and atomic reads of explicitly non-secret current configuration.
   • crates/openshell-sandbox/src/network_broker.rs: mediate metadata TCP before ordinary loopback routing.
   • crates/openshell-supervisor-network/src/google_cloud_metadata.rs, lib.rs, proxy.rs: restore handler and dispatch direct/forward metadata requests locally with identity verification and bounded parsing.
   • e2e/python/: exercise Google SDK discovery through an attached provider with synthetic credentials.
   • docs/how-it-works/providers/google.mdx and related policy skill: document Linux runtime support and the reserved endpoint.

   Implementation Steps

   1. Restore the handler and its response/security/expiry coverage in the supervisor.
   2. Connect sandbox broker routing to supervisor dispatch; verify identity, local termination, and malformed/oversized/slow requests.
   3. Add Google SDK discovery coverage and update documentation.
   4. Run focused tests, repository checks, and the relevant Docker E2E lane before committing and creating a PR.

   Test Plan

   • Unit: metadata responses, header validation, placeholder isolation, expiry, credential refresh/removal, non-secret classification, configured-email aliases, exact destination matching.
   • Integration: broker relay versus ordinary loopback, supplied identity rejection, raw HTTP/forward dispatch and request bounds.
   • E2E: Python google-auth metadata discovery and repeated refresh using synthetic credentials, plus a 503 when credentials lack a binding. The test runs in the existing Docker Python CI lane; local validation uses the available Podman runtime.

   Risks & Open Questions

   • The reserved loopback destination can no longer target a workload-owned listener.
   • Actual cloud metadata destinations remain blocked. SDKs use injected discovery environment variables.
   • Windows/MXC support is outside this restoration's Linux mediation contract.
   • PR refactor(providers)!: declare imported profile behavior safely #3775's platform adapter schema is absent from current main; do not introduce its unfinished schema here.
   • No LSM or gateway TOML changes are expected. Existing trusted executable identity checks remain in force.

   Documentation Impact

   Update provider docs to describe supervisor mediation and supported runtimes; review related skills using the sync-agent-infra maintenance map.

   ---

   Revision 2 — preserve current config classification, support repeated SDK refresh, and use Podman for local E2E validation
   Revision 1 — initial plan
6. feloy commented on Sep 30, 2026

   

   feloy

   on Sep 30, 2026

   ContributorAuthor

   More actions

   🏗️ build-from-issue-agent

   Implementation Complete

   PR: #3973

   Restored the supervisor-owned GCP metadata emulator through the existing authenticated network relay. Project/account discovery and token placeholders use current provider state; repeated SDK refresh works through the configured account alias.

   Tests

   • 21 metadata handler tests restored/added, one exact-destination test, and six proxy/broker integration tests.
   • Added Google SDK ADC discovery and repeated-refresh E2E coverage; extended the unbound-provider test to require HTTP 503.
   • mise run pre-commit and mise run ci passed.
   • Podman provider E2E: 18 passed, 0 skipped (134.02s).
   • Manual Podman metadata probe succeeded with an explicit credential binding.
   • Linux-only broker unit tests await Linux execution; macOS E2E exercised the Linux broker in Podman.

   Docs updated

   • docs/how-it-works/providers/google.mdx
   • skills/generate-sandbox-policy/SKILL.md

   The issue will auto-close when the PR is merged.
7. johntmyers

   closed this as completedin #3973on Oct 2, 2026
8. ItsRoy69

   added a commit that references this issue on Oct 2, 2026

   fix(providers): restore supervisor-backed GCP metadata discovery (NVI…

   ...

   This issue will close once commit f7273e4 is merged into the 'main' branch.

   f7273e4
9. wseaton

   added a commit that references this issue on Oct 7, 2026

   fix(providers): restore supervisor-backed GCP metadata discovery (NVI…

   ...

   This issue will close once commit 46dcbe0 is merged into the 'main' branch.

   46dcbe0