AWS CLI 기반 S3 인증 구조 개선

들어가며

기존에는 S3 연동을 위해 아래처럼 application-local.yml에 AWS Access Key와 Secret Key를 직접 넣는 방식을 사용하려고 했다.

cloud:
  aws:
    credentials:
      access-key: xxx
      secret-key: xxx

 

하지만 이 방식은 로컬에서는 간단하게 사용할 수 있지만,

• 설정 파일 관리 실수
• Git 추적 위험
• 협업 시 보안 문제

등이 발생할 수 있었다.

 

특히 팀 프로젝트 환경에서는 “로컬 설정 파일이라 괜찮겠지”라고 생각하다가 실수로 커밋되는 경우도 충분히 발생할 수 있다.

그래서 이번에는 AWS CLI 기반 인증 방식과 AWS SDK Credential Chain 구조를 적용하여 로컬 설정 파일 의존도를 제거하는 방향으로 개선하게 되었다.

---

문제 상황

AWS CLI 설치 후에도 aws 명령어가 동작하지 않았다

처음에는 아래처럼 AWS CLI를 설치하였다.

winget install --id Amazon.AWSCLI -e

 

하지만 설치 직후 아래 명령어가 정상 동작하지 않았다.

aws configure
bash: aws: command not found

---

원인 분석

Git Bash 세션에 PATH가 반영되지 않은 상태

AWS CLI 설치 자체는 정상적으로 완료된 상태였다.

하지만 현재 실행 중이던 Git Bash 세션에는 PATH 정보가 아직 반영되지 않아 aws 명령 자체를 인식하지 못하고 있었다.

---

해결 방법

Git Bash 재실행 후 AWS CLI 정상 인식

Git Bash를 완전히 종료 후 다시 실행하였다.

aws --version

 

이후 아래 명령어를 통해 정상 설치 여부를 확인하였다.

aws-cli/2.34.45 Python/3.14.4 Windows/11 exe/AMD64

 

이후 AWS CLI 인증 정보를 등록하였다.

aws configure

AWS Access Key ID [None]:
AWS Secret Access Key [None]:
Default region name [None]: ap-northeast-2
Default output format [None]: json

 

이 과정을 통해 인증 정보가 로컬 PC의 AWS Credential Store에 저장되었다.

---

추가 문제 발생

aws s3 ls 실행 시 AccessDenied 발생

인증 설정 이후 아래 명령어로 S3 접근 테스트를 진행하였다.

aws s3 ls

 

하지만 아래와 같은 에러가 발생하였다.

An error occurred (AccessDenied)
when calling the ListBuckets operation

 

처음에는 인증 실패라고 생각했지만, 실제로는 AWS 인증 자체는 성공한 상태였다.

문제는 현재 IAM 사용자에 아래 권한이 없었던 것이다.

s3:ListAllMyBuckets

 

즉, “모든 버킷 목록 조회 권한”이 없는 상태였다.

---

실제 원인

인증(Authentication)과 권한(Authorization)은 다르다

AWS CLI가 정상적으로 동작하고 있다는 것은 이미 인증 자체는 성공했다는 의미였다.

하지만 AWS는 인증(Authentication)과 권한(Authorization)을 분리해서 관리한다.

 

즉,

• Access Key 등록 성공
• AWS 인증 성공
• 하지만 특정 S3 작업 권한 부족

상태였던 것이다.

 

이번 프로젝트에서는 전체 버킷 조회가 필요한 것이 아니라 특정 버킷의 파일 업로드/조회만 필요했기 때문에 필수적인 문제는 아니었다.

---

코드 구조 개선

application-local.yml 의존 제거

기존에는 application-local.yml에 저장한 Access Key / Secret Key를 직접 주입하는 방식으로 S3Client를 생성하고 있었다.

@Bean
public S3Client s3Client(
        AudioStorageProperties properties,
        @Value("${cloud.aws.credentials.access-key}") String accessKey,
        @Value("${cloud.aws.credentials.secret-key}") String secretKey
) {

    AwsBasicCredentials credentials =
            AwsBasicCredentials.create(accessKey, secretKey);

    return S3Client.builder()
            .region(Region.of(properties.region()))
            .credentialsProvider(
                    StaticCredentialsProvider.create(credentials)
            )
            .build();
}

 

하지만 이 방식은 아래와 같은 문제가 있었다.

• local yml에 민감 정보 저장 필요
• 설정 파일 관리 부담
• Git 추적 가능성 존재
• 환경별 Credential 관리 복잡성 증가

---

AWS CLI 기반 Credential Chain 사용 구조로 변경

이번에는 AWS CLI 기반 인증 구조를 적용하면서 Credential을 직접 주입하지 않도록 수정하였다.

@Bean
public S3Client s3Client(AudioStorageProperties properties) {

    return S3Client.builder()
            .region(Region.of(properties.region()))
            .build();
}

 

이후 AWS SDK가 자동으로 아래 경로의 인증 정보를 읽도록 변경하였다.

~/.aws/credentials

 

즉,

• application-local.yml 내 AWS Key 제거
• 코드 내 Credential 하드코딩 제거
• AWS SDK 기본 Credential Chain 사용

구조로 개선하였다.

---

느낀 점

처음에는 local yml에 AWS Access Key를 저장해도 큰 문제가 없다고 생각했지만, 실제로는 설정 파일 관리 실수나 Git 추적 같은 보안 문제가 발생할 수 있다는 점을 알게 되었다.

 

이번 작업을 통해 AWS CLI 기반 인증 구조와 AWS SDK Credential Chain 방식을 처음 적용해보면서, 실제 서비스에서는 인증 정보를 코드나 설정 파일에 직접 관리하지 않는 방식이 중요하다는 점을 경험할 수 있었다.