refactor: use KAFKA_S3_* env vars instead of AWS-specific names in Helm chart

[kincoy]

What this PR does

This PR updates the AutoMQ Helm chart to use the more semantically accurate environment variable names:

• KAFKA_S3_ACCESS_KEY
• KAFKA_S3_SECRET_KEY

instead of the AWS-specific:

• AWS_ACCESS_KEY_ID
• AWS_SECRET_ACCESS_KEY

This change aligns better with AutoMQ’s multi-cloud and generic object storage positioning, avoiding confusion that these variables are AWS-only.

Why this is needed

the Helm chart currently defaults to the AWS-specific ones. This may mislead users to believe that only AWS S3 is supported, whereas in reality, AutoMQ works with any S3-compatible storage.

Using KAFKA_S3_* as default improves clarity and neutrality, especially for users deploying on Tencent Cloud, MinIO, or other providers.

[CLAassistant]

All committers have signed the CLA.

[kincoy]

While the AutoMQ code already supports both naming conventions:

if ("KAFKA_S3_ACCESS_KEY".equals(env.getName()) || "AWS_ACCESS_KEY_ID".equals(env.getName())) { ... }

[superhx]

Because AutoMQ only support S3 compatible storage. So it's reasonable to use AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY

[kincoy]

Because AutoMQ only support S3 compatible storage. So it's reasonable to use AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY

Thanks! Just a quick note — for non-AWS users (like Alibaba Cloud), AWS_ACCESS_KEY_ID can be confusing, since it looks AWS-specific.
For example, some users might assume there should be something like ALI_ACCESS_KEY_ID instead.
Something like KAFKA_S3_ACCESS_KEY might feel more vendor-neutral for S3-compatible setups.

[superhx]

Because AutoMQ only support S3 compatible storage. So it's reasonable to use AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY

Thanks! Just a quick note — for non-AWS users (like Alibaba Cloud), AWS_ACCESS_KEY_ID can be confusing, since it looks AWS-specific. For example, some users might assume there should be something like ALI_ACCESS_KEY_ID instead. Something like KAFKA_S3_ACCESS_KEY might feel more vendor-neutral for S3-compatible setups.

The old config value is KAFKA_S3_ACCESS_KEY. But based on past experience, most users are familiar with the S3 SDK and prefer the configuration mode using AWS_ACCESS_KEY_ID. Additionally, more advanced users will use AWS's authentication chain (Env, Instance Profile, STS). So we modified the configuration from KAFKA_S3_ACCESS_KEY to AWS_ACCESS_KEY_ID.

[kincoy]

The old config value is KAFKA_S3_ACCESS_KEY. But based on past experience, most users are familiar with the S3 SDK and prefer the configuration mode using AWS_ACCESS_KEY_ID. Additionally, more advanced users will use AWS's authentication chain (Env, Instance Profile, STS). So we modified the configuration from KAFKA_S3_ACCESS_KEY to AWS_ACCESS_KEY_ID.

That makes sense, thanks for the explanation! I’ll close this now.