thedevopsmachine commented on issue #14100:
URL: https://github.com/apache/apisix/issues/14100#issuecomment-6425585975

   The change is small and backward-compatible. Make the explicit keys optional 
in the schema, and only construct an explicit `Credentials{}` when static keys 
were actually supplied — otherwise pass `nil` so `lua-resty-aws` falls back to 
its default credential provider chain (which discovers the instance profile / 
ECS or EKS task role / IRSA web-identity and auto-refreshes before expiry).
   
   ```diff
   --- a/apisix/secret/aws.lua
   +++ b/apisix/secret/aws.lua
   @@
            endpoint_url = core.schema.uri_def,
        },
   -    required = {"access_key_id", "secret_access_key"},
    }
   
    local _M = {
        schema = schema
    }
   @@ local function make_request_to_aws(conf, key)
        local region = conf.region
   
   -    local access_key_id = env.fetch_by_uri(conf.access_key_id) or 
conf.access_key_id
   -
   -    local secret_access_key = env.fetch_by_uri(conf.secret_access_key) or 
conf.secret_access_key
   -
   -    local session_token = env.fetch_by_uri(conf.session_token) or 
conf.session_token
   -
   -    local credentials = aws_instance:Credentials({
   -        accessKeyId = access_key_id,
   -        secretAccessKey = secret_access_key,
   -        sessionToken = session_token,
   -    })
   +    -- Resolve explicit credentials from env/config when present.
   +    local access_key_id = conf.access_key_id
   +                          and (env.fetch_by_uri(conf.access_key_id) or 
conf.access_key_id)
   +    local secret_access_key = conf.secret_access_key
   +                          and (env.fetch_by_uri(conf.secret_access_key) or 
conf.secret_access_key)
   +    local session_token = conf.session_token
   +                          and (env.fetch_by_uri(conf.session_token) or 
conf.session_token)
   +
   +    -- If static keys are supplied, use them (long-term IAM user keys, or
   +    -- externally-rotated temporary creds). Otherwise leave credentials nil 
so
   +    -- lua-resty-aws resolves them via its default provider chain. On EC2 /
   +    -- ECS / EKS this picks up the instance profile or task role (incl. IRSA
   +    -- web-identity) and auto-refreshes the temporary credentials -- access
   +    -- key, secret, AND session token -- before they expire, with no config
   +    -- churn.
   +    local credentials
   +    if access_key_id and secret_access_key then
   +        credentials = aws_instance:Credentials({
   +            accessKeyId = access_key_id,
   +            secretAccessKey = secret_access_key,
   +            sessionToken = session_token,
   +        })
   +    end
   ```
   
   The rest of `make_request_to_aws` is unchanged — `credentials` is already 
passed into `aws_instance:SecretsManager({ credentials = credentials, ... })`. 
When it is `nil`, `lua-resty-aws` resolves credentials through its provider 
chain instead of the fixed ones.
   
   Notes / considerations for reviewers:
   
   -   **Backward compatible.** Existing configs that set `access_key_id` + 
`secret_access_key` (long-term keys) behave exactly as before. Dropping 
`required` only *allows* omitting them; it does not change behavior when they 
are present.
       
   -   **Depends on the bundled** `lua-resty-aws` **provider chain.** This 
relies on `lua-resty-aws`'s default credential provider 
(ECS/EKS/IRSA/instance-profile providers), which is what carries an 
`Expiration` and refreshes. The exact provider support varies by 
`lua-resty-aws` version, so the fix should be validated against the version 
APISIX pins in its rockspec.
       
   -   **Docs.** The `secret`/AWS doc should note that omitting the keys opts 
into the provider chain (recommended on ECS/Fargate, EKS, EC2), while supplying 
them uses static credentials.


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]

Reply via email to