Taragolis commented on code in PR #29623:
URL: https://github.com/apache/airflow/pull/29623#discussion_r1116025807
##########
airflow/providers/amazon/aws/hooks/base_aws.py:
##########
@@ -312,19 +312,35 @@ def _get_web_identity_credential_fetcher(
base_session = self.basic_session._session or
botocore.session.get_session()
client_creator = base_session.create_client
federation =
self.extra_config.get("assume_role_with_web_identity_federation")
- if federation == "google":
- web_identity_token_loader =
self._get_google_identity_token_loader()
- else:
- raise AirflowException(
- f'Unsupported federation: {federation}. Currently "google"
only are supported.'
- )
+
+ web_identity_token_loader = (
+ {
+ "file": self._get_file_token_loader,
+ "google": self._get_google_identity_token_loader,
+ }.get(federation)()
+ if type(federation) == str
+ else None
+ )
Review Comment:
> I do not find this argument compelling at all. If a user was so inclined
they could simply obtain an access key id, secret and session token by calling
AssumeRoleWIthWebIdentity with the STS API endpoint directly. I fail to see how
this raises any security concerns.
Yep what you write is is controlled by IAM permissions and required initial
boto3/botocore session and STS.Client.
Your proposal more about how obtain this initial session by provide custom
filepath and role-arn from the connection, which can not be limited by
administrators. And in situation if one pod have multiple web identity token
files mounted user might easily change default AWS SDK behaviour and get
information different rather than initially specified for `AWS_ROLE_ARN` and
`AWS_WEB_IDENTITY_TOKEN_FILE`.
I want to highlight that use this env variables it is expected integration
according to AWS docs, I can't find any other ways:
- https://docs.aws.amazon.com/eks/latest/userguide/pod-configuration.html
-
https://aws.amazon.com/blogs/opensource/introducing-fine-grained-iam-roles-service-accounts/
If we look throught the `botocore` code, there is no way to legit redefine
this behaivior, rather than use profiles.
And just wondering what is wrong with general approach?
pod has `AWS_ROLE_ARN` for example `arn:aws:iam::111122223333:role/my-role`
and `AWS_WEB_IDENTITY_TOKEN_FILE` for example
`/var/run/secrets/eks.amazonaws.com/serviceaccount/token`, in this case AWS
Connection obtain initial session with role
`arn:aws:iam::111122223333:role/my-role` and if it required to switch to
another like `arn:aws:iam::5555666677778888:role/my-role` than
you/administrator need to allow through AWS IAM access to assume
`arn:aws:iam::5555666677778888:role/my-another-role` from
`arn:aws:iam::111122223333:role/my-role`. As soon as you have this everything
you only need to specify in connection Extra `{"role_arn":
"arn:aws:iam::5555666677778888:role/my-another-role"}` and **do not specify**
`aws_access_key_id`, `aws_secret_access_key`, `aws_session_token`,
`profile_name`.
This how it works in the other cases when need to switch role, e.g. in EC2
Instance with attached IAM profile or ECS Task
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
