[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6994XKND3D0Z2KEYSH513MC":3,"skill-same:01M6994XKND3D0Z2KEYSH513MC":83},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":23,"publishedAt":46,"linkOnly":47,"markdownContent":48,"markdownBody":49,"frontMatter":50,"refName":54,"commitSha":55,"skillDirectory":56,"forksCount":57,"repositoryHtmlUrl":58,"repositoryHomepageUrl":6,"ownerHtmlUrl":59,"ownerBlogUrl":60,"ownerDescription":61,"updatedAt":62,"install":63,"resources":76},"01M6994XKND3D0Z2KEYSH513MC","gke-workload-identity",null,"Configures and diagnoses Workload Identity Federation for GKE authentication failures for Pods (403 \"iam.serviceAccounts.getAccessToken\" \u002F permission denied, \"could not find default credentials\", or GKE metadata server unreachable) by verifying cluster and node-pool Workload Identity configuration, the Kubernetes ServiceAccount (KSA) to IAM binding (direct principal binding and legacy Google ServiceAccount impersonation), target-resource IAM roles, and gke-metadata-server health. Use when setting up KSA\u002FGSA bindings (`roles\u002Fiam.workloadIdentityUser`, `iam.gke.io\u002Fgcp-service-account`) or when a Pod cannot authenticate to Google Cloud APIs. Don't use for in-cluster Kubernetes RBAC errors (API-server authorization), general workload crashes (use gke-workload-troubleshooting), or Pod Security Standards and NetworkPolicies (use gke-workload-security).","google\u002Fskills","google","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F1342004?v=4","01M698VYEFDM0VJBZDYYJ2T83S","Google","01M698WR0H76ENHE587T9EJT89",24122,"Apache-2.0","https:\u002F\u002Fgithub.com\u002Fgoogle\u002Fskills\u002Fblob\u002Fmain\u002Fskills\u002Fcloud\u002Fgke-workload-identity\u002FSKILL.md",[18],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000010","后端与接口","SCENARIO","使用场景",[24,25,26,27,28,9,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45],"gke workload identity","identity","workload","gke","denied","when","unreachable","server health","api-server","errors","security standards","io","default","up","api","iam","gcp","server","authentication","security","google cloud","kubernetes","2026-11-10 10:12:30",false,"---\nname: gke-workload-identity\nmetadata:\n  version: \"1.0.2\"\n  category: Security\ndescription: >-\n  Configures and diagnoses Workload Identity Federation for GKE authentication failures for Pods\n  (403 \"iam.serviceAccounts.getAccessToken\" \u002F permission denied, \"could not find\n  default credentials\", or GKE metadata server unreachable) by verifying\n  cluster and node-pool Workload Identity configuration, the Kubernetes\n  ServiceAccount (KSA) to IAM binding (direct principal binding and legacy Google\n  ServiceAccount impersonation), target-resource IAM roles, and gke-metadata-server\n  health. Use when setting up KSA\u002FGSA bindings (`roles\u002Fiam.workloadIdentityUser`,\n  `iam.gke.io\u002Fgcp-service-account`) or when a Pod cannot authenticate to Google Cloud APIs. Don't use for in-cluster\n  Kubernetes RBAC errors (API-server authorization), general workload crashes\n  (use gke-workload-troubleshooting), or Pod Security Standards and NetworkPolicies\n  (use gke-workload-security).\n---\n\n# GKE Workload Identity Federation Troubleshooting Skill\n\nUse this skill to systematically diagnose why a Pod using **Workload Identity\nFederation for GKE** cannot authenticate to Google Cloud APIs. Typical symptoms:\n\n-   `HTTP\u002F403 ... Permission 'iam.serviceAccounts.getAccessToken' denied on\n    resource`\n-   `google.auth.exceptions ... could not find default credentials` \u002F\n    `ComputeEngineCredentials cannot find the metadata server`\n-   API calls that unexpectedly use the node's default Compute Engine service\n    account instead of the workload's identity.\n\n## Attribution\n\n**MUST READ**: Before executing any `gcloud`, REST API, or MCP command, you\nMUST read [Usage Attribution](references\u002Fattribution.md). For commands executed\ndirectly in the terminal (never in generated scripts, Terraform, or user code),\nprefix `gcloud` with\n`CLOUDSDK_METRICS_REQUEST_ATTRIBUTION=\"agent-skills\u002F1.0 (skill:gke-workload-identity)\"`\nand append `agent-skills\u002F1.0 (skill:gke-workload-identity)` to `User-Agent` headers.\n\n## Read-only boundary\n\nThis skill is **diagnostic and non-interactive**. It only **reads** cluster,\nIAM, and logging state and **proposes** fixes as commands or GitOps manifest\nchanges for a human to apply. It must **never** create or modify IAM bindings,\nKSA annotations, node pools, or clusters automatically. When evidence is missing\nor the fix requires a privileged change, summarize findings and hand off to a\nhuman (see Step 7).\n\n## Output discipline (apply to every conclusion)\n\nWhen you report a diagnosis, always:\n\n1.  **Name the single most-likely root cause** (not an open-ended list of\n    possibilities).\n2.  **Explicitly rule out** the other plausible causes, citing the evidence that\n    excludes them. In particular, when the cause is node-pool configuration,\n    state plainly that it is **not** a KSA annotation or IAM binding problem;\n    when the cause is a missing role on a target resource, state that Workload\n    Identity itself is **not** misconfigured.\n3.  **Give the exact remediation as a proposed change for a human** — a concrete\n    `gcloud` command (or GitOps manifest edit) with the real identifiers filled\n    in — and never apply it automatically.\n\n--------------------------------------------------------------------------------\n\n## Diagnostic Workflow\n\n### Step 0: Context discovery & time window\n\nCollect (from the user or the failing resource): `PROJECT_ID`, `PROJECT_NUMBER`,\n`CLUSTER`, cluster `LOCATION`, `NAMESPACE`, the **KSA** the Pod runs as, the\n**node and node pool** the Pod is scheduled on (used in Step 2), the **target\nresource \u002F API** being called, and the **exact error string**. Define a time\nwindow around the first observed failure for log queries.\n\n```bash\n# Resolve the project number (used in the direct-binding principal identifier).\ngcloud projects describe \"{PROJECT_ID}\" --format=\"value(projectNumber)\"\n\n# Confirm which KSA the workload runs as.\nkubectl get pod \"{pod_name}\" -n \"{namespace}\" \\\n  -o jsonpath='{.spec.serviceAccountName}'\n\n# Identify the node the Pod runs on, then the node pool that node belongs to\n# (Step 2 checks the node pool's Workload Identity mode).\nNODE=$(kubectl get pod \"{pod_name}\" -n \"{namespace}\" -o jsonpath='{.spec.nodeName}')\nkubectl get node \"$NODE\" \\\n  -o jsonpath='{.metadata.labels.cloud\\.google\\.com\u002Fgke-nodepool}'\n```\n\n--------------------------------------------------------------------------------\n\n### Step 1: Capture the exact error signature\n\nRead the workload's own logs and the `gke-metadata-server` logs to classify the\nfailure.\n\n```bash\nkubectl logs \"{pod_name}\" -n \"{namespace}\" --all-containers --prefix\nkubectl describe pod \"{pod_name}\" -n \"{namespace}\"\n```\n\nEquivalent via Cloud Logging (preferred for historical events). Open it as a\n**Logs Explorer deep link** — URL-encode the query and append the project and\ntime window:\n`https:\u002F\u002Fconsole.cloud.google.com\u002Flogs\u002Fquery;query={URL_ENCODED_QUERY};timeRange={start}%2F{end}?project={project_id}`\n(encode `\u002F` as `%2F`, or use `;duration=PT1H` for a rolling hour):\n\n```\nresource.type=\"k8s_container\"\nresource.labels.namespace_name=\"{namespace}\"\nresource.labels.pod_name=\"{pod_name}\"\nseverity>=WARNING\n```\n\n**Classify the signature:**\n\n-   `iam.serviceAccounts.getAccessToken` denied \u002F `HTTP\u002F403` → the workload is\n    using the **GSA impersonation** path. This is expected for the legacy setup,\n    but if you intend to use **direct binding**, it means the KSA still carries\n    a leftover `iam.gke.io\u002Fgcp-service-account` annotation (or the client SDK is\n    configured to impersonate) and is unintentionally impersonating a GSA; go to\n    Step 3.\n-   `403 PERMISSION_DENIED` on the **target API\u002Fresource** (no `getAccessToken`\n    in the error) → the resolved identity lacks the required IAM role on that\n    resource; go to Step 4.\n-   `could not find default credentials` \u002F `cannot find the metadata server` →\n    metadata-server connectivity or a startup race; go to Step 5.\n-   Calls succeed but as the **node default service account** → Workload\n    Identity is not in effect for this node pool; go to Step 2.\n\n--------------------------------------------------------------------------------\n\n### Step 2: Verify Workload Identity is enabled (cluster + node pool)\n\nBoth the cluster and the **node pool the Pod runs on** must have Workload\nIdentity enabled. A node pool with `GCE_METADATA` (instead of `GKE_METADATA`)\ncauses Pods to fall back to the node's default Compute Engine service account.\n\n```bash\n# Cluster must have a workload identity pool (PROJECT_ID.svc.id.goog).\ngcloud container clusters describe \"{cluster}\" --location \"{location}\" \\\n  --format=\"value(workloadIdentityConfig.workloadPool)\"\n\n# Node pool must have workloadMetadataConfig.mode = GKE_METADATA.\ngcloud container node-pools describe \"{node_pool}\" --cluster \"{cluster}\" \\\n  --location \"{location}\" \\\n  --format=\"value(config.workloadMetadataConfig.mode)\"\n```\n\n-   Empty workload pool → Workload Identity is **not enabled on the cluster**.\n-   Node-pool mode is `GCE_METADATA` (or empty) → the node pool is **not** using\n    the GKE metadata server; this is the usual cause of \"runs as the node\n    default service account\". Remediation: enable\n    `--workload-metadata=GKE_METADATA` on the node pool (propose to a human;\n    recreates nodes). This is a **node-pool configuration** problem — not a KSA\n    annotation or IAM binding problem — so do not change KSA annotations or IAM\n    bindings to fix it. When the symptom is \"runs as the node default service\n    account\", say so explicitly: the root cause is the node pool's\n    `workloadMetadataConfig.mode`, and the KSA annotation and IAM bindings are\n    **ruled out** as the cause. Propose the exact fix, e.g.:\n\n```bash\ngcloud container node-pools update \"{node_pool}\" --cluster \"{cluster}\" \\\n  --location \"{location}\" --workload-metadata=GKE_METADATA\n```\n\n--------------------------------------------------------------------------------\n\n### Step 3: Verify the KSA → identity binding\n\nThere are two supported models. **Prefer direct binding** (current default);\ntreat GSA impersonation as the **legacy** path.\n\n> **How the two models fail differently:** with **direct binding** the KSA\n> principal accesses resources directly, so failures show up as a plain `403\n> PERMISSION_DENIED` on the target API (fix in Step 4). A `403\n> iam.serviceAccounts.getAccessToken` instead means an **impersonation** attempt\n> — intended under the legacy path, or *unintended* if a leftover\n> `iam.gke.io\u002Fgcp-service-account` annotation remains on a KSA that was meant to\n> use direct binding.\n\n**(a) Direct KSA binding (no GSA impersonation).** The KSA principal is granted\nroles directly. Construct the principal identifier and search for its bindings:\n\n```\nprincipal:\u002F\u002Fiam.googleapis.com\u002Fprojects\u002F{PROJECT_NUMBER}\u002Flocations\u002Fglobal\u002FworkloadIdentityPools\u002F{PROJECT_ID}.svc.id.goog\u002Fsubject\u002Fns\u002F{NAMESPACE}\u002Fsa\u002F{KSA_NAME}\n```\n\n**(b) Legacy: KSA + GSA impersonation.** The KSA must be annotated to point at a\nGSA, and the KSA must hold `roles\u002Fiam.workloadIdentityUser` on that GSA.\n\n```bash\n# The KSA annotation must reference the intended GSA.\nkubectl get serviceaccount \"{ksa_name}\" -n \"{namespace}\" \\\n  -o jsonpath='{.metadata.annotations.iam\\.gke\\.io\u002Fgcp-service-account}'\n\n# The GSA's IAM policy must bind the KSA member to workloadIdentityUser.\ngcloud iam service-accounts get-iam-policy \\\n  \"{gsa_name}@{project_id}.iam.gserviceaccount.com\" \\\n  --format=json\n# Expect a binding: role roles\u002Fiam.workloadIdentityUser,\n# member serviceAccount:{PROJECT_ID}.svc.id.goog[{NAMESPACE}\u002F{KSA_NAME}]\n```\n\n> If the annotation is present but the binding is missing, the binding was\n> likely removed — check the `setIamPolicy` audit logs around the failure time\n> to find the responsible principal.\n\n--------------------------------------------------------------------------------\n\n### Step 4: Verify IAM permissions on the target resource\n\nEven with a correct binding, the identity (the KSA principal for direct binding,\nor the GSA for legacy) must hold the role required by the API call (for example\n`roles\u002Fstorage.objectViewer`). The standard IAM Policy Troubleshooter has\nlimited support for Workload Identity principals; use Cloud Asset Inventory to\nsearch all IAM policies for the principal instead.\n\n```bash\n# Direct binding: search for the KSA principal's bindings across the project.\ngcloud asset search-all-iam-policies \\\n  --scope=\"projects\u002F{PROJECT_ID}\" \\\n  --query='policy:\"{PROJECT_ID}.svc.id.goog\"'\n\n# Legacy: search for the GSA's bindings on the target resource's project.\ngcloud asset search-all-iam-policies \\\n  --scope=\"projects\u002F{TARGET_PROJECT_ID}\" \\\n  --query='policy:\"{gsa_name}@{project_id}.iam.gserviceaccount.com\"'\n```\n\nIf no binding grants the required role on the target resource, **that missing\nrole is the root cause** (and Workload Identity itself is **not**\nmisconfigured). Present the fix as a **proposed change for a human to apply** —\nthe exact `add-iam-policy-binding` with the real principal and role — never\napplying it automatically. For example, for direct binding on a project-level\nresource:\n\n```bash\ngcloud projects add-iam-policy-binding \"{TARGET_PROJECT_ID}\" \\\n  --member=\"principal:\u002F\u002Fiam.googleapis.com\u002Fprojects\u002F{PROJECT_NUMBER}\u002Flocations\u002Fglobal\u002FworkloadIdentityPools\u002F{PROJECT_ID}.svc.id.goog\u002Fsubject\u002Fns\u002F{NAMESPACE}\u002Fsa\u002F{KSA_NAME}\" \\\n  --role=\"{REQUIRED_ROLE}\"   # e.g. roles\u002Fstorage.objectViewer\n```\n\n--------------------------------------------------------------------------------\n\n### Step 5: GKE metadata server & connectivity\n\nApplies when the signature is `could not find the metadata server`, `cannot find\nthe metadata server`, or a connection\u002Ftimeout error. The `gke-metadata-server`\nDaemonSet (in `kube-system`) brokers the token exchange on each node; requests\nto `169.254.169.254` are redirected to it, so a Pod fails closed if it cannot\nreach a healthy metadata-server Pod on its node.\n\n**(a) Check gke-metadata-server Pod health on the workload's node.**\n\n```bash\n# The DaemonSet Pods must be healthy on the workload's node.\nkubectl get pods -n kube-system -l k8s-app=gke-metadata-server -o wide\n\n# A gke-metadata-server Pod can be OOM-evicted when the cluster has many\n# (>3,000) Kubernetes service accounts. Look for CrashLoopBackOff, then confirm\n# the eviction was OOMKilled.\nkubectl get pods -n kube-system | grep CrashLoopBackOff\nkubectl describe pod {gke_metadata_server_pod} --namespace=kube-system | grep OOMKilled\n```\n\n**(b) Inspect the `gke-metadata-server` logs** (historical, via Cloud Logging;\nopen as a Logs Explorer deep link, see Step 1):\n\n```\nresource.type=\"k8s_container\"\nresource.labels.namespace_name=\"kube-system\"\nlabels.\"k8s-pod\u002Fk8s-app\"=\"gke-metadata-server\"\nseverity>=WARNING\n```\n\n**(c) Connectivity test** from the affected Pod — it must reach the metadata\nserver and (for some client libraries) resolve its DNS name:\n\n```bash\n# Token endpoint via the hardcoded metadata IP (a healthy path returns a token).\nkubectl exec {pod_name} -n {namespace} -- \\\n  curl -sS -H 'Metadata-Flavor: Google' \\\n  'http:\u002F\u002F169.254.169.254\u002FcomputeMetadata\u002Fv1\u002Finstance\u002Fservice-accounts\u002Fdefault\u002Ftoken'\n```\n\nPossible causes:\n\n-   **Startup race**: the metadata server needs a few seconds after a Pod\n    starts. Applications that authenticate immediately may fail; the fix is\n    application-side retries or an `initContainer` that waits for the metadata\n    server, not a cluster change.\n-   **DNS**: some client libraries resolve `metadata.google.internal`; broken\n    in-cluster DNS surfaces as `cannot find the metadata server`. As a\n    workaround, set `GCE_METADATA_HOST=169.254.169.254` to skip DNS resolution.\n-   **Network policy \u002F egress**: a cluster network policy must allow egress to\n    `169.254.169.254\u002F32` on port `80` (GKE Dataplane V2), or\n    `169.254.169.252\u002F32` on port `988`. A default-deny egress rule that blocks\n    HTTPS to the public Security Token Service (`sts.googleapis.com:443`)\n    produces `504 Gateway Timeout` or `context deadline exceeded`.\n-   **`gke-metadata-server` crashing \u002F high restarts**: see (a) — reduce the\n    number of Kubernetes service accounts (\u003C3,000) to restore functionality.\n\n--------------------------------------------------------------------------------\n\n### Step 6: \"Invalid form of account ID\" edge case (legacy GSA impersonation)\n\n> **Applies only to the legacy GSA impersonation setup** (a KSA annotated with\n> `iam.gke.io\u002Fgcp-service-account`), not to direct principal binding.\n\nSignature: an operation that requires an IAM **service account email** (for\nexample, manually creating a Cloud Storage signed URL) fails with:\n\n```\nERROR: Invalid form of account ID SERVICEACCOUNT_NAME.svc.id.goog.\nShould be [Gaia ID | Email | Unique ID | ] of the account\n```\n\nCause: for a KSA linked to a GSA via annotation, the GKE metadata server by\ndefault returns `SERVICEACCOUNT_NAME.svc.id.goog` as the identifier, which is\nnot a valid IAM service account email. This is **not** a missing IAM binding and\ndoes **not** require reverting the setup.\n\nFix (propose to a human): add the\n`iam.gke.io\u002Freturn-principal-id-as-email=\"true\"` annotation to the Pod's KSA so\nthe metadata server returns the identity in the expected form:\n\n```bash\nkubectl annotate serviceaccount \"{ksa_name}\" --namespace \"{namespace}\" \\\n  iam.gke.io\u002Freturn-principal-id-as-email=\"true\"\n```\n\n--------------------------------------------------------------------------------\n\n### Step 7: Remediation boundary & escalation\n\n-   Present the **root cause + evidence** (the exact error, the missing binding\n    \u002F annotation \u002F node-pool mode, or the metadata-server state). Include a\n    **Cloud Logging deep link** (see Step 1) to the supporting entries.\n-   Propose the fix as a **command or GitOps manifest change** for a human to\n    apply — never modify IAM, KSAs, or node pools automatically.\n\n**Escalate** (instead of proposing more self-service diagnostics) when either:\n\n-   the relevant logs are **unavailable** (excluded by a filter, or past the log\n    bucket's retention); or\n-   the identity\u002Fbinding is correct, the target-resource IAM is correct, and the\n    metadata server is healthy, yet the failure persists (undetermined root\n    cause).\n\nIn those cases: state the limitation plainly, summarize the findings gathered\n(cluster\u002Fnode-pool config, bindings, annotations, metadata-server state, and any\n`setIamPolicy` audit logs), and route to GKE support \u002F engineering escalation.\nDo **not** fabricate a diagnosis when evidence is missing.\n\n--------------------------------------------------------------------------------\n\n## References\n\nThis skill is derived from public Google Cloud documentation:\n\n-   [Troubleshoot GKE authentication issues](https:\u002F\u002Fdocs.cloud.google.com\u002Fkubernetes-engine\u002Fdocs\u002Ftroubleshooting\u002Fauthentication.md.txt)\n    — the Workload Identity Federation section: WI-enabled check, KSA\n    annotation, `roles\u002Fiam.workloadIdentityUser`,\n    `iam.serviceAccounts.getAccessToken` 403,\n    `iam.gke.io\u002Freturn-principal-id-as-email`, metadata-server DNS and the\n    [`gke-metadata-server` Pod is crashing](https:\u002F\u002Fdocs.cloud.google.com\u002Fkubernetes-engine\u002Fdocs\u002Ftroubleshooting\u002Fauthentication.md.txt#metadata-server-crashes)\n    guidance.\n-   [About Workload Identity Federation for GKE](https:\u002F\u002Fdocs.cloud.google.com\u002Fkubernetes-engine\u002Fdocs\u002Fconcepts\u002Fworkload-identity.md.txt)\n    — identities, the GKE metadata server, and why Pods don't inherit the node\n    identity.\n-   [Configure applications to use Workload Identity Federation for GKE](https:\u002F\u002Fdocs.cloud.google.com\u002Fkubernetes-engine\u002Fdocs\u002Fhow-to\u002Fworkload-identity.md.txt)\n    — node-pool `--workload-metadata=GKE_METADATA`, the direct-binding\n    `principal:\u002F\u002F...` identifier, and the legacy\n    `serviceAccount:PROJECT_ID.svc.id.goog[NAMESPACE\u002FKSA_NAME]` member format.\n-   [Search IAM policies (Cloud Asset Inventory)](https:\u002F\u002Fcloud.google.com\u002Fasset-inventory\u002Fdocs\u002Fsearching-iam-policies)\n    — `gcloud asset search-all-iam-policies` for auditing a principal's\n    bindings.\n-   [View GKE logs](https:\u002F\u002Fdocs.cloud.google.com\u002Fkubernetes-engine\u002Fdocs\u002Fhow-to\u002Fview-logs.md.txt)\n    — Cloud Logging queries for workload and system logs.\n","# GKE Workload Identity Federation Troubleshooting Skill\n\nUse this skill to systematically diagnose why a Pod using **Workload Identity\nFederation for GKE** cannot authenticate to Google Cloud APIs. Typical symptoms:\n\n-   `HTTP\u002F403 ... Permission 'iam.serviceAccounts.getAccessToken' denied on\n    resource`\n-   `google.auth.exceptions ... could not find default credentials` \u002F\n    `ComputeEngineCredentials cannot find the metadata server`\n-   API calls that unexpectedly use the node's default Compute Engine service\n    account instead of the workload's identity.\n\n## Attribution\n\n**MUST READ**: Before executing any `gcloud`, REST API, or MCP command, you\nMUST read [Usage Attribution](references\u002Fattribution.md). For commands executed\ndirectly in the terminal (never in generated scripts, Terraform, or user code),\nprefix `gcloud` with\n`CLOUDSDK_METRICS_REQUEST_ATTRIBUTION=\"agent-skills\u002F1.0 (skill:gke-workload-identity)\"`\nand append `agent-skills\u002F1.0 (skill:gke-workload-identity)` to `User-Agent` headers.\n\n## Read-only boundary\n\nThis skill is **diagnostic and non-interactive**. It only **reads** cluster,\nIAM, and logging state and **proposes** fixes as commands or GitOps manifest\nchanges for a human to apply. It must **never** create or modify IAM bindings,\nKSA annotations, node pools, or clusters automatically. When evidence is missing\nor the fix requires a privileged change, summarize findings and hand off to a\nhuman (see Step 7).\n\n## Output discipline (apply to every conclusion)\n\nWhen you report a diagnosis, always:\n\n1.  **Name the single most-likely root cause** (not an open-ended list of\n    possibilities).\n2.  **Explicitly rule out** the other plausible causes, citing the evidence that\n    excludes them. In particular, when the cause is node-pool configuration,\n    state plainly that it is **not** a KSA annotation or IAM binding problem;\n    when the cause is a missing role on a target resource, state that Workload\n    Identity itself is **not** misconfigured.\n3.  **Give the exact remediation as a proposed change for a human** — a concrete\n    `gcloud` command (or GitOps manifest edit) with the real identifiers filled\n    in — and never apply it automatically.\n\n--------------------------------------------------------------------------------\n\n## Diagnostic Workflow\n\n### Step 0: Context discovery & time window\n\nCollect (from the user or the failing resource): `PROJECT_ID`, `PROJECT_NUMBER`,\n`CLUSTER`, cluster `LOCATION`, `NAMESPACE`, the **KSA** the Pod runs as, the\n**node and node pool** the Pod is scheduled on (used in Step 2), the **target\nresource \u002F API** being called, and the **exact error string**. Define a time\nwindow around the first observed failure for log queries.\n\n```bash\n# Resolve the project number (used in the direct-binding principal identifier).\ngcloud projects describe \"{PROJECT_ID}\" --format=\"value(projectNumber)\"\n\n# Confirm which KSA the workload runs as.\nkubectl get pod \"{pod_name}\" -n \"{namespace}\" \\\n  -o jsonpath='{.spec.serviceAccountName}'\n\n# Identify the node the Pod runs on, then the node pool that node belongs to\n# (Step 2 checks the node pool's Workload Identity mode).\nNODE=$(kubectl get pod \"{pod_name}\" -n \"{namespace}\" -o jsonpath='{.spec.nodeName}')\nkubectl get node \"$NODE\" \\\n  -o jsonpath='{.metadata.labels.cloud\\.google\\.com\u002Fgke-nodepool}'\n```\n\n--------------------------------------------------------------------------------\n\n### Step 1: Capture the exact error signature\n\nRead the workload's own logs and the `gke-metadata-server` logs to classify the\nfailure.\n\n```bash\nkubectl logs \"{pod_name}\" -n \"{namespace}\" --all-containers --prefix\nkubectl describe pod \"{pod_name}\" -n \"{namespace}\"\n```\n\nEquivalent via Cloud Logging (preferred for historical events). Open it as a\n**Logs Explorer deep link** — URL-encode the query and append the project and\ntime window:\n`https:\u002F\u002Fconsole.cloud.google.com\u002Flogs\u002Fquery;query={URL_ENCODED_QUERY};timeRange={start}%2F{end}?project={project_id}`\n(encode `\u002F` as `%2F`, or use `;duration=PT1H` for a rolling hour):\n\n```\nresource.type=\"k8s_container\"\nresource.labels.namespace_name=\"{namespace}\"\nresource.labels.pod_name=\"{pod_name}\"\nseverity>=WARNING\n```\n\n**Classify the signature:**\n\n-   `iam.serviceAccounts.getAccessToken` denied \u002F `HTTP\u002F403` → the workload is\n    using the **GSA impersonation** path. This is expected for the legacy setup,\n    but if you intend to use **direct binding**, it means the KSA still carries\n    a leftover `iam.gke.io\u002Fgcp-service-account` annotation (or the client SDK is\n    configured to impersonate) and is unintentionally impersonating a GSA; go to\n    Step 3.\n-   `403 PERMISSION_DENIED` on the **target API\u002Fresource** (no `getAccessToken`\n    in the error) → the resolved identity lacks the required IAM role on that\n    resource; go to Step 4.\n-   `could not find default credentials` \u002F `cannot find the metadata server` →\n    metadata-server connectivity or a startup race; go to Step 5.\n-   Calls succeed but as the **node default service account** → Workload\n    Identity is not in effect for this node pool; go to Step 2.\n\n--------------------------------------------------------------------------------\n\n### Step 2: Verify Workload Identity is enabled (cluster + node pool)\n\nBoth the cluster and the **node pool the Pod runs on** must have Workload\nIdentity enabled. A node pool with `GCE_METADATA` (instead of `GKE_METADATA`)\ncauses Pods to fall back to the node's default Compute Engine service account.\n\n```bash\n# Cluster must have a workload identity pool (PROJECT_ID.svc.id.goog).\ngcloud container clusters describe \"{cluster}\" --location \"{location}\" \\\n  --format=\"value(workloadIdentityConfig.workloadPool)\"\n\n# Node pool must have workloadMetadataConfig.mode = GKE_METADATA.\ngcloud container node-pools describe \"{node_pool}\" --cluster \"{cluster}\" \\\n  --location \"{location}\" \\\n  --format=\"value(config.workloadMetadataConfig.mode)\"\n```\n\n-   Empty workload pool → Workload Identity is **not enabled on the cluster**.\n-   Node-pool mode is `GCE_METADATA` (or empty) → the node pool is **not** using\n    the GKE metadata server; this is the usual cause of \"runs as the node\n    default service account\". Remediation: enable\n    `--workload-metadata=GKE_METADATA` on the node pool (propose to a human;\n    recreates nodes). This is a **node-pool configuration** problem — not a KSA\n    annotation or IAM binding problem — so do not change KSA annotations or IAM\n    bindings to fix it. When the symptom is \"runs as the node default service\n    account\", say so explicitly: the root cause is the node pool's\n    `workloadMetadataConfig.mode`, and the KSA annotation and IAM bindings are\n    **ruled out** as the cause. Propose the exact fix, e.g.:\n\n```bash\ngcloud container node-pools update \"{node_pool}\" --cluster \"{cluster}\" \\\n  --location \"{location}\" --workload-metadata=GKE_METADATA\n```\n\n--------------------------------------------------------------------------------\n\n### Step 3: Verify the KSA → identity binding\n\nThere are two supported models. **Prefer direct binding** (current default);\ntreat GSA impersonation as the **legacy** path.\n\n> **How the two models fail differently:** with **direct binding** the KSA\n> principal accesses resources directly, so failures show up as a plain `403\n> PERMISSION_DENIED` on the target API (fix in Step 4). A `403\n> iam.serviceAccounts.getAccessToken` instead means an **impersonation** attempt\n> — intended under the legacy path, or *unintended* if a leftover\n> `iam.gke.io\u002Fgcp-service-account` annotation remains on a KSA that was meant to\n> use direct binding.\n\n**(a) Direct KSA binding (no GSA impersonation).** The KSA principal is granted\nroles directly. Construct the principal identifier and search for its bindings:\n\n```\nprincipal:\u002F\u002Fiam.googleapis.com\u002Fprojects\u002F{PROJECT_NUMBER}\u002Flocations\u002Fglobal\u002FworkloadIdentityPools\u002F{PROJECT_ID}.svc.id.goog\u002Fsubject\u002Fns\u002F{NAMESPACE}\u002Fsa\u002F{KSA_NAME}\n```\n\n**(b) Legacy: KSA + GSA impersonation.** The KSA must be annotated to point at a\nGSA, and the KSA must hold `roles\u002Fiam.workloadIdentityUser` on that GSA.\n\n```bash\n# The KSA annotation must reference the intended GSA.\nkubectl get serviceaccount \"{ksa_name}\" -n \"{namespace}\" \\\n  -o jsonpath='{.metadata.annotations.iam\\.gke\\.io\u002Fgcp-service-account}'\n\n# The GSA's IAM policy must bind the KSA member to workloadIdentityUser.\ngcloud iam service-accounts get-iam-policy \\\n  \"{gsa_name}@{project_id}.iam.gserviceaccount.com\" \\\n  --format=json\n# Expect a binding: role roles\u002Fiam.workloadIdentityUser,\n# member serviceAccount:{PROJECT_ID}.svc.id.goog[{NAMESPACE}\u002F{KSA_NAME}]\n```\n\n> If the annotation is present but the binding is missing, the binding was\n> likely removed — check the `setIamPolicy` audit logs around the failure time\n> to find the responsible principal.\n\n--------------------------------------------------------------------------------\n\n### Step 4: Verify IAM permissions on the target resource\n\nEven with a correct binding, the identity (the KSA principal for direct binding,\nor the GSA for legacy) must hold the role required by the API call (for example\n`roles\u002Fstorage.objectViewer`). The standard IAM Policy Troubleshooter has\nlimited support for Workload Identity principals; use Cloud Asset Inventory to\nsearch all IAM policies for the principal instead.\n\n```bash\n# Direct binding: search for the KSA principal's bindings across the project.\ngcloud asset search-all-iam-policies \\\n  --scope=\"projects\u002F{PROJECT_ID}\" \\\n  --query='policy:\"{PROJECT_ID}.svc.id.goog\"'\n\n# Legacy: search for the GSA's bindings on the target resource's project.\ngcloud asset search-all-iam-policies \\\n  --scope=\"projects\u002F{TARGET_PROJECT_ID}\" \\\n  --query='policy:\"{gsa_name}@{project_id}.iam.gserviceaccount.com\"'\n```\n\nIf no binding grants the required role on the target resource, **that missing\nrole is the root cause** (and Workload Identity itself is **not**\nmisconfigured). Present the fix as a **proposed change for a human to apply** —\nthe exact `add-iam-policy-binding` with the real principal and role — never\napplying it automatically. For example, for direct binding on a project-level\nresource:\n\n```bash\ngcloud projects add-iam-policy-binding \"{TARGET_PROJECT_ID}\" \\\n  --member=\"principal:\u002F\u002Fiam.googleapis.com\u002Fprojects\u002F{PROJECT_NUMBER}\u002Flocations\u002Fglobal\u002FworkloadIdentityPools\u002F{PROJECT_ID}.svc.id.goog\u002Fsubject\u002Fns\u002F{NAMESPACE}\u002Fsa\u002F{KSA_NAME}\" \\\n  --role=\"{REQUIRED_ROLE}\"   # e.g. roles\u002Fstorage.objectViewer\n```\n\n--------------------------------------------------------------------------------\n\n### Step 5: GKE metadata server & connectivity\n\nApplies when the signature is `could not find the metadata server`, `cannot find\nthe metadata server`, or a connection\u002Ftimeout error. The `gke-metadata-server`\nDaemonSet (in `kube-system`) brokers the token exchange on each node; requests\nto `169.254.169.254` are redirected to it, so a Pod fails closed if it cannot\nreach a healthy metadata-server Pod on its node.\n\n**(a) Check gke-metadata-server Pod health on the workload's node.**\n\n```bash\n# The DaemonSet Pods must be healthy on the workload's node.\nkubectl get pods -n kube-system -l k8s-app=gke-metadata-server -o wide\n\n# A gke-metadata-server Pod can be OOM-evicted when the cluster has many\n# (>3,000) Kubernetes service accounts. Look for CrashLoopBackOff, then confirm\n# the eviction was OOMKilled.\nkubectl get pods -n kube-system | grep CrashLoopBackOff\nkubectl describe pod {gke_metadata_server_pod} --namespace=kube-system | grep OOMKilled\n```\n\n**(b) Inspect the `gke-metadata-server` logs** (historical, via Cloud Logging;\nopen as a Logs Explorer deep link, see Step 1):\n\n```\nresource.type=\"k8s_container\"\nresource.labels.namespace_name=\"kube-system\"\nlabels.\"k8s-pod\u002Fk8s-app\"=\"gke-metadata-server\"\nseverity>=WARNING\n```\n\n**(c) Connectivity test** from the affected Pod — it must reach the metadata\nserver and (for some client libraries) resolve its DNS name:\n\n```bash\n# Token endpoint via the hardcoded metadata IP (a healthy path returns a token).\nkubectl exec {pod_name} -n {namespace} -- \\\n  curl -sS -H 'Metadata-Flavor: Google' \\\n  'http:\u002F\u002F169.254.169.254\u002FcomputeMetadata\u002Fv1\u002Finstance\u002Fservice-accounts\u002Fdefault\u002Ftoken'\n```\n\nPossible causes:\n\n-   **Startup race**: the metadata server needs a few seconds after a Pod\n    starts. Applications that authenticate immediately may fail; the fix is\n    application-side retries or an `initContainer` that waits for the metadata\n    server, not a cluster change.\n-   **DNS**: some client libraries resolve `metadata.google.internal`; broken\n    in-cluster DNS surfaces as `cannot find the metadata server`. As a\n    workaround, set `GCE_METADATA_HOST=169.254.169.254` to skip DNS resolution.\n-   **Network policy \u002F egress**: a cluster network policy must allow egress to\n    `169.254.169.254\u002F32` on port `80` (GKE Dataplane V2), or\n    `169.254.169.252\u002F32` on port `988`. A default-deny egress rule that blocks\n    HTTPS to the public Security Token Service (`sts.googleapis.com:443`)\n    produces `504 Gateway Timeout` or `context deadline exceeded`.\n-   **`gke-metadata-server` crashing \u002F high restarts**: see (a) — reduce the\n    number of Kubernetes service accounts (\u003C3,000) to restore functionality.\n\n--------------------------------------------------------------------------------\n\n### Step 6: \"Invalid form of account ID\" edge case (legacy GSA impersonation)\n\n> **Applies only to the legacy GSA impersonation setup** (a KSA annotated with\n> `iam.gke.io\u002Fgcp-service-account`), not to direct principal binding.\n\nSignature: an operation that requires an IAM **service account email** (for\nexample, manually creating a Cloud Storage signed URL) fails with:\n\n```\nERROR: Invalid form of account ID SERVICEACCOUNT_NAME.svc.id.goog.\nShould be [Gaia ID | Email | Unique ID | ] of the account\n```\n\nCause: for a KSA linked to a GSA via annotation, the GKE metadata server by\ndefault returns `SERVICEACCOUNT_NAME.svc.id.goog` as the identifier, which is\nnot a valid IAM service account email. This is **not** a missing IAM binding and\ndoes **not** require reverting the setup.\n\nFix (propose to a human): add the\n`iam.gke.io\u002Freturn-principal-id-as-email=\"true\"` annotation to the Pod's KSA so\nthe metadata server returns the identity in the expected form:\n\n```bash\nkubectl annotate serviceaccount \"{ksa_name}\" --namespace \"{namespace}\" \\\n  iam.gke.io\u002Freturn-principal-id-as-email=\"true\"\n```\n\n--------------------------------------------------------------------------------\n\n### Step 7: Remediation boundary & escalation\n\n-   Present the **root cause + evidence** (the exact error, the missing binding\n    \u002F annotation \u002F node-pool mode, or the metadata-server state). Include a\n    **Cloud Logging deep link** (see Step 1) to the supporting entries.\n-   Propose the fix as a **command or GitOps manifest change** for a human to\n    apply — never modify IAM, KSAs, or node pools automatically.\n\n**Escalate** (instead of proposing more self-service diagnostics) when either:\n\n-   the relevant logs are **unavailable** (excluded by a filter, or past the log\n    bucket's retention); or\n-   the identity\u002Fbinding is correct, the target-resource IAM is correct, and the\n    metadata server is healthy, yet the failure persists (undetermined root\n    cause).\n\nIn those cases: state the limitation plainly, summarize the findings gathered\n(cluster\u002Fnode-pool config, bindings, annotations, metadata-server state, and any\n`setIamPolicy` audit logs), and route to GKE support \u002F engineering escalation.\nDo **not** fabricate a diagnosis when evidence is missing.\n\n--------------------------------------------------------------------------------\n\n## References\n\nThis skill is derived from public Google Cloud documentation:\n\n-   [Troubleshoot GKE authentication issues](https:\u002F\u002Fdocs.cloud.google.com\u002Fkubernetes-engine\u002Fdocs\u002Ftroubleshooting\u002Fauthentication.md.txt)\n    — the Workload Identity Federation section: WI-enabled check, KSA\n    annotation, `roles\u002Fiam.workloadIdentityUser`,\n    `iam.serviceAccounts.getAccessToken` 403,\n    `iam.gke.io\u002Freturn-principal-id-as-email`, metadata-server DNS and the\n    [`gke-metadata-server` Pod is crashing](https:\u002F\u002Fdocs.cloud.google.com\u002Fkubernetes-engine\u002Fdocs\u002Ftroubleshooting\u002Fauthentication.md.txt#metadata-server-crashes)\n    guidance.\n-   [About Workload Identity Federation for GKE](https:\u002F\u002Fdocs.cloud.google.com\u002Fkubernetes-engine\u002Fdocs\u002Fconcepts\u002Fworkload-identity.md.txt)\n    — identities, the GKE metadata server, and why Pods don't inherit the node\n    identity.\n-   [Configure applications to use Workload Identity Federation for GKE](https:\u002F\u002Fdocs.cloud.google.com\u002Fkubernetes-engine\u002Fdocs\u002Fhow-to\u002Fworkload-identity.md.txt)\n    — node-pool `--workload-metadata=GKE_METADATA`, the direct-binding\n    `principal:\u002F\u002F...` identifier, and the legacy\n    `serviceAccount:PROJECT_ID.svc.id.goog[NAMESPACE\u002FKSA_NAME]` member format.\n-   [Search IAM policies (Cloud Asset Inventory)](https:\u002F\u002Fcloud.google.com\u002Fasset-inventory\u002Fdocs\u002Fsearching-iam-policies)\n    — `gcloud asset search-all-iam-policies` for auditing a principal's\n    bindings.\n-   [View GKE logs](https:\u002F\u002Fdocs.cloud.google.com\u002Fkubernetes-engine\u002Fdocs\u002Fhow-to\u002Fview-logs.md.txt)\n    — Cloud Logging queries for workload and system logs.\n",{"name":5,"metadata":51,"description":7},{"version":52,"category":53},"1.0.2","Security","main","bb9b3f464aae37af360d079c1d863524955b0363","skills\u002Fcloud\u002Fgke-workload-identity",2005,"https:\u002F\u002Fgithub.com\u002Fgoogle\u002Fskills","https:\u002F\u002Fgithub.com\u002Fgoogle","https:\u002F\u002Fopensource.google\u002F","Google ❤️ Open Source","2026-11-14 01:51:35",{"source":8,"skillName":5,"commands":64,"prompt":74,"zipAvailable":75},[65,68,71],{"tool":66,"command":67},"npx","npx skills add google\u002Fskills --skill gke-workload-identity",{"tool":69,"command":70},"bunx","bunx skills add google\u002Fskills --skill gke-workload-identity",{"tool":72,"command":73},"pnpm","pnpm dlx skills add google\u002Fskills --skill gke-workload-identity","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fgoogle\u002Fskills\u002Fblob\u002Fmain\u002Fskills\u002Fcloud\u002Fgke-workload-identity\u002FSKILL.md",true,[77],{"path":78,"resourceType":79,"resourceTypeDesc":80,"sizeBytes":81,"sourceHtmlUrl":82},"references\u002Fattribution.md","REFERENCE","参考文档",1903,"https:\u002F\u002Fgithub.com\u002Fgoogle\u002Fskills\u002Fblob\u002Fmain\u002Fskills\u002Fcloud\u002Fgke-workload-identity\u002Freferences\u002Fattribution.md",[84,114,144,172,199,223],{"skillNo":85,"name":86,"nameZh":6,"description":87,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":88,"categories":89,"keywords":94,"publishedAt":46},"01M6998S2EZKD3GEJ7F943RZTE","sign-in-with-google-web","Implement, configure, and secure Sign In With Google (SiwG) using Google Identity Services (GIS \u002F `https:\u002F\u002Faccounts.google.com\u002Fgsi\u002Fclient`) across web architectures. Use when creating Google sign-in buttons, implementing Google One Tap with FedCM, integrating GIS in React\u002FNext.js\u002FAngular\u002FHTML, verifying ID tokens on backend runtimes (Python\u002FNode.js\u002FGo\u002FJava), enforcing Google Workspace domain restrictions (`hd`), securing client-side ID tokens via WebCrypto nonces or encrypted IndexedDB, embedding in cross-origin iframes via the Intermediate Iframe API (`https:\u002F\u002Faccounts.google.com\u002Fgsi\u002Fintermediate`), configuring Content Security Policy (CSP), COOP, and Permissions Policy (`identity-credentials-get`) headers, or handling sign-out and revocation. Don't use for legacy Google Sign-In (`gapi.auth2`), Google Cloud IAM service accounts, or Android\u002FiOS native Credential Manager.","https:\u002F\u002Fgithub.com\u002Fgoogle\u002Fskills\u002Fblob\u002Fmain\u002Fskills\u002Fidentity\u002Fsign-in-with-google-web\u002FSKILL.md",[90,93],{"categoryNo":91,"categoryName":92,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000009","前端开发",{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[9,95,96,97,98,99,100,43,101,44,102,103,104,105,106,39,107,108,109,110,25,111,112,113],"sign in with google web","sign","with","web","android","go","google workspace","implement","policy","python","implementing","react","permissions","buttons","secure","manager","architectures","domain","runtimes",{"skillNo":115,"name":116,"nameZh":6,"description":117,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":118,"categories":119,"keywords":129,"publishedAt":46},"01M6998PHPDCAD684VW5WRG83D","dpop-adoption","Implement and debug OAuth 2.0 DPoP (RFC 9449) refresh token sender-constraining for WebCrypto, Node.js ES6, and browser runtimes integrating with Google's OAuth platform. Use when configuring non-extractable asymmetric key pairs (P-256), generating DPoP Proof JWTs for authorization code exchange and token refresh, or handling 400 use_dpop_nonce challenge retry loops at oauth2.googleapis.com\u002Ftoken. Don't use for unconstrained OAuth 2.0 flows (where refresh tokens are not bound to a client key pair), or for Google Cloud IAM \u002F service account authentication.","https:\u002F\u002Fgithub.com\u002Fgoogle\u002Fskills\u002Fblob\u002Fmain\u002Fskills\u002Fidentity\u002Fdpop-adoption\u002FSKILL.md",[120,121,124],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":122,"categoryName":123,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发",{"categoryNo":125,"categoryName":126,"taxonomyType":127,"taxonomyTypeDesc":128},"01JBSEEDCAT000000000000030","开发工程师","PROFESSION","适用职业",[130,131,9,44,132,133,42,134,135,136,39,137,138,139,140,141,142,25,113,143,29],"dpop adoption","adoption","es6","retry","flows","challenge","code","browser","loops","at","node","token","pair","platform",{"skillNo":145,"name":146,"nameZh":6,"description":147,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":148,"categories":149,"keywords":156,"publishedAt":46},"01M6998M72TC73EEAQH4XC7EXW","retrieving-developer-knowledge","Searches, retrieves, and synthesizes official Google developer documentation across Google Cloud, AI\u002FGemini, Android, Chrome, Web, Flutter, Go, Firebase, and other Google developer platforms. Integrates with the Developer Knowledge MCP server (search_documents, get_documents, answer_query) or the Developer Knowledge REST API fallback. Use when searching for gcloud CLI commands, API syntax, IAM permissions, official documentation, architectural comparisons, or product choice overviews. Don't use for local filesystem lookups or non-Google documentation.","https:\u002F\u002Fgithub.com\u002Fgoogle\u002Fskills\u002Fblob\u002Fmain\u002Fskills\u002Fdevelopers\u002Fretrieving-developer-knowledge\u002FSKILL.md",[150,151,154,155],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":152,"categoryName":153,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000021","资料检索与研究",{"categoryNo":122,"categoryName":123,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":125,"categoryName":126,"taxonomyType":127,"taxonomyTypeDesc":128},[157,158,159,160,44,161,162,163,164,165,166,167,168,29,169,38,170,39,171,107],"retrieving developer knowledge","knowledge","developer","MCP","mcp server","official","developer documentation","get","search","local","choice","documents","query","across","documentation",{"skillNo":173,"name":174,"nameZh":6,"description":175,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":176,"categories":177,"keywords":178,"publishedAt":46},"01M6998J2CZEXS9BES9S3WWFKC","migrate-to-rust","Clones, analyzes, plans, and migrates legacy codebases (C++, Fortran, Java, Python, C, Shell) from a GitHub URL or local directory to a modern, high-performance, deterministic, 100% Safe Rust architecture, tracking live telemetry across every task bucket, test failure\u002Ffix cycle, and Profile-Guided Optimization (PGO) stage, and producing a first-person AI storytelling report and interactive HTML infographic. Use when migrating a GitHub repository or local codebase to Rust, porting legacy C++, Fortran, Python, or Java workloads to memory-safe Rust, designing Struct-of-Arrays (SoA) or SIMD Rust architectures, or optimizing Rust ports with LLVM PGO. Don't use for unrelated non-Rust refactoring or single-line syntax questions.","https:\u002F\u002Fgithub.com\u002Fgoogle\u002Fskills\u002Fblob\u002Fmain\u002Fskills\u002Fdevelopers\u002Fmigrate-to-rust\u002FSKILL.md",[],[179,180,181,182,183,184,185,186,104,187,188,189,190,191,192,166,193,194,195,29,196,197,170,198],"migrate to rust","rust","migrate","github","memory","performance","directory","safe","ports","llvm","soa","cycle","porting","fix","arrays","infographic","high-performance","URL","architecture","unrelated",{"skillNo":200,"name":201,"nameZh":6,"description":202,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":203,"categories":204,"keywords":208,"publishedAt":46},"01M6998GCC3K29WZ82KXMB9E02","finding-google-skills","Google platform decision and setup guidance, loaded on demand from Google's skill catalog. Use when a developer is choosing or setting up part of their stack, such as where to run a service, a database, storage, messaging, authentication, analytics, ads, or AI model serving, and a Google product is a reasonable candidate - whether or not a vendor is named - or when a request names a Google product or API. Brings in the matching Google skill so the answer can weigh Google options, their trade-offs, and when they are not the right fit. Skip when the stack is already settled on another provider and no Google product is named, or the task involves no platform choice.","https:\u002F\u002Fgithub.com\u002Fgoogle\u002Fskills\u002Fblob\u002Fmain\u002Fskills\u002Fdevelopers\u002Ffinding-google-skills\u002FSKILL.md",[205,206,207],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":122,"categoryName":123,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":125,"categoryName":126,"taxonomyType":127,"taxonomyTypeDesc":128},[9,209,210,211,212,143,213,214,215,216,217,42,218,37,219,167,220,221,29,222,38],"finding google skills","storage","as","messaging","model","trade-offs","provider","answer","fit","catalog","decision","use","database","candidate",{"skillNo":224,"name":225,"nameZh":6,"description":226,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":227,"categories":228,"keywords":231,"publishedAt":46},"01M6998DWNHTH0BS6W1CY8ZXMP","workload-manager-basics","Use this skill to manage Google Cloud Workload Manager evaluations, rules, scanned resources, and validation results by using public client libraries and the REST API. Use when you need to inspect workload best-practice rules, create and run evaluations for Google Cloud general best practices, SAP, SQL Server, or custom organizational rules, review violations, export results to BigQuery, or automate Workload Manager through client libraries because no service-specific public CLI or MCP server is available. Don't use for general Google Compute Engine instance management, VPC configuration, or standard IAM auditing.","https:\u002F\u002Fgithub.com\u002Fgoogle\u002Fskills\u002Fblob\u002Fmain\u002Fskills\u002Fcloud\u002Fworkload-manager-basics\u002FSKILL.md",[229,230],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":122,"categoryName":123,"taxonomyType":21,"taxonomyTypeDesc":22},[232,26,110,233,9,160,234,44,161,235,236,237,238,29,239,38,39,240,241,41,242],"workload manager basics","basics","cli","review","vpc","resources","inspect","you","create","libraries","run"]