Unable to generate_credentials() for an AWS secret engine STS endpoint

[sunchill06]

I get the following error when I try to get credentials from an sts endpoint. Below is the error.

Response

{
  "errorMessage": "Error assuming role: InvalidParameter: 1 validation error(s) found.\n- minimum field value of 900, AssumeRoleInput.DurationSeconds.\n, on put https://vault.endpoint.com/v1/aws/sts/vault-policy",
  "errorType": "InvalidRequest",
  "stackTrace": [
    "  File \"/var/task/lambda_function.py\", line 54, in lambda_handler\n    print(hvac.api.secrets_engines.Aws.generate_credentials(client, 'lambda_china_staging', role_arn='arn:aws:iam::1234567890:role/VaultAssumeRoleDummy', endpoint='sts', ttl='3600s'))\n",
    "  File \"/var/task/hvac/api/secrets_engines/aws.py\", line 397, in generate_credentials\n    params=params,\n",
    "  File \"/var/task/hvac/adapters.py\", line 139, in put\n    return self.request(\"put\", url, **kwargs)\n",
    "  File \"/var/task/hvac/adapters.py\", line 369, in request\n    response = super().request(*args, **kwargs)\n",
    "  File \"/var/task/hvac/adapters.py\", line 336, in request\n    method, url, response.status_code, text, errors=errors\n",
    "  File \"/var/task/hvac/utils.py\", line 36, in raise_for_error\n    raise exceptions.InvalidRequest(message, errors=errors, method=method, url=url)\n"
  ]
}

Request:

hvac.api.secrets_engines.Aws.generate_credentials(client, 'lambda_china_staging', role_arn='arn:aws:iam::1234567890:role/VaultAssumeRoleDummy', endpoint='sts', ttl='3600s')

[briantist]

Hi @sunchill06 , I'd like to clarify what's being attempted here and what's going wrong.

It seems like you're calling hvac.api.secrets_engines.Aws.generate_credentials, and passing in the ttl parameter, but the ttl is not being passed correctly to the endpoint in Vault, is that correct?

[sunchill06]

HI @briantist , Thanks for reverting. Yeah I am trying to pass ttl parameter but its giving me the error mentioned in the issue description. Also, I assumed that since the STS endpoint would internally pass a default ttl of 3600s so I don't really pass the ttl param but even that doesn't work and I get the same error.

[briantist]

@sunchill06 thanks very much for this report. I think I have a fix that will work for it. We unfortunately do not have good test coverage against the AWS engine since we do not have an AWS environment to test against in CI.

Would you be able to test out this fix?

• AWS secret engine - fix generate_credentials for STS endpoint #934

You should be able to install this (perhaps into a virtual environment is a good idea) by installing off of my branch. This might work:

pip install https://github.com/briantist/hvac/archive/secrets/aws/generate_credentials-param-passing.zip

Let me know if that works for you, thanks!

[sunchill06]

Hi @briantist, Thanks for helping out here.

I can see that its working fine now, provided that I pass the ttl param. But if I skip the ttl param it still gives the same error. Wonder if STS API is causing this, whereas there documentation suggests that the default token time is `3600s.

 {
  "errorMessage": "Error assuming role: InvalidParameter: 1 validation error(s) found.\n- minimum field value of 900, AssumeRoleInput.DurationSeconds.\n, on put https://vault.endpoint.com/v1/aws/sts/vault-policy",
  "errorType": "InvalidRequest",
  "stackTrace": [
    "  File \"/var/task/lambda_function.py\", line 54, in lambda_handler\n    print(hvac.api.secrets_engines.Aws.generate_credentials(client, 'vault_aws_secret_role', role_arn='arn:aws:iam::1234567890:role/VaultAssumeRoleDummy', endpoint='sts', ttl='3600s'))\n",
    "  File \"/var/task/hvac/api/secrets_engines/aws.py\", line 397, in generate_credentials\n    params=params,\n",
    "  File \"/var/task/hvac/adapters.py\", line 139, in put\n    return self.request(\"put\", url, **kwargs)\n",
    "  File \"/var/task/hvac/adapters.py\", line 369, in request\n    response = super().request(*args, **kwargs)\n",
    "  File \"/var/task/hvac/adapters.py\", line 336, in request\n    method, url, response.status_code, text, errors=errors\n",
    "  File \"/var/task/hvac/utils.py\", line 36, in raise_for_error\n    raise exceptions.InvalidRequest(message, errors=errors, method=method, url=url)\n"
  ]
}

[briantist]

Thanks @sunchill06 that's weird. The default is also specified on the Vault side so even without AWS's default value it should still be that. I'll see if I can find a reason why that's not the case. If possible, can you try using curl or some other method to make the same request directly to Vault to see if it defaults to 3600s correctly?

[sunchill06]

Hi @briantist,

I tried with curl and it works fine without specifying ttl explicitly.

[sunchill06]

Hi @briantist,

Sorry about my earlier comment. Earlier, I actually tried with a wrapper that we have written around vault and there we pass ttl of 900s explicitely. Today I retried directly with vault endpoint and it doesn't work without specifying ttl. See below:

curl -X POST --header "X-Vault-Token: <redacted>" 'https://<vault-endpoint>/v1/aws/sts/<role>'

{"errors":["Error assuming role: InvalidParameter: 1 validation error(s) found.\n- minimum field value of 900, AssumeRoleInput.DurationSeconds.\n"]}

---

curl -X POST --header "X-Vault-Token: <redacted>" -d 'ttl=900s' 'https://<vault-endpoint>/v1/aws/sts/<role>'
{"request_id":"51520d2c-494a-f456-099a-4fb30deb2f7f","lease_id":"aws/sts/<role>/JHZpJJcQcJZNtfjbo6Bpc72S","renewable":false,"lease_duration":899,"data":{"access_key":"<redacted>","arn":"arn:aws:sts::12333523523523:assumed-role/<iam-role>/vault-oidc-gsuite-sunil.aggarwal@domain","secret_key":"<redacted>","security_token":"<redacted>"},"wrap_info":null,"warnings":null,"auth":null}

[briantist]

Thanks for the update @sunchill06 I was really scratching my head on this one 😅

So does that mean that even Vault is requiring an explicit ttl?

Is it possible for your role in particular, default_sts_ttl may have been set with a value under 900s?

[sunchill06]

Sorry about that @briantist, I should have checked this thoroughly but I was just too much occupied. And yes, you rightly pointed out, we are using default_sts_ttl may be that explains the behaviour.

[briantist]

ok cool, at least that explains everything then, but no worries this wasn't the main thing holding up merging, we (maintainers) need to fix the CI failures before we can start merging other PRs, so I'm working on that with the others, but hopefully we'll get this fix in and released soon