michaelkoepf commented on PR #1245: URL: https://github.com/apache/fluss/pull/1245#issuecomment-3590042653
@leekeiabstraction _very strong_ catch. > Were fs.s3a.secret.key/access.key in the properties during the second run? yes, that was the manual test scenario: "but leave the credentials (access key, secret) there". verification check, kind of. but i did miss out on the `fs.s3a.assumed.role.credentials.provider` behavior, indeed. > Additional question that might help my understanding, what do we expect the user experience to look like here when they disable token delegation and forgot to set credential provider? we would have treated this as a configuration error, which causes s3 access to fail. this mechanism was introduced as a safety net. users should prefer short-term credentials, as we discourage embedding long-term credentials in the client. if they want to use long-term credentials in the client, they should be explicit about it. any ideas how we can achieve this despite the behavior of `fs.s3a.assumed.role.credentials.provider`? maybe we can set `fs.s3a.assumed.role.credentials.provider` to a credential provider that uses short-term credentials and remove the long-term credential providers from `s3.aws.credentials.provider` default chain (instead of setting it to blank)? -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
