New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Destination S3: STS Assume Role Authentication #38143
base: master
Are you sure you want to change the base?
Conversation
…eep credentials refreshed for a particular Role ARN. The Role ARN comes from the connector spec and is configured. Airbyte credentials are used to configure the initial STS Client, then the credentials aquired through the STS Assume Role are used for subsequent service requests. This means that all calls to S3 are made with the temporary credentials aquired through STS. The temporary credentials are refreshed using the credentials provided to the connector through the environment.
The latest updates on your projects. Learn more about Vercel for Git ↗︎ 1 Ignored Deployment
|
*/ | ||
class S3AssumeRoleCredentialConfig(private val roleArn: String) : S3CredentialConfig { | ||
// TODO: Verify this env var, I think it might actually be AWS_ASSUME_ROLE_EXTERNAL_ID or something like that. | ||
private val externalId: String? = System.getenv("AWS_EXTERNAL_ID") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
should that be in the config?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This has to be set by us to a unique value for each customer. It cannot come from the config because that would allow for a confused deputy problem. This coming from the environment solves this problem because it means that even if you were to use an ARN that you don't own, the externalId will never match the customer's Role rules as the externalId will not match.
For example:
Customer A has configured a role with id: 1234 and externalId: abcd
Customer B has configured a role with id: 5678 and externalId: zxyw
If Customer A sets an ARN of 5678, the platform will still inject abcd as the externalId, so the STS Assume Role will fail because the externalId was not zxyw. The key here is that Airbyte MUST provide the externalId to the connector and the externalId MUST NOT be configurable.
It is not required that the externalId (or the role ARN) be secret.
More info here: https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-user_externalid.html#external-id-purpose
...kotlin/io/airbyte/cdk/integrations/destination/s3/credential/S3AssumeRoleCredentialConfig.kt
Show resolved
Hide resolved
This stack of pull requests is managed by Graphite. Learn more about stacking. |
Add the AssumeRoleCredentialConfig that will use STS Assume Role to keep credentials refreshed for a particular Role ARN. The Role ARN comes from the connector spec and is configured. Airbyte credentials are used to configure the initial STS Client, then the credentials aquired through the STS Assume Role are used for subsequent service requests. This means that all calls to S3 are made with the temporary credentials aquired through STS. The temporary credentials are refreshed using the credentials provided to the connector through the environment.