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
Is your feature request related to a problem? Please describe.
Kinesis source requires aws.credentials.access_key_id and aws.credentials.secret_access_key. If risingwave is running on a k8s cluster, it is better practice to attache a service account with the appropriate permissions to assume an iam role with the least required permissions.
Describe the solution you'd like
Instead of erroring out if the aws credentials are not provided, default to the AWS default credential chain.
Describe alternatives you've considered
An alternative would be to include a new aws config field aws.s3.use_instance_profile, similar to how starrock handles connectors. This would add another field, however.
Additional context
No response
The text was updated successfully, but these errors were encountered:
@xiangjinwu
Reviewed the related threads. Is enforcing ak/sk at the table create level the best way to handle access concerns? This makes it difficult to operate in an environment that relies on IAMs for access control.
If the want is to separate the source permissions and the service permissions, having an option to set a base role arn as part of the start up config could accomplish that. That role could be created with a limited scope of permissions that does not include the state store. The service account running the pods would need permissions to assume the base role. Managing / rotating keys for a source is a non-starter for a production deployment.
The service account for risingwave has permission to assume other iam roles. We do not need to worry about updating this each time we add a new source.
Add an envar like RW_BASE_ROLE to pass an arn for sources to use.
OR
use the default credential provider chain is the auth keys are not set and aws.credentials.role.arn is present in the config.
Using a base role would all the system operations of risingwave to use he service account role which would have access to the state s3 bucket, and the base role would not have permissions for that.
Is your feature request related to a problem? Please describe.
Kinesis source requires
aws.credentials.access_key_id
andaws.credentials.secret_access_key
. If risingwave is running on a k8s cluster, it is better practice to attache a service account with the appropriate permissions to assume an iam role with the least required permissions.Describe the solution you'd like
Instead of erroring out if the aws credentials are not provided, default to the AWS default credential chain.
Describe alternatives you've considered
An alternative would be to include a new aws config field
aws.s3.use_instance_profile
, similar to how starrock handles connectors. This would add another field, however.Additional context
No response
The text was updated successfully, but these errors were encountered: