AWS plugin: agent cannot use MFA / chained assume-role profiles (AssumeRoleTokenProvider not set)

[mmassenzio]

Summary

The AWS plugin cannot authenticate when the configured AWS profile is a chained assume-role that requires MFA. The agent's AWS SDK config load fails because no AssumeRoleTokenProvider is wired up, so the SDK has no way to obtain the MFA token non-interactively.

Environment

• formae 0.83.2 (local agent, SQLite datastore), macOS arm64
• AWS resource plugin aws@0.1.4
• AWS CLI v2 present on the host

What happens

With a target that resolves to an MFA/assume-role profile, discovery and apply spam errors like:

ERR Failed to list resources for AWS::S3::AccessPoint in target default-aws-target:
loading AWS config: assume role with MFA enabled, but AssumeRoleTokenProvider session option not set.

Every resource type fails the same way, so nothing can be discovered or applied.

Repro

~/.aws/config with a chained, MFA-gated role (names generalized):

[profile base]
# static creds or SSO

[profile base-mfa-role]
role_arn      = arn:aws:iam::<acct-a>:role/devops-role
mfa_serial    = arn:aws:iam::<acct-a>:mfa/<device>
source_profile = base

[profile dev-role]
role_arn       = arn:aws:iam::<acct-b>:role/devops-role
source_profile = base-mfa-role

Forma target:

config = new aws.Config {
    region  = "us-west-2"
    profile = "dev-role"
}

Start the agent and apply/discover → the error above.

Root cause

The agent loads AWS config with the profile but does not register a token provider (config.WithAssumeRoleCredentialOptions / stscreds.AssumeRoleOptions.TokenProvider). The Go SDK therefore cannot satisfy the mfa_serial requirement. Notably, the agent also does not read the AWS CLI's assume-role cache (~/.aws/cli/cache), so authenticating via the CLI first does not help either.

Things that do not fix it:

• aws sso login / pre-authenticating the profile in another shell (the SDK still tries to assume the role itself).
• Setting AWS_PROFILE — with a profile set, the SDK re-enters the MFA chain and ignores static env creds.

Workaround

Let the AWS CLI resolve the chain (it prompts for MFA and caches), export the resulting temporary credentials as env vars, and start the agent in that shell. Do not pin profile in the forma (a pinned profile re-enters the MFA chain and ignores the env creds):

unset AWS_PROFILE AWS_DEFAULT_PROFILE
eval "$(aws configure export-credentials --profile dev-role --format env)"
formae agent start

Set only region in the target config. The exported session is temporary (~1h); re-export and restart when it expires.

Suggested fix

Any of:

1. Register an AssumeRoleTokenProvider (e.g. stscreds.StdinTokenProvider) when loading AWS config so interactive MFA works for local agents.
2. Honor the AWS CLI assume-role cache (~/.aws/cli/cache) / credential_process.
3. Document the temporary-credentials workaround in the AWS plugin credentials section, and note that profile should be omitted when supplying creds via env.

[mmassenzio]

Update: attempted fix does not work (see closed PR platform-engineering-labs/formae-plugin-aws#145)

The obvious fix — registering stscreds.StdinTokenProvider via WithAssumeRoleCredentialOptions in the AWS plugin's ToAwsConfig — does not work, because the plugin runs as a headless child process of the agent (PluginProcessSupervisor). Its os.Stdin is a pipe controlled by the agent, not a TTY, so:

• an interactive MFA prompt can never reach the user, and
• gating on isTerminal(os.Stdin) makes the provider a no-op inside the plugin (confirmed: patch compiled into the plugin, error unchanged, no prompt).

So any fix must be non-interactive. Candidates:

1. Honor the AWS CLI assume-role / SSO cache (~/.aws/cli/cache) so a session the user already established via the CLI is reused. aws-sdk-go-v2 doesn't do this natively.
2. Support credential_process profiles (SDK-native) and document it.
3. Agent-mediated prompt: the agent owns the TTY — it could prompt for the MFA code and pass it to the plugin's TokenProvider over the plugin protocol. Bigger change.

Meanwhile the documented workaround stands: don't pin profile; export temporary credentials (aws configure export-credentials --format env) into the agent's environment.

[discount-elf]

Thank you for the issue submission! We will dig into this and decide how we can support this.

[mmassenzio]

Of course - as you can see, I did try an approach, but as it requires a TTY, it wasn't working with the current formae server.
Let me know if I can do anything to help here, I'm really keen to see if we can adopt formae for at least a subset of our clusters.

[discount-elf]

There is some complex work that we will be doing that will shift most things into the agent from the CLI. At that point we can probably implement request/response workflow that would allow a prompt to be propagated up via the plugin.

For now however we should probably implement 1. I need to understand the security implications of this, to understand the cli/cache structure, as it probably wouldn't be great if the plugin re-used any session and not the one defined in a credential profile. We would want to gate this behavior in the target config with a bool: reuseCliCache or similar.