0

I am trying to fetch a secret from an Azure Key Vault using curl in a Linux VM. My commands are:

ACCESS_TOKEN=$(curl 'http://169.254.169.254/metadata/identity/oauth2/token?api-version=2018-02-01&resource=https%3A%2F%2Fvault.azure.net' -H Metadata:true | jq -r .access_token)

CONFIG_SECRET=$(curl 'https://sFlowDeploymentKeys.vault.azure.net/secrets/config?api-version=2016-10-01' -H "Authorization: Bearer $ACCESS_TOKEN" --http1.1)

I get a 400 error Bad Request. The access token is being retrieved correctly, but the second curl command doesn't return properly. From echoing the command itself, it seems like part of the access token is getting broken off and appended to the end of the command after http1.1.

  • 1
    Why do you post a picture that only contains text ? (and not even the COMPLETE output of curl!) – Luuk Mar 14 '23 at 15:26
  • As I stated, there is a 400 error which is the output. The picture is merely for debugging purposes and also contains a secret so I cannot post the full command. I am just curious why the command is running as so with part of the access token broken off and appended after. –  Mar 14 '23 at 17:15
  • copy/paste the complete command and output into your question above, use the `{}` tool from the Edit menu for proper formatting as `code/data/output/errMsgs` and then replace any secret info with `XXsecretXX` or something. If there are unusal chars in the secret text, swap those into someplace visible, as often Ctrrl-chars etc are what cause commands to fail. Good luck. – shellter Mar 14 '23 at 17:21
  • fixed. the output is just a 400 HTTP error with bad request, no other relevant output. –  Mar 14 '23 at 17:40
  • 1
    It sounds like a semi-invisible carriage return character is getting into your `ACCESS_TOKEN` variable. It could be either because the script file has DOS/Windows-style line endings, or the output from `jq` does, or possibly both. See ["Are shell scripts sensitive to encoding and line endings?"](https://stackoverflow.com/questions/39527571/are-shell-scripts-sensitive-to-encoding-and-line-endings) for info about how to diagnose and fix problems like this. – Gordon Davisson Mar 14 '23 at 19:49

1 Answers1

1

When trying from this side, I am getting a HTTP/1.1 401 Unauthorized (which is expected):

I added the -v to make curl verbose, and changed the ACCESS_TOKEN to "TEST-TEST"

D:\TEMP>curl -v "https://sFlowDeploymentKeys.vault.azure.net/secrets/config?api-version=2016-10-01" -H "Authorization: Bearer TEST-TEST" --http1.1
*   Trying 20.192.44.113:443...
* Connected to sFlowDeploymentKeys.vault.azure.net (20.192.44.113) port 443 (#0)
* schannel: disabled automatic use of client certificate
* ALPN: offers http/1.1
* ALPN: server accepted http/1.1
> GET /secrets/config?api-version=2016-10-01 HTTP/1.1
> Host: sFlowDeploymentKeys.vault.azure.net
> User-Agent: curl/7.83.1
> Accept: */*
> Authorization: Bearer TEST-TEST
>
* Mark bundle as not supporting multiuse
< HTTP/1.1 401 Unauthorized
< Cache-Control: no-cache
< Pragma: no-cache
< Content-Length: 111
< Content-Type: application/json; charset=utf-8
< Expires: -1
< WWW-Authenticate: Bearer authorization="https://login.windows.net/cdc5aeea-15c5-4db6-b079-fcadd2505dc2", resource="https://vault.azure.net"
< x-ms-keyvault-region: centralindia
< x-ms-request-id: 4bde9db9-64d6-4509-995a-db04bf09a8c8
< x-ms-keyvault-service-version: 1.9.736.1
< x-ms-keyvault-network-info: conn_type=Ipv4;addr=195.240.162.281;act_addr_fam=InterNetwork;
< X-Content-Type-Options: nosniff
< Strict-Transport-Security: max-age=31536000;includeSubDomains
< Date: Tue, 14 Mar 2023 17:53:39 GMT
<
{"error":{"code":"Unauthorized","message":"[BearerReadAccessTokenFailed] Error validating token: 'S2S12005'."}}* Connection #0 to host sFlowDeploymentKeys.vault.azure.net left intact
Luuk
  • 12,245
  • 5
  • 22
  • 33
  • So, are you essentially saying the ACCESS_TOKEN is not valid then and the command is correct? I am not getting a 401 error however, as it seems like the last "x" characters of the token are not being properly inputted. It inputs as Authorization: Bearer <95% of TOKEN> --http1.1 <5% of TOKEN>. Maybe thats causing the 400 error? Not sure why this would happen, is there a string length limit? –  Mar 14 '23 at 18:24
  • 1
    No, I am saying you are having a "Bad Request" (it's giving you a HTTP 400 error). You need to find out why you are getting a HTTP400, and when using a token like `TEST-TEST` it's giving a HTTP401. Possible that your token contains spaces or ....? Happy debugging! – Luuk Mar 14 '23 at 18:34