feat(config): load identity blob from GCP Secret Manager

[keanji-x]

Summary

Adds a GCP Secret Manager source for the validator identity blob alongside the existing on-disk file source. Secret payload is the same YAML bytes as the on-disk IdentityBlob, so the ops change is just uploading the existing identity file to Secret Manager instead of mounting it on the VM.

Two parallel enum variants:

• Identity::FromGcpSecret (network / validator-network identity)
• InitialSafetyRulesConfig::FromGcpSecret (consensus identity incl. BLS key + overrides)

Both carry a projects/<P>/secrets/<S>/versions/<V> resource path (short form without /versions/<V> defaults to latest). Fetch happens once at startup through the same identity_blob() / identity_key() / peer_id() call sites, so downstream consensus/network code is untouched.

Pilot test (GCE VM, single-node cluster)

Verified end-to-end on gravity-mainnet-node-la-0:

• Built gravity_node with --features gcp-secret-manager, deployed single-node cluster via cluster/ scripts
• Uploaded a fresh identity.yaml to Secret Manager (gravity-sm-pilot-identity)
• validator.yaml rendered with from_gcp_secret in all three identity slots (safety_rules, validator_network, full_node_networks)
• Node loaded identity.yaml via HTTPS fetch from SM (GCP_ACCESS_TOKEN fallback since VM has no bound SA)
• ValidatorSet account_address exactly matched the SM-uploaded identity
• make start → block production reached epoch 2 round ~2800 (19 blocks in 10s)
• Zero identity.yaml on disk in the node's config directory

Config

full_node_networks:
  - identity:
      type: from_gcp_secret
      resource: projects/my-proj/secrets/validator-identity/versions/latest

consensus:
  safety_rules:
    initial_safety_rules_config:
      from_gcp_secret:
        identity_blob_secret: projects/my-proj/secrets/validator-identity/versions/latest
        overriding_identity_secrets: []
        waypoint: { from_config: "0:abc..." }

Auth

Picked in order:

1. GCP_ACCESS_TOKEN env var — escape hatch for non-GCE dev/CI (e.g. export GCP_ACCESS_TOKEN=$(gcloud auth print-access-token)).
2. GCE metadata server — zero-config on GCE VMs/GKE pods with a bound service account that has roles/secretmanager.secretAccessor and the VM is created with --scopes=cloud-platform.

Deliberately does not pull google-cloud-auth (async, drags tonic/tokio) into aptos-config — the crate today has no async deps. Reuses reqwest + base64 which are already workspace deps.

Hardening commits

1. Cargo feature gcp-secret-manager (off by default). reqwest and base64 are optional = true in aptos-config. Binaries that only load identity from disk no longer transitively link the HTTP/TLS stack through aptos-config. Forwarding feature gaptos/gcp-secret-manager is exposed for downstream crates.
2. Per-process fetch cache keyed by normalized resource path so NetworkConfig::identity_key + NetworkConfig::peer_id + safety_rules don't each issue their own metadata_token + secretmanager.access round-trip at startup.
3. Resource name in load-failure messages. Bare .unwrap() becomes unwrap_or_else with a panic message that includes the GCP resource; safety_rules_config.rs adds .with_context on the two call sites.

Scope boundaries

• aptos-genesis/builder.rs still uses Identity::from_file — genesis/keygen writes the YAML locally, then ops uploads it to Secret Manager. No reason to read from GCP during genesis.
• Does not replace IdentityBlob::to_file (still used by keygen).
• Does not touch safety_rules OnDiskStorage (BLS consensus key still materializes to secure_storage.json at first boot). That's a separate concern to address via SecureBackend::Vault or a new GcpSecret backend — out of scope here.
• Does not touch gravity_cli/signer GCP KMS signer — that's EVM secp256k1 signing, orthogonal to the identity blob (which carries x25519 / Ed25519 / BLS12-381).

Test plan

• cargo check -p aptos-config (no feature) — 0 new warnings
• cargo check -p aptos-config --features gcp-secret-manager — 0 new warnings
• cargo check -p aptos-safety-rules — clean (with and without smoke-test feature)
• cargo test -p aptos-config --lib gcp_secret — 3/3 pass (normalize_* unit tests)
• End-to-end on GCE VM with single-node cluster producing blocks

Companion PRs (ordered merge)

1. This PR (gravity-aptos)
2. gravity-reth: bump gravity-api-types pin to match this PR's merge SHA — prevents dual api-types in downstream graph (PipeExecLayerApi impl ConfigStorage trait mismatch). Will be opened after this merges.
3. gravity-sdk [Storage] Rename config default_prune_window -> ledger_prune_window aptos-labs/aptos-core#688: bumps gaptos + greth revs, adds cluster.toml identity = { source = "gcp_secret" } support and deploy.sh rendering.

🤖 Generated with Claude Code