Nginx запрашивает / вместо /.well-known/openid-configuration

Настраиваю workload identity federation между on-prem GitLab и GCP согласно документации. Сделал настройки в GCP, взял готовый пример пайплайна, но джоба падает с ошибкой

$ gcloud auth print-access-token
ERROR: (gcloud.auth.print-access-token) ("Error code invalid_grant: Parsing error for OIDC discovery document: [Line 0, column 0: Unexpected end of stream : expected '{']", '{"error":"invalid_grant","error_description":"Parsing error for OIDC discovery document: [Line 0, column 0: Unexpected end of stream : expected \'{\']"}')

Смотрю что выдаёт https://GITLAB/.well-known/openid-configuration и вижу 302 редирект на /users/sign_in - это неожиданное поведение. На этот запрос должно возвращать JSON вида

$ curl -s https://gitlab.com/.well-known/openid-configuration
{"issuer":"https://gitlab.com","authorization_endpoint":"https://gitlab.com/oauth/authorize","token_endpoint":"https://gitlab.com/oauth/token","revocation_endpoint":"https://gitlab.com/oauth/revoke","introspection_endpoint":"https://gitlab.com/oauth/introspect","userinfo_endpoint":"https://gitlab.com/oauth/userinfo","jwks_uri":"https://gitlab.com/oauth/discovery/keys","scopes_supported":["api","read_api","read_user","read_repository","write_repository","read_registry","write_registry","sudo","openid","profile","email"],"response_types_supported":["code"],"response_modes_supported":["query","fragment"],"grant_types_supported":["authorization_code","password","client_credentials","refresh_token"],"token_endpoint_auth_methods_supported":["client_secret_basic","client_secret_post"],"subject_types_supported":["public"],"id_token_signing_alg_values_supported":["RS256"],"claim_types_supported":["normal"],"claims_supported":["iss","sub","aud","exp","iat","sub_legacy","name","nickname","email","email_verified","website","profile","picture","groups","groups_direct","https://gitlab.org/claims/groups/owner","https://gitlab.org/claims/groups/maintainer","https://gitlab.org/claims/groups/developer"]}

Нужно разобраться откуда у меня берется этот редирект.

GitLab выставлен в интернет через "внешний" Nginx, который разрешает доступ только с определенных адресов, и для начала проверю что возвращает внутри сервера GitLab

$ wget --no-check-certificates -qO- https://localhost/.well-known/openid-configuration
{"issuer":"https://GITLAB","authorization_endpoint":"https://GITLAB/oauth/authorize","token_endpoint":"https://GITLAB/oauth/token","revocation_endpoint":"https://GITLAB/oauth/revoke","introspection_endpoint":"https://GITLAB/oauth/introspect","userinfo_endpoint":"https://GITLAB/oauth/userinfo","jwks_uri":"https://GITLAB/oauth/discovery/keys","scopes_supported":["api","read_api","read_user","read_repository","write_repository","read_registry","write_registry","sudo","openid","profile","email"],"response_types_supported":["code"],"response_modes_supported":["query","fragment"],"grant_types_supported":["authorization_code","password","client_credentials","refresh_token"],"token_endpoint_auth_methods_supported":["client_secret_basic","client_secret_post"],"subject_types_supported":["public"],"id_token_signing_alg_values_supported":["RS256"],"claim_types_supported":["normal"],"claims_supported":["iss","sub","aud","exp","iat","sub_legacy","name","nickname","email","email_verified","website","profile","picture","groups","groups_direct","https://gitlab.org/claims/groups/owner","https://gitlab.org/claims/groups/maintainer","https://gitlab.org/claims/groups/developer"]}

Выходит что сам GitLab отдает JSON, но поведение меняется, если запрос приходит от "внешнего" Nginx. Пробую сделать запрос с сервера, где запущен "внешний" Nginx на бэкенд GitLab

$ curl -s --connect-to GITLAB:443:10.0.31.8:443 https://GITLAB/.well-known/openid-configuration
{"issuer":"https://GITLAB","authorization_endpoint":"https://GITLAB/oauth/authorize","token_endpoint":"https://GITLAB/oauth/token","revocation_endpoint":"https://GITLAB/oauth/revoke","introspection_endpoint":"https://GITLAB/oauth/introspect","userinfo_endpoint":"https://GITLAB/oauth/userinfo","jwks_uri":"https://GITLAB/oauth/discovery/keys","scopes_supported":["api","read_api","read_user","read_repository","write_repository","read_registry","write_registry","sudo","openid","profile","email"],"response_types_supported":["code"],"response_modes_supported":["query","fragment"],"grant_types_supported":["authorization_code","password","client_credentials","refresh_token"],"token_endpoint_auth_methods_supported":["client_secret_basic","client_secret_post"],"subject_types_supported":["public"],"id_token_signing_alg_values_supported":["RS256"],"claim_types_supported":["normal"],"claims_supported":["iss","sub","aud","exp","iat","sub_legacy","name","nickname","email","email_verified","website","profile","picture","groups","groups_direct","https://gitlab.org/claims/groups/owner","https://gitlab.org/claims/groups/maintainer","https://gitlab.org/claims/groups/developer"]}

Ответ правильный, а значит проблема в конфигурации "внешнего" Nginx. Попутно смотрю в логи Nginx на сервере GitLab и вижу что запрос с "внешнего" Nginx был не GET /.well-known/openid-configuration, а GET / и поэтому GitLab отвечает 302 редиректом на /users/sign_in.

Довольно долго мучился с конфигурацией Nginx пока не перечитал документацию на proxy_pass и попробовал убрать слеш в конце адреса.

Было:

location /.well-known/openid-configuration {
  allow all;
  proxy_pass https://10.0.31.8:443/;
}

Стало:

location /.well-known/openid-configuration {
  allow all;
  proxy_pass https://10.0.31.8:443;
}

Не уверен было ли раньше другое поведение (есть упоминание об изменение поведения proxy_pass в Nginx 1.1.12) поскольку только сейчас я сделал частично закрытый сайт, но после этого изменения workload indetity federation заработал без ошибок и больше не нужно создавать ключи для сервис аккаунтов.