Baoyuantop commented on issue #12782:
URL: https://github.com/apache/apisix/issues/12782#issuecomment-6359620873
Hi @klinux, thanks for the detailed config and stack trace.
We looked at the failure path. The crash happens **before** APISIX calls GCP
Secret Manager: GCP auth builds a JWT with `resty.jwt:sign` / `RSASigner` using
`auth_config.private_key`, and that PEM load/sign step is what aborts.
OpenResty then logs `runtime error: unknown reason` because `resty.jwt` raises
a table (`error({ reason = ... })`), so the real reason is easy to miss.
That usually means the `private_key` string APISIX sees is **not a valid
PEM** at runtime (common cases: newlines stored as literal `\n` after
double-escaping in JSON/etcd, a truncated key, or extra quotes/whitespace). A
normal PKCS#8 `-----BEGIN PRIVATE KEY-----` block with real newlines does work
on the official image; plaintext `key-auth` working only shows the plugin path
is fine.
This also looks **different** from [discussion
#12749](https://github.com/apache/apisix/discussions/12749#discussioncomment-14997875)
(CRD not forwarding `$secret://`): your stack already enters
`apisix/secret/gcp.lua` → `google-cloud-oauth.lua`, so the secret URI is being
resolved.
Could you check:
1. In the live `secrets/gcp/1` object, does `auth_config.private_key`
contain real line breaks (not the two characters `\` + `n`)?
2. Or configure via `auth_file` pointing at the full GCP service-account
JSON / PEM and retry?
If it still fails after a verified PEM, please share APISIX exact image tag
and (redacted) whether the key header is `BEGIN PRIVATE KEY` vs `BEGIN RSA
PRIVATE KEY`.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
