HCP Vault: New OIDC Provider's /.well-known/openid-configuration returns port :8202 instead of :8200

HashiCorp Cloud Platform (HCP) HCP Vault
1

Hello,
When I query the /.well-known/openid-configuration endpoint of the OpenID Connect ID Secrets Engine on my HCP Vault 1.9.2 one-node Development/Extra Small cluster over my private HVP to VPC subnet peering connetion from a VM on EC2, it returns TCP port :8202 in the URLs, where I would expect to see :8200, such as shown in the documentation at step 6.:

[ec2-user@ip-172-20-10-223 ~]$ curl -sS https://hcp-tf-example-vault-cluster.private.vault.b8XXX4e.aws.hashicorp.cloud:8200/v1/admin/identity/oidc/provider/my-provider/.well-known/openid-configuration | jq .
{
  "issuer": "https://node-10-0.hcp-tf-example-vault-cluster.private.vault.b8XXX4e.aws.hashicorp.cloud:8202/v1/admin/identity/oidc/provider/my-provider",
  "jwks_uri": "https://node-10-0.hcp-tf-example-vault-cluster.private.vault.b8XXX4e.aws.hashicorp.cloud:8202/v1/admin/identity/oidc/provider/my-provider/.well-known/keys",
  "authorization_endpoint": "https://node-10-0.hcp-tf-example-vault-cluster.private.vault.b8XXX4e.aws.hashicorp.cloud:8202/ui/vault/admin/identity/oidc/provider/my-provider/authorize",
  "token_endpoint": "https://node-10-0.hcp-tf-example-vault-cluster.private.vault.b8XXX4e.aws.hashicorp.cloud:8202/v1/admin/identity/oidc/provider/my-provider/token",
  "userinfo_endpoint": "https://node-10-0.hcp-tf-example-vault-cluster.private.vault.b8XXX4e.aws.hashicorp.cloud:8202/v1/admin/identity/oidc/provider/my-provider/userinfo",
  "request_uri_parameter_supported": false,
  "id_token_signing_alg_values_supported": [
    "RS256",
    "RS384",
    "RS512",
    "ES256",
    "ES384",
    "ES512",
    "EdDSA"
  ],
  "response_types_supported": [
    "code"
  ],
  "scopes_supported": [
    "openid"
  ],
  "subject_types_supported": [
    "public"
  ],
  "grant_types_supported": [
    "authorization_code"
  ],
  "token_endpoint_auth_methods_supported": [
    "client_secret_basic"
  ]
}

Although I have permitted egress TCP port :8202 on my VPC’s subnet towards HVP, HCP Vault does not answer TCP connections at port :8202.
Does either the HVP block ingress :8202, or the Vault cluster only listen on :8200, but not on :8202 as well?

Further, I observe that on the public address, if enabled on the HCP Vault cluster configuration, the /well-known/openid-configuration endpoint returns exactly the same answer as shown above. Also, HCP Vault does not answer TCP connections on port :8202, but only on :8200.
The FQDNs returned in the configuration use ...-cluster.private.vault... in the URLs that point to the internal IP address of the HCP Vault cluster, which is not reachable from the Internet.
This makes it difficult or impossible to use/test the OIDC Provider over the external port of HCP Vault, for example from OIDC Clients on the Internet that support debugging OAuth flows to OIDC Providers, such as HCP Vault.

While setting up the OIDC Provider on HCP Vault, I have noticed that care must be taken of Namespaces which the Enterprise version provides, e.g. the default namespace admin must be included into the URL path, as shown in the curl query above :8200/v1/admin/identity/oidc/provider/my-provider/.well-known/openid-configuration, or by adding a HTTP Header X-Vault-Namespace to the requests.

Eventually, does Vault Enterprise have a similar effect on port numbers like using :8202 in some URLs instead of :8200? Or, is this an issue in the way HCP configures Vault servers?
Thank you.

2

The issuer parameter is configurable OIDC Identity Provider | Vault by HashiCorp you can have this point to the desired endpoint

1 Like
3

This URL Read Provider OpenID Configuration

It only talks about reading OIDC configuration, there is no option to update the issuer in OIDC configuration