Bug: sam delete doesn't seem to respect MFA session duration, or doesn't know where to find cached session

[rhbecker]

Description:

Every sam delete invocation requires entry of a new token. This does not occur with sam deploy using the same profile.

Maybe there's some small chance this issue shares a root cause with what's being addressed in PR #6551.

This issue seems similar to the resolved #1623, and perhaps the resolved #1682.

Steps to reproduce:

1. Configure an AWS CLI profile with MFA enabled.
2. Switch into that profile.
3. Execute a sam deploy.
4. Enter the requested code.
5. Try another sam deploy just to see you're not asked for the code again.
6. Execute a sam delete; you're prompted for a code regardless of whether still within the expected session duration.

Observed result:

The prompt for the code comes after answering the following question, which might indicate the location of the issue ...

Are you sure you want to delete the stack in the region us-west-2 ? [y/N]

Expected result:

The sam delete command should know how to locate the session cache and should respect duration_seconds settings configured for the AWS CLI profile, just as sam deploy seems to.

Additional environment details (Ex: Windows, Mac, Amazon Linux etc)

The config for the profile I'm using ...

[profile example.mfa]
duration_seconds = 43200
mfa_serial = arn:aws:iam::<REDACTED>:mfa/testuser
output = yaml
region = us-west-2
role_arn = arn:aws:iam::<REDACTED>:role/<REDACTED>
role_session_name = example
source_profile = example

The output of sam --info ...

{
  "version": "1.107.0",
  "system": {
    "python": "3.11.3",
    "os": "Linux-5.15.90.1-microsoft-standard-WSL2-x86_64-with-glibc2.31"
  },
  "additional_dependencies": {
    "docker_engine": "Not available",
    "aws_cdk": "Not available",
    "terraform": "Not available"
  },
  "available_beta_feature_env_vars": [
    "SAM_CLI_BETA_FEATURES",
    "SAM_CLI_BETA_BUILD_PERFORMANCE",
    "SAM_CLI_BETA_TERRAFORM_SUPPORT",
    "SAM_CLI_BETA_RUST_CARGO_LAMBDA"
  ]
}

[lucashuy]

Thanks for raising this issue! I can reproduce the problem where sam delete doesn't seem to be using the same cache as sam deploy. We'll need to dig a little deeper into what delete does differently than deploy to find the root cause.