Would Enhanced AWS Authentication Improve Security and User Experience in Pipedream Back-End?

This topic was automatically generated from Slack. You can find the original thread here.

Before officially posting this elsewhere, I was wondering if this feature request would make sense within the Pipedream back-end:

Enhanced AWS Authentication
• As an alternative to access+secret keys to authenticate against the AWS API, why not allow to securely assume a role from the customer AWS account in the Pipedream AWS account?
• For this, each Pipedream account would need a unique instance profile which is used to run their workflows
◦ Something like this: arn:aws:iam::<PIPEDREAM_AWS_ACCOUNT_ID>:instance-profile/<PIPEDREAM_INSTANCE_PROFILE_UNIQUE_TO_CUSTOMER_ACCOUNT>
• Then, in the customer AWS account, we could grant permission for the above instance profile from Pipedream to assume certain roles within the account.
◦ When creating a session from an STS assume role call, it returns temporary credentials (access+secret key).
◦ So presumably, the rest of the implementation for the AWS app wouldn’t have to changes; it would either use a long-living access+secret key, or a temporary one.
• When configuring the AWS app in Pipedream, we would just have to enter the ARN of the role to assume from our AWS account (which contains the AWS account ID).
◦ Ex: arn:aws:iam::<CUSTOMER_AWS_ACCOUNT_ID>:role/<NAME_OF_THE_ROLE_TO_ASSUME>
• Then, no need to rotate access+secret keys, which should make most IT teams pretty happy! :ok_hand:
• And for plans below the Business tier (who don’t have access to the VPC feature), it would provide an added layer of security (it ensures that the requests come from a specific Pipedream account, based on the unique instance profile).
◦ It’s even presumably a little more secure than IP security (since IPs can be spoofed, but I’m pretty sure the AWS API is not vulnerable to this, because they use a handshake in the authentication process).

:100: . We have a design for this internally and it’s on the backlog

Is this blocking you or are you able to use access keys in your org?

We can use keys. :+1:

But this would definitely be an improvement!

We’re migrating old stuff to AWS right now, and we’re trying to get rid of as many keys as possible. :grin:

Otherwise, new org process is that we have to rotate keys every 3 months.

Fortunately, Pipedream makes the rotation pretty quick & painless. :+1: (not so for many other services…)

ack that’s useful feedback, thanks