We are trying to promote Vault as OIDC provider for Boundary, but it is not working as expected

Boundary
#1

The auto generated issuer address is missing the vault address, ideally it should be “issuer”: https:// vaultaddres s:8200/v1/identity/oidc/provider/my-provider

But the issuer address is :"/v1/identity/oidc/provider/my-provider"

ref url: Vault as an OIDC Identity Provider | Vault - HashiCorp Learn

image
image1086×758 56.9 KB

#2

Does your Vault cluster config have an api_addr set in its configuration?

If it does, that should be what’s being used as the scheme://host:port part of the URL – if not, Vault will try to determine one to use automatically, but it’s not always able to do this (I believe you can check by looking at the api_addr value in the output of vault read sys/config/state/sanitized). If none is set or auto-detected, you can specify the OIDC issuer explicitly as part of the OIDC provider setup.

#3

Hi, Omkensey we tried to follow the url and modify the issuer, but it not changing.

Would really appreciate it if you could show in commands how to change issuer.

#4

We are getting {“errors”:[“unsupported operation”]} when updating the issuer value

LOGS Below

curl --header “X-Vault-Token: $VAULT_TOKEN” --request POST --data @payload.json $VAULT_ADDR/v1/identity/oidc/provider/my-provider/.well-known/openid-configuration

{“errors”:[“unsupported operation”]}

root@vaultx:~# cat payload.json
{
“data”: {
“issuer”: “https://vaultx.techrock.info:8200/v1/identity/oidc/provider/my-provider”,
“jwks_uri”: “/v1/identity/oidc/provider/my-provider/.well-known/keys”,
“authorization_endpoint”: “/ui/vault/identity/oidc/provider/my-provider/authorize”,
“token_endpoint”: “/v1/identity/oidc/provider/my-provider/token”,
“userinfo_endpoint”: “/v1/identity/oidc/provider/my-provider/userinfo”,
“request_uri_parameter_supported”: false,
“id_token_signing_alg_values_supported”: [
“RS256”,
“RS384”
],
“response_types_supported”: [
“code”
],
“scopes_supported”: [
“groups”,
“user”,
“openid”
],
“subject_types_supported”: [
“public”
],
“grant_types_supported”: [
“authorization_code”
],
“token_endpoint_auth_methods_supported”: [
“none”,
“client_secret_basic”
]
}
}

root@vaultx:~# curl --header “X-Vault-Token: $VAULT_TOKEN” --request POST --data @payload.json $VAULT_ADDR/v1/identity/oidc/provider/my-provider/.well-known/openid-configuration -v
Note: Unnecessary use of -X or --request, POST is already inferred.

  • Trying 3.19.74.64:8200…
  • TCP_NODELAY set
  • Connected to vaultx.techrock.info (3.19.74.64) port 8200 (#0)
  • ALPN, offering h2
  • ALPN, offering http/1.1
  • successfully set certificate verify locations:
  • CAfile: /etc/ssl/certs/ca-certificates.crt
    CApath: /etc/ssl/certs
  • TLSv1.3 (OUT), TLS handshake, Client hello (1):
  • TLSv1.3 (IN), TLS handshake, Server hello (2):
  • TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
  • TLSv1.3 (IN), TLS handshake, Request CERT (13):
  • TLSv1.3 (IN), TLS handshake, Certificate (11):
  • TLSv1.3 (IN), TLS handshake, CERT verify (15):
  • TLSv1.3 (IN), TLS handshake, Finished (20):
  • TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
  • TLSv1.3 (OUT), TLS handshake, Certificate (11):
  • TLSv1.3 (OUT), TLS handshake, Finished (20):
  • SSL connection using TLSv1.3 / TLS_AES_128_GCM_SHA256
  • ALPN, server accepted to use h2
  • Server certificate:
  • subject: CN=vaultx.techrock.info
  • start date: Apr 8 01:02:31 2022 GMT
  • expire date: Jul 7 01:02:30 2022 GMT
  • subjectAltName: host “vaultx.techrock.info” matched cert’s “vaultx.techrock.info”
  • issuer: C=US; O=Let’s Encrypt; CN=R3
  • SSL certificate verify ok.
  • Using HTTP2, server supports multi-use
  • Connection state changed (HTTP/2 confirmed)
  • Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
  • Using Stream ID: 1 (easy handle 0x56348e450fa0)

POST /v1/identity/oidc/provider/my-provider/.well-known/openid-configuration HTTP/2
Host: vaultx.techrock.info:8200
user-agent: curl/7.68.0
accept: /
content-length: 805
content-type: application/x-www-form-urlencoded

  • We are completely uploaded and fine
  • TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
  • Connection state changed (MAX_CONCURRENT_STREAMS == 250)!
    < HTTP/2 405
    < cache-control: no-store
    < content-type: application/json
    < strict-transport-security: max-age=31536000; includeSubDomains
    < content-length: 37
    < date: Sat, 16 Apr 2022 07:44:23 GMT
    <
    {“errors”:[“unsupported operation”]}
  • Connection #0 to host vaultx.techrock.info left intact
#5

The OIDC well-known path isn’t an API endpoint you can send a configuration update to in Vault. Our Learn guide for setting up the OIDC provider will step you through how to set that up. But as a first step, what do you see for the api_addr when you run vault read sys/config/state/sanitized?

The endpoints for the OIDC provider are documented in the OIDC provider API docs.

#6

root@vaultx:~# vault read sys/config/state/sanitized
Key Value

api_addr n/a
cache_size 0
cluster_addr n/a
cluster_cipher_suites n/a
cluster_name n/a
default_lease_ttl 0s
default_max_request_duration 0s
disable_cache false
disable_clustering false
disable_indexing false
disable_mlock false
disable_performance_standby false
disable_printable_check false
disable_sealwrap false
disable_sentinel_trace false
enable_response_header_hostname false
enable_response_header_raft_node_id false
enable_ui true
listeners [map[config:map[address:0.0.0.0:8200 tls_cert_file:/opt/vault/tls/vaultxfullchain.pem tls_key_file:/opt/vault/tls/vaultxprivatekey.pem] type:tcp]]
log_format unspecified
log_level n/a
log_requests_level n/a
max_lease_ttl 0s
pid_file n/a
plugin_directory n/a
raw_storage_endpoint false
seals [map[disabled:false type:shamir]]
storage map[cluster_addr: disable_clustering:false redirect_addr: type:file]
root@vaultx:~#

cat /etc/vault.d/vault.hcl

ui = true

storage “file” {
path = “/opt/vault/data”
}

HTTPS listener

listener “tcp” {
address = “0.0.0.0:8200”
tls_cert_file = “/opt/vault/tls/vaultxfullchain.pem”
tls_key_file = “/opt/vault/tls/vaultxprivatekey.pem”
}

#7
  • issuer (string: <optional>) - Specifies what will be used as the scheme://host:port component for the iss claim of ID tokens. This defaults to a URL with Vault’s api_addr as the scheme://host:port component and /v1/:namespace/identity/oidc/provider/:name as the path component. If provided explicitly, it must point to a Vault instance that is network reachable by clients for ID token validation.

You have set neither api_addr in the Vault configuration file, nor the issuer parameter when setting up the OIDC provider - you are going to have to set one of these.

1 Like
#8

I think you can just repeat step 5 of the “Create an OIDC provider” section in the Learn guide, but this time add issuer=https://[your Vault hostname]:8200 to the command parameters.

Then repeat step 6 as-is to check the OIDC well-known path to see if it worked.

#9

Thanks omkensey & maxb…

Now it’s Displaying the correct Vault OIDC configuration endpoint