_NAME --key=AWS_ACCESS_KEY --secret=AWS_SECRET_KEYa ZenML secret can hold the AWS credentials and then be referenced in the S3 Artifact Store configuration attributes:Copyzenml secret create aws --aws_access_key_id=AWS_ACCESS_KEY --aws_secret_access_key=AWS_SECRET_KEY
zenml artifact-store register s3 --flavor s3 --path=s3://BUCKET_NAME --key='{{aws.aws_access_key_id}}' --secret='{{aws.aws_secret_access_key}}'

an even better version is to reference the secret itself in the S3 Artifact Store configuration:Copyzenml secret create aws --aws_access_key_id=AWS_ACCESS_KEY --aws_secret_access_key=AWS_SECRET_KEY
zenml artifact-store register s3 --flavor s3 --path=s3://BUCKET_NAME --authentication_secret=aws

All these options work, but they have many drawbacks:

first of all, not all Stack Components support referencing secrets in their configuration attributes, so this is not a universal solution.

some Stack Components, like those linked to Kubernetes clusters, rely on credentials being set up on the machine where the pipeline is running, which makes pipelines less portable and more difficult to set up. In other cases, you also need to install and set up cloud-specific SDKs and CLIs to be able to use the Stack Component.

people configuring and using Stack Components linked to cloud resources need to be given access to cloud credentials, or even provision the credentials themselves, which requires access to the cloud provider platform and knowledge about how to do it.

in many cases, you can only configure long-lived credentials directly in Stack Components. This is a security risk because they can inadvertently grant access to key resources and services to a malicious party if they are compromised. Implementing a process that rotates credentials regularly is a complex task that requires a lot of effort and maintenance.