You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently in GrowthBook, one can configure an Athena Datasource, however this is a problem for multi-tenant uses of GrowthBook.
Currently with Athena, you have the option of:
Use auto-detect which leverages the instance's IAM instance profile to obtain credentials and interact with Athena, OR
You can use an IAM user created for programmatic access (secret key + access key) and embed them in the connection.
The above two will work fine, but I suggest a rework of this to allow for much more complicated permission setups.
The reason I say this is because:
with auto-detect this basically requires the IAM role to have access to everything it may need to query. Which as a shared resource could reveal datasets to users who should not have access to see those datasets. Currently you can only set a default database, which doesn't stop users querying other databases in Athena.
on the flip-side, managing access keys and secrets keys specifically for each connection is a major pain, not to mention all the fun involved with revoking those keys if they should be leaked. As you can probably imagine, this gets very complicated the more Athena connections you need - and rotating them regularly would be hard.
What would work much better?
I suggest a third option maybe named Assume Role which leverages the current IAM role (the same role found during auto-detect) and uses this role to assume another (the one supplied in connection setup) which performs an aws sts assume-role to get temporary credentials via STS. Once this is done, the temporary credentials can be used for the process to interact with Athena.
Ultimately, this means we can completely lock down the instance's role to talk with Athena, and only allow it to use Athena through specially provisioned roles, which restrict the resources it can operate on.
With this feature we could actually consider introducing the Athena datasource to our users.
The text was updated successfully, but these errors were encountered:
Description of Feature
Hi,
Currently in GrowthBook, one can configure an Athena Datasource, however this is a problem for multi-tenant uses of GrowthBook.
Currently with Athena, you have the option of:
auto-detect
which leverages the instance's IAM instance profile to obtain credentials and interact with Athena, ORThe above two will work fine, but I suggest a rework of this to allow for much more complicated permission setups.
The reason I say this is because:
auto-detect
this basically requires the IAM role to have access to everything it may need to query. Which as a shared resource could reveal datasets to users who should not have access to see those datasets. Currently you can only set a default database, which doesn't stop users querying other databases in Athena.What would work much better?
I suggest a third option maybe named
Assume Role
which leverages the current IAM role (the same role found duringauto-detect
) and uses this role to assume another (the one supplied in connection setup) which performs anaws sts assume-role
to get temporary credentials via STS. Once this is done, the temporary credentials can be used for the process to interact with Athena.Ultimately, this means we can completely lock down the instance's role to talk with Athena, and only allow it to use Athena through specially provisioned roles, which restrict the resources it can operate on.
With this feature we could actually consider introducing the Athena datasource to our users.
The text was updated successfully, but these errors were encountered: