Set AWS_SDK_LOAD_CONFIG for system services

[arnaldo2792]

Issue number:

Related: bottlerocket-os/bottlerocket#1667

Description of changes:

The AWS SDK for Go doesn't use the ${HOME}/.aws/config file unless the AWS_SDK_LOAD_CONFIG env variable is set to a truthy value. This applies to both v1 and v2 versions of the AWS SDK for Go. The AWS SDK for Rust doesn't require AWS_SDK_LOAD_CONFIG to be set to read ${HOME}/.aws/config

Testing done:

In an aws-ecs-2-fips variant which defaults to have an AWS config as:

[default]
use_fips_endpoint=true

Without the environment variable set, the ECS agent used the default AWS endpoints. With the environment variable set and the same AWS confg as above, the ECS agent used the FIPS endpoints:

[root@admin]# sheltie journalctl -u systemd-resolved.service | grep fips
systemd-resolved[5806]: Looking up RR for ecs-fips.us-west-2.amazonaws.com IN AAAA.
systemd-resolved[5806]: Cache miss for ecs-fips.us-west-2.amazonaws.com IN AAAA
systemd-resolved[5806]: Firing regular transaction 38590 for <ecs-fips.us-west-2.amazonaws.com IN AAAA> scope dns on eth0/* (validate=yes).
systemd-resolved[5806]: Looking up RR for ecs-fips.us-west-2.amazonaws.com IN A.
systemd-resolved[5806]: Cache miss for ecs-fips.us-west-2.amazonaws.com IN A
systemd-resolved[5806]: Firing regular transaction 35110 for <ecs-fips.us-west-2.amazonaws.com IN A> scope dns on eth0/* (validate=yes).
systemd-resolved[5806]: Not caching negative entry for: ecs-fips.us-west-2.amazonaws.com IN AAAA, cache mode set to no-negative
systemd-resolved[5806]: Regular transaction 38590 for <ecs-fips.us-west-2.amazonaws.com IN AAAA> on scope dns on eth0/* now complete with <success> from network (unsigned; non-confidential).
systemd-resolved[5806]: Added positive unauthenticated non-confidential cache entry for ecs-fips.us-west-2.amazonaws.com IN A 60s on eth0/INET/172.31.0.2
systemd-resolved[5806]: Regular transaction 35110 for <ecs-fips.us-west-2.amazonaws.com IN A> on scope dns on eth0/* now complete with <success> from network (unsigned; non-confidential).
systemd-resolved[5806]: Looking up RR for ecs-fips.us-west-2.amazonaws.com IN AAAA.
systemd-resolved[5806]: Cache miss for ecs-fips.us-west-2.amazonaws.com IN AAAA
systemd-resolved[5806]: Firing regular transaction 26730 for <ecs-fips.us-west-2.amazonaws.com IN AAAA> scope dns on eth0/* (validate=yes).
systemd-resolved[5806]: Looking up RR for ecs-fips.us-west-2.amazonaws.com IN A.
systemd-resolved[5806]: Positive cache hit for ecs-fips.us-west-2.amazonaws.com IN A
systemd-resolved[5806]: Regular transaction 25613 for <ecs-fips.us-west-2.amazonaws.com IN A> on scope dns on eth0/* now complete with <success> from cache (unsigned; non-confidential).
systemd-resolved[5806]: Not caching negative entry for: ecs-fips.us-west-2.amazonaws.com IN AAAA, cache mode set to no-negative
systemd-resolved[5806]: Regular transaction 26730 for <ecs-fips.us-west-2.amazonaws.com IN AAAA> on scope dns on eth0/* now complete with <success> from network (unsigned; non-confidential).

Terms of contribution:

By submitting this pull request, I agree that this contribution is dual-licensed under the terms of both the Apache License, version 2.0, and the MIT license.

[bcressey]

Can you confirm that this configuration does not leak into the environment for orchestrated containers?

Have you confirmed via code inspection that this does nothing if the config file doesn't exist? (What if it's malformed?)

[bcressey]

This is a bit of a misleading comment:

• it only applies to system services using the AWS SDK for Go
• those services can already set this variable and load the config if they want

I sort of understand the rationale for applying this as a system-wide setting but it might be good to state it here.

[arnaldo2792]

Can you confirm that this configuration does not leak into the environment for orchestrated containers?

It doesn't:

bash-5.1# systemctl show ecs.service | grep AWS_SDK_LOAD_CONFIG -q && echo "Set!"
Set!
bash-5.1# docker ps
CONTAINER ID   IMAGE       COMMAND            CREATED         STATUS         PORTS     NAMES
52c2f0a4005e   fedora:35   "sleep infinity"   4 minutes ago   Up 4 minutes             ecs-fedora-19-fedora-92f692fdbaa9cde89601
bash-5.1# docker exec -it 52c2f0a4005e bash
[root@52c2f0a4005e /]# env | grep AWS_SDK_LOAD_CONFIG || echo "Not Set!"
Not Set!
[root@52c2f0a4005e /]#

I'm still confirming your other question.

[arnaldo2792]

Have you confirmed via code inspection that this does nothing if the config file doesn't exist? (What if it's malformed?)

I created a simple Go client like so:

package main

import (
        "fmt"

        "github.com/aws/aws-sdk-go/aws/session"
        "github.com/aws/aws-sdk-go/service/sts"
)

func main() {
        sess := session.Must(session.NewSession())
        svc := sts.New(sess)
        input := &sts.GetCallerIdentityInput{}

        result, err := svc.GetCallerIdentity(input)

        if err != nil {
                fmt.Printf("Error!: %v", err)
                return
        }

        fmt.Println(result)
}

And tested as follows with AWS_SDK_LOAD_CONFIG=true

• If ~/.aws/.config is missing, the client doesn't fail and uses other credentials providers in the chain (e.g. ~/.aws/credentials)
• If ~/aws/.config is malformed (as shown below), the client succeeds and in reads valid configurations only, so in the example provided, the client attempted to use the FIPS endpoints:

[default]
use_fips_endpoint = true
# use_fips_endpoint = false
not_valid =
incomm
plete

Error!: RequestError: send request failed
caused by: Post "https://sts-fips.aws-global.amazonaws.com/": dial tcp: lookup sts-fips.aws-global.amazonaws.com: no such host⏎

WithAWS_SDK_LOAD_CONFIG=false, the client still reads ~/.aws/credentials:

❯ go run main.go
{
  Account: "XXXXXXXXXXXX",
  Arn: "arn:aws:sts::XXXXXXXXXXXX:assumed-role/<role>/<>",
  UserId: "<>"
}

I tested similar cases in the ECS agent (e.g. malformed ~/.aws/config) and the ECS agent still connected to the cluster.