PowerShell Assume Role Credentials Presists in subsequent execution

[swordfish291]

Hello Team,

Thank for the amazing work that has been put into this. It really makes alot easier with these layers to run powershell code.

I am having an issue. I have a function that is assigned an execution role(LambdaExecutionRole) that assumes another role(DeleteSnapshotsRole) in another account using Use-STSRole cmdlet. I am able to execute the function the first time after modifying the code however when the function is executed the second time it returns the error DeleteSnapshotsRole is not authorized to assume DeleteSnapshotsRole. For some reason after the first execution the credentials presist in the function and second execution it uses the assumed role from the previous execution. Is there any configuration we need to set in the layers to flush the environment variables after each execution? I have tried to set the AWS credentials to null after the function is executed but these null values are getting picked up in subsequent executions.

Here is the code:

function delete-ebs-snapshots {
    Import-Module AWS.Tools.SecurityToken
    Import-Module AWS.Tools.Common
    Import-Module AWS.Tools.S3
    Import-Module AWS.Tools.Organizations
    $creds = Use-STSRole -RoleArn "arn:aws:iam::xxxxxxxx:role/DeleteSnapshotsRole" -RoleSessionName "delete-ebs-lambda" -Region us-west-2
    $env:AWS_ACCESS_KEY_ID = $creds.Credentials.AccessKeyId
    $env:AWS_SECRET_ACCESS_KEY = $creds.Credentials.SecretAccessKey
    $env:AWS_SESSION_TOKEN = $creds.Credentials.SessionToken
    # Get the account listing
    $accounts = Get-ORGAccountList
    $accounts
    $env:AWS_ACCESS_KEY_ID = $null
    $env:AWS_SECRET_ACCESS_KEY = $null
    $env:AWS_SESSION_TOKEN = $null
}

Thanks Abdul

[julianwood]

Hi, glad you're finding the PowerShell custom runtime useful. Are you not wanting to assume the role on subsequent invokes, or wanting to assume another role? The environment re-use is part of how Lambda works. This allows you to improve performance by re-using the execution environment. See more at: https://docs.aws.amazon.com/lambda/latest/dg/lambda-runtime-environment.html

Here is some more information on assuming roles: https://aws.amazon.com/premiumsupport/knowledge-center/iam-assume-role-error/ and a workshop which you can have a look at too: https://www.wellarchitectedlabs.com/security/300_labs/300_lambda_cross_account_iam_role_assumption/

Not sure what you're trying to achieve but perhaps you can store the $env:AWS_ACCESS_KEY_ID, $env:AWS_SECRET_ACCESS_KEY and $env:AWS_SESSION_TOKEN before you reset them to the assumes role details and set them back, rather than clearing them with $null

[swordfish291]

This has worked:

"perhaps you can store the $env:AWS_ACCESS_KEY_ID, $env:AWS_SECRET_ACCESS_KEY and $env:AWS_SESSION_TOKEN before you reset them to the assumes role details and set them back, rather than clearing them with $null"

Thank you @julianwood

[austoonz]

@swordfish291

Just adding a comment as there's simpler solution than updating the default environment variables.

Pass $creds.Credentials to the -Credential parameter of any AWS cmdlet. Also, when importing any of the AWS.Tools.* modules, AWS.Tools.Common is imported by default.

For example:

Import-Module AWS.Tools.SecurityToken
Import-Module AWS.Tools.Organizations

$creds = Use-STSRole -RoleArn "arn:aws:iam::xxxxxxxx:role/DeleteSnapshotsRole" -RoleSessionName "delete-ebs-lambda" -Region us-west-2

# Get the account listing
$accounts = Get-ORGAccountList -Credential $creds.Credentials
$accounts