As @Marcin suggested in order to assume a IAM role you still need some way to authenticate to AWS before that (whether that's going to be by using a programmatic access for an IAM user or via federation from external service like Cognito, ADFS, AzureAD, Duo, Okta, etc).
As per the documentation:
You can then specify a source_profile that
points to a separate named profile that contains IAM user credentials
with permission to use the role. In the previous example, the
marketingadmin profile uses the credentials in the user1 profile. When
you specify that an AWS CLI command is to use the profile
marketingadmin, the AWS CLI automatically looks up the credentials for
the linked user1 profile and uses them to request temporary
credentials for the specified IAM role. The CLI uses the
sts:AssumeRole operation in the background to accomplish this. Those
temporary credentials are then used to run the requested AWS CLI
command. The specified role must have attached IAM permission policies
that allow the requested AWS CLI command to run.
When you run commands using a profile that specifies an IAM role, the
AWS CLI uses the source profile's credentials to call AWS Security
Token Service (AWS STS) and request temporary credentials for the
specified role. The user in the source profile must have permission to
call sts:assume-role for the role in the specified profile. The role
must have a trust relationship that allows the user in the source
profile to use the role. The process of retrieving and then using
temporary credentials for a role is often referred to as assuming the
role.
Based on your comments and explanation (the one in which you are saying that you are still providing access and secret key as env var) and the error you have shared in one of your comments:
"Error in assuming role" [Profile] role_arn = role output = json region = us-east-1 role_session_name = rolesession credential_source = Environment
I'm assuming that the IAM user which you try to source if there is one present at all doesn't have permissions to assume the role_arn you are referring to.
There has to be a trust relationship between the IAM user and the role it tries to assume:
Policy attached to IAM user:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::123456789012:envuser"
},
"Action": "sts:AssumeRole"
}
]
}
Trust policy on the role itself:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
**"Action": "sts:AssumeRole",**
"Resource": "arn:aws:iam::123456789012:role/marketingadminrole"
}
]
}
On how to use those in .NET there are good explanations and examples in this answer and in this blog post.