feat: Support verifying govcloud aws sessions

[strazzere]

Add support to query govcloud sts endpoints for session tokens.

Description:

While doing some experimentation I noticed that govcloud sessions would never detect, so I added the logic to the session verifier to perform these.

I'm unsure exactly if this is the best way to add the logic in, as if the commercial check fails it will then check if it is a valid govcloud account. So essentially a true-negative will now make two http calls. This might possibly be something that should be gated behind a feature? I was hoping someone at Truffle would have more information on which would be preferred. Part of me thought, no one has ever complained this didn't work so no one else might want it. Though this also could mean no one else has ever realized it wasn't working? Lastly, if this ends up being merged, we may want to do the same with the account check code as well since this also utilizes a similar endpoint.

Checklist:

• Tests passing (make test-community)?
• Lint passing (make lint this requires golangci-lint)?

[kashifkhan0771]

While doing some experimentation I noticed that govcloud sessions would never detect, so I added the logic to the session verifier to perform these.

I believe you meant they are never verified, not "detected," right?
Is the session token pattern the same for both commercial and GovCloud sessions?
If the pattern is indeed the same, and we have two endpoints to verify against with no clear way to determine which secret belongs to which endpoint then your approach seems reasonable.

That said, does the verification API return a specific error when a token is checked against the wrong endpoint?
If so, we should only retry verification in response to that specific error, otherwise we’ll end up re-verifying on every error.

[strazzere]

Correct, I meant verified.

Is the session token pattern the same for both commercial and GovCloud sessions?

Yes, there seems to be no difference in the pattern, it is just a base64'ed protobuf blob - per the comments in the code. I attempted to decode them with the referenced links, in hope that the region was accessible (which would give an indication of govcloud or not) however it is not a fully parsed protobuf with any determinable differences.

That said, does the verification API return a specific error when a token is checked against the wrong endpoint?
It will just return a 403 with no special information indicating that it might be govcloud or valid. This is pretty consistent with how using govcloud things for non-govcloud endpoints tends to reply. It just looks "broken" or "invalid".

[kashifkhan0771]

As you mentioned, there isn’t a clear way to identify the specific endpoint. The changes look good to me overall.
My only concern is that we might end up attempting GovCloud verification for every error we receive from Commercial.
That said, I’m approving this from my side. If anyone has suggestions for a better approach, feel free to add.

[abmussani]

Please correct me if I am wrong, Everytime attemptVerifyMatch returns with err = nil and ok = false, The changes will try to verify for gov region ?

Even If the token has been expired, attemptVerifyMatch will returns err = nil and ok = false . Aren't we confident that credentials are unverified in this case?

[strazzere]

Please correct me if I am wrong, Everytime attemptVerifyMatch returns with err = nil and ok = false, The changes will try to verify for gov region ?

Correct

Even If the token has been expired, attemptVerifyMatch will returns err = nil and ok = false . Aren't we confident that credentials are unverified in this case?

No, if you find gov cloud credentials, they look like expired and unverifiable credentials when hitting the regular endpoint. Upon trying the gov cloud endpoint, it can be seen these are valid and unexpired gov cloud specific credentials.