Skip to content
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

Support AWS default credential chain for Kinesis Source #17849

Closed
psheets opened this issue Jul 29, 2024 · 4 comments
Closed

Support AWS default credential chain for Kinesis Source #17849

psheets opened this issue Jul 29, 2024 · 4 comments

Comments

@psheets
Copy link
Contributor

psheets commented Jul 29, 2024

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

@xiangjinwu
Copy link
Contributor

Prior context: #11086

@psheets
Copy link
Contributor Author

psheets commented Jul 30, 2024

@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.

@psheets
Copy link
Contributor Author

psheets commented Aug 5, 2024

Thoughts on implementation:

  • 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.

@fuyufjh
Copy link
Member

fuyufjh commented Aug 19, 2024

closed by #17933

@fuyufjh fuyufjh closed this as completed Aug 19, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants