### Release notes The GitLab CI external secrets feature should support retrieving secrets from AWS services such as Secrets Manager, Systems Manager Parameter Store, and S3. ### Problem to solve The GitLab CI external secrets engine is great, but currently, it is limited to HashiCorp Vault, GCP, and Azure Key Vault. Users relying on AWS Cloud have no option to use it at the moment and must retrieve secrets manually with tools like the AWS CLI. This has caveats, as GitLab is not able to mask secrets in pipeline jobs, and you must extend your build container with the necessary tools. ### Proposal There should be an option to retrieve secrets from the following AWS services: - AWS Secrets Manager: AWS Secrets Manager helps you manage, retrieve, and rotate database credentials, application credentials, OAuth tokens, API keys, and other secrets throughout their lifecycles. Many AWS services store and use secrets in Secrets Manager. See issue https://gitlab.com/gitlab-org/gitlab/-/issues/29047. - AWS Systems Manager Parameter Store: Parameter Store, a capability of AWS Systems Manager, provides secure, hierarchical storage for configuration data management and secrets management. You can store data such as passwords and database connection strings as plain text or encrypted data. See issue https://gitlab.com/gitlab-org/gitlab/-/issues/434280. - AWS S3: The object storage of AWS. - ~~STS ASSUME ROLE WITH WEBIDENTITY: Exchange Gitlab token for temporary AWS credentials and return them as File.~~ Not needed anymore It should be possible to use different authentication methods, such as: - The authentication chain of the AWS SDK (environment variables, instance profiles, task roles, IRSA, etc.) - Assume Role with WebIdentityToken to leverage the OIDC token of GitLab ### Intended users This feature will be beneficial for the following GitLab personas: - Sasha (Software Developer): To seamlessly integrate and retrieve secrets without manual intervention, enhancing productivity and security in their workflows. - Priyanka (Platform Engineer): To manage and automate the retrieval of secrets securely across different environments and applications. - Sidney (Systems Administrator): To streamline the process of managing and accessing secrets, reducing the overhead of manual secret handling. - Rachel (Release Manager): To ensure that the pipeline jobs can securely access the necessary secrets without exposing them, thereby maintaining the integrity and confidentiality of the deployment processes. - Ingrid (Infrastructure Operator): To efficiently handle secrets management within the infrastructure, ensuring secure and automated access to necessary credentials and configurations. - Isaac (Infrastructure Engineer): To leverage secure authentication methods and enhance the security posture by integrating AWS secrets management into their CI/CD pipelines. ### Feature Usage Metrics Right now, I don't know - even if I am sure, there are metrics written by GitLab for the use of the specific secrets engine ### Does this feature require an audit event? I think in the same way, as If I would use other secret engines.