Clojurians Log v2

Apologies @pieterbreed, I did not read your message or issue https://github.com/cognitect-labs/aws-api/issues/172 closely enough. Let me take a closer look and get back to you ...

Hi again @pieterbreed. I still don't have an answer for you, but I've learned a couple of things that may be clues: • Session tokens are indeed base64 encoded, but are otherwise opaque. • Session tokens can be gotten from STS global or STS regional endpoints, and > Session tokens from Regional AWS STS endpoints are valid in all AWS Regions. Session tokens from the global STS endpoint are valid only in AWS Regions that are enabled by default. This is according to https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_enable-regions.html and https://medium.com/@TalBeerySec/revealing-the-inner-structure-of-aws-session-tokens-a6c76469cba7. So one completely untested hypothesis is that the aws cli is returning for you a regional session token that works for whatever client you then use, but the aws api invocation of AssumeRole operation is defaulting to the global STS endpoint, returning a global session token which is not valid for the client (or region) you then attempt to use it with. Again, completely untested. I've still yet to reproduce your problem; if I could do that, then I would next look into invoking a regional STS endpoint via client https://github.com/cognitect-labs/aws-api?tab=readme-ov-file#endpoint-override and see if resulting token makes any difference.

Hi @scottbale , thank you for the update, this is something i can test (tomorrow). Will revert with the results. Since AssumeRole is such a custom scenario type of action, I’m struggling a little bit to imagine how to share the code + the infra that will reproduce my scenario. How do you feel about if I DM you details of my actual environment with which to replicate?

Hi @scottbale, here's what I found: (work-around solution) In the AWS web console, under IAM account settings, there is a toggle for Global endpoint which can be changed to make tokens issued by global sts endpoint valid in all regions (and not only the default ones). This makes the tokens bigger, but otherwise solves the problem I have. From here, assume this setting point_up::skin-tone-4 was not made, ie account in default state. If I create my client like this:

(def sts-client
    (aws/client
     {:api               :sts
      :region            "af-south-1"
      :endpoint-override "sts.af-south-1.amazonaws.com"
      :credentials-provider
      (reify
        cognitect.aws.credentials/CredentialsProvider
        (fetch [_]
          {:aws/access-key-id     "ASIAXXXXXXXXXXXXXXW7"
           :aws/secret-access-key "jGGa7XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXIu"
           :aws/session-token     "IQoJb3JpZ2luX2VjEKn//////////XXXXXXX...XXXXXOmU="}))}))

(aws/invoke sts-client
                {:op      :AssumeRole
                 :request {:RoleArn         "arn:aws:iam::77499999999:role/AllowCognitoClients"
                           :RoleSessionName "pieter-test-2"}})

{:ErrorResponse
 {:Error
  {:Type "Sender",
   :TypeAttrs {},
   :Code "SignatureDoesNotMatch",
   :CodeAttrs {},
   :Message "Credential should be scoped to a valid region. ",
   :MessageAttrs {}},
  :ErrorAttrs {},
  :RequestId "30405d2d-378d-4062-a031-989a8cdb2c22",
  :RequestIdAttrs {}},
 :ErrorResponseAttrs {:xmlns ""},
 :cognitect.aws.http/status 403,
 :cognitect.anomalies/category :cognitect.anomalies/forbidden,
 :cognitect.aws.error/code "SignatureDoesNotMatch"}

(:endpoint sts-client)
  
  {:hostname          "sts.amazonaws.com"
   :protocols         ["https"]
   :signatureVersions ["v4"]
   :variants          [,,,]
   :credentialScope   {:region "us-east-1"}
   :partition         "aws"
   :region            "aws-global"
   :dnsSuffix         "amazonaws.com"}

Hi @scottbale, thanks for looking into this. I spent a little bit more time looking at this. Regarding the difference in SessionToken that I described previously, I noticed the following: • valid SessionTokens (ie ones from AWS CLI) all start with these character string: IQoJb3JpZ2luX2VjEIv//////////... • The SessionTokens I receive from cognitect/aws-api all start with FwoGZXIvYXdzEF8... When I base64-decode these values, the differ like this: • AWS CLI: (non-printable) origin_ec... • cognitect aws-api: (non-printable) er/aws... I'm (still) not sure if this is a red-herring or a clue.

Hi @pieterbreed. Unfortunately aws-api does not support "assume role", this is a longstanding issue https://github.com/cognitect-labs/aws-api/issues/172. Ignore this, sorry. I will study more carefully.

I scanned that issue and have a question; Are you saying that if I call (aws/invoke valid-sts-client {:op :AssumeRole :request {...}}) that this will return incorrect results?

My use-case is this one: https://github.com/cognitect-labs/aws-api/blob/main/examples/assume_role_example.clj

I believe you would need to use the com.cognitect.aws/logs artifact ("logs" being the short name for "Amazon CloudWatch Logs") and invoke the GetQueryResults operation. Latest version is 871.2.29.35.