Background

Currently, to use Amazon S3 as backend storage for LFS objects in Bitbucket, the following properties must be set in bitbucket.properties to authenticate and configure the S3 bucket:

bitbucket.filestore=s3
plugin.bitbucket-filestore-s3.bucket=<bucket_name>
plugin.bitbucket-filestore-s3.region=us-east-1
plugin.bitbucket-filestore-s3.access-key=<aws_access_key>
plugin.bitbucket-filestore-s3.secret-key=<aws_secret_key>

This approach requires storing long-lived credentials in plain text within the properties file or in the values.yaml file when deploying on Kubernetes, which poses a security risk.

Suggested Improvement

Leverage the AWS SDK's default credential provider chain to discover credentials, rather than requiring explicit access and secret keys in configuration files. The AWS SDK default credential chain includes:

1. Java System Properties: aws.accessKeyId and aws.secretAccessKey
2. Environment Variables: AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY
3. Web Identity Token Credentials: Provided through system properties or environment variables
4. Credential Profiles File: Located at the default location (~/.aws/credentials), shared by all AWS SDKs and the AWS CLI
5. Amazon ECS Credentials: Provided if the AWS_CONTAINER_CREDENTIALS_RELATIVE_URI environment variable is set and the security manager allows access
6. EC2 Instance Profile Credentials: Delivered through the Amazon EC2 metadata service (IMDSv2)

By supporting the full AWS SDK credential chain, Bitbucket deployments on Kubernetes could utilize EKS Pod Identity or IAM Role for Service Accounts (IRSA), removing the need to store sensitive keys in properties or YAML files.

Benefits

1. Enhanced security by eliminating the need to store long-lived credentials in plain text
2. Greater flexibility in deployment environments, particularly Kubernetes/EKS
3. Alignment with AWS best practices for credential management