진짜 개난리 났음 에러 개판 (AWS EC2, VPC endpoint, S3)

사건의 개요😂

• 회사 업무의 요건 중 하나로 현행 S3 버켓에서 이행용 S3 버켓으로 데이터를 migration 해야 함
• 근데 이제 계정이 다른(크로스 어카운트)
• public internet을 경유하지 않고 vpc endpoint를 이용해서 데이터 migration을 진행
• 어제는 s3 access point를 가지고 검증하다가 이미 vpc endpoint가 있다길래 급선회

나는 좀,,, 저능한가? 같은 실수를 반복하니까 해결용으로 기록을 해야겠다

하하 개판이네

 

무슨 일이 일어나고 있나요?🤔

동작 검증을 위해 간단하게 크로스 어카운트가 아니고 동일 계정 내에서 검증환경 제작

 

검증 환경

• VPC 작성

간단하게 public subnet과 private subnet이 각각 하나씩 있는 vpc를 새로 작성했음.

IGW와 NAT-GW도 함께 생성함

 

• S3 버켓 생성

S3는 원래 검증용으로 쓰던 테스트 버켓이 있어서 해당 버켓을 사용하기로 했다

이 버켓은 퍼블릭 접근을 모두 차단하는 버켓이고, security rule 준수를 위해 접근 가능한 ip 제한이 있다

 

• VPC 엔드포인트 생성

VPC 엔드포인트를 새로 생성함

 

 

AWS 서비스 연결 유형, 서비스는 S3, Gateway 방식으로 생성함

찾아보니까 interface 유형은 public internet 경유라고 해서 gateway 유형으로 선택했음

 

routing table은 private subnet에 연결된 테이블을 선택

정책은 default로 모든 resource에 접근할 수 있게 되어있는데, 프로젝트 security rule 상 다른 버켓에 접근할 수 있는 것은 ng이므로 접근 제어를 위해 사용자 지정 정책을 설정했다

{
	"Version": "2008-10-17",
	"Statement": [
		{
			"Sid": "Allow-access-to-specific-bucket",
			"Effect": "Allow",
			"Principal": "*",
			"Action": [
				"s3:ListBucket",
				"s3:GetObject",
				"s3:PutObject"
			],
			"Resource": [
				"arn:aws:s3:::{target-bucket-name}",
				"arn:aws:s3:::{target-bucket-name}/*"
			]
		}
	]
}

* 허용할 버켓, 허용할 액션을 최소한으로 allow 하는 정책을 작성.

 

• S3 버켓 폴리시 작성(수정)

{
    "Version": "2012-10-17",
    "Id": "Policy2024082702",
    "Statement": [
        {
            "Sid": "AllowAccessToSpecificIpOrUser",
            "Effect": "Allow",
            "Principal": "*",
            "Action": [
                "s3:Put*",
                "s3:Get*",
                "s3:List*"
            ],
            "Resource": "arn:aws:s3:::{target-bucket-name}/*",
            "Condition": {
                "StringEqualsIfExists": {
                    "aws:SourceVpce": "vpce-{vpceId}"
                },
                "IpAddress": {
                    "aws:SourceIp": "source-IP"
                },
                "ArnEquals": {
                    "aws:PrincipalArn": "arn:aws:iam::{accountId}:user/{userId}"
                }
            }
        },
        {
            "Sid": "AllowConsoleAccess",
            "Effect": "Allow",
            "Principal": {
                "AWS": "arn:aws:iam::{accountId}:root"
            },
            "Action": "s3:*",
            "Resource": "arn:aws:s3:::{target-bucket-name}/*",
            "Condition": {
                "StringEquals": {
                    "aws:RequestedRegion": "{target-bucket-region}"
                },
                "StringLike": {
                    "aws:UserAgent": "*AWSManagementConsole*"
                }
            }
        }
    ]
}

 

이 정책을 작성하고 적용할 때가 제일 쫄렸다.

원래 ip제한/유저 제한만 두고 있었는데 vpc endpoint를 통한 접근도 추가로 허용해야 하기 때문에 vpce만 추가하기 쉬운데, 그렇게 되면 콘솔을 통한 접근을 할 수 없게 되어버린다(내가 루트 계정인데도!!!!)

 

그렇기 때문에 콘솔을 통한 접근을 추가로 허용해주는 statement도 붙여주어야 하는데 여기서 또 충돌이 한 번 일어났다

처음에 작성했던 두번째 statement는 다음과 같았다

{
    "Sid": "AllowConsoleAccess",
    "Effect": "Allow",
    "Principal": "*",
    "Action": "s3:*",
    "Resource": "arn:aws:s3:::{target-bucket-name}/*",
    "Condition": {
        "StringEquals": {
            "aws:RequestedRegion": "{target-bucket-region}"
        },
        "StringLike": {
            "aws:UserAgent": "*AWSManagementConsole*"
        }
    }
}

 

그랬더니 기가 막히게 에러가 발생했다

User: arn:aws:iam::{accountId}:root is not authorized to perform: s3:PutBucketPolicy on resource: "arn:aws:s3:::{target-bucket-name}" because public policies are blocked by the BlockPublicPolicy block public access setting.

 

이유를 찾아보니, S3 버켓은 퍼블릭 접근을 모두 불허하고 있는데, 두번째 statement의 principal이 "*"로 설정되어서 충돌을 일으켰기 때문이었다.

그래서 이 계정에서는 모두가 콘솔을 통해 접근할 수 있도록 principal을 accountId 단위로 수정했다.

 

• EC2 인스턴스 생성

인스턴스는 public subnet에 bastion 서버, private subnet에 검증용 서버를 각각 한 대씩 실행했음.

잠깐 검증만하고 닫을거니까 인스턴스 유형이나 ami는 따로 설정하지 않았다.

 

세큐리티 그룹은 default를 붙였는데 ssh로 접근할 예정이기 때문에 22포트만 열어주는 것으로 수정했다.

 

• 검증 시작

눈물의 ssh 접근... 여기서부터 무한의 에러계단을 뚜벅뚜벅 걸어오르게 되는데

 

흩날려라 천본앵이 아니고 무한의 에러😎

• 배스천 서버에 프라이빗 서버 접속용 공개키 파일 전송하기

우선 배스천 서버에 프라이빗 서버 접근용 공개키를 옮겨놔야 했는데 여기서도 에러와 함께 하게 되었다 제발 멈춰

>scp -i key.pem key.pem ec2-user@{bastion-server-ip}:/etc
scp: dest open "/etc/key.pem": Permission denied
scp: failed to upload file key.pem to /etc

이 에러는 target directory의 접근 권한 불일치 때문에 발생했음

루트 디렉토리 바로 아래에 있는 etc 디렉토리에 옮기려고 했던게 문제였다.

그래서 순순히 /home/ec2-user 아래에 key라는 디렉토리를 하나 작성하고 거기에 옮겼음

 

#bastion 서버에서 ec2-user 유저로 접속하여 실행
>mkdir /home/ec2-user/key

#로컬 서버에서 실행
#scp -i[옵션] [ssh접속을 위한 키 경로] [원본 파일 경로] [접속할 유저이름]@[접속처 ip]:[파일을 보관할 경로]
>scp -i key.pem key.pem ec2-user@{bation-server-ip}:/home/ec2-user/key

#bastion 서버에서 파일이 잘 전송되었는지 확인
[ec2-user@{ip} /]$ ll /home/ec2-user/key
total 4
-rw-r--r--. 1 ec2-user ec2-user 1674 Nov 19 03:40 EC2-Tutorial.pem

확인해보니 잘 복사되었기 때문에 프라이빗 서버에 접속을 시도했다(에러 제발 멈춰!!!)

 

[ec2-user@ip key]$ ssh -i key.pem ec2-user@{private-server-ip}
The authenticity of host '{private-server-ip} ({private-server-ip})' can't be established.
ED25519 key fingerprint is SHA256:FuycXU6oc0nfxCC+GeXFmNh55anwT+ScLAjd4K+SHlA.
This key is not known by any other names
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added '{private-server-ip}' (ED25519) to the list of known hosts.
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@         WARNING: UNPROTECTED PRIVATE KEY FILE!          @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
Permissions 0664 for 'key.pem' are too open.
It is required that your private key files are NOT accessible by others.
This private key will be ignored.
Load key "key.pem": bad permissions
ec2-user@{private-server-ip}: Permission denied (publickey,gssapi-keyex,gssapi-with-mic).

이번에도 역시 권한 때문에 막혔다

이번에는 too open 되어있기 때문에 막혔는데, 이것이 서버 접속용 인증키인데 권한이 644로 설정되어 있기 때문에 발생한 오류였다.

그래서 600으로 권한을 변경해주고 접속을 시도함

 

[ec2-user@ip /]$ chmod 600 /home/ec2-user/key/key.pem
[ec2-user@ip /]$ ll /home/ec2-user/key/key.pem
-rw-------. 1 ec2-user ec2-user 1674 Nov 19 03:40 /home/ec2-user/key/key.pem

[ec2-user@ip key]$ ssh -i key.pem ec2-user@{private-server-ip}
   ,     #_
   ~\_  ####_        Amazon Linux 2023
  ~~  \_#####\
  ~~     \###|
  ~~       \#/ ___   https://aws.amazon.com/linux/amazon-linux-2023
   ~~       V~' '->
    ~~~         /
      ~~._.   _/
         _/ _/
       _/m/'

눈물의 몇번째인지 기억도 안 나는 트라이

드디어 접속했다

 

이제 s3 버켓 소통 확인을 위해 간단하게 ls 커맨드를 실행했고,,,

[ec2-user@ip ~]$ aws s3 ls s3://{target-bucket-name}
An error occurred (AccessDenied) when calling the ListObjectsV2 operation: User: arn:aws:sts::{accountId}:assumed-role/ec2-ssm-role/i-03f35e9bb5ce2e301 is not authorized to perform: s3:ListBucket on resource: "arn:aws:s3:::{{target-bucket-name}}" because no VPC endpoint policy allows the s3:ListBucket action

그래 이럴 줄 알았다 이제 놀랍지도 않아 한번에 되면 뭔가 이상한거겠지

에러를 잘 살펴보니 이번에도 권한 문제였음

왜인지 기억이 안나지만 프라이빗 서버에 ssm용 iam 역할을 부착해놨는데, 내가 초기에 작성한 vpc 엔드포인트 폴리시에는 접속할 수 있는 사람을 제어하기 위해 userId를 조건으로 걸어놨었기 때문에 이 두개가 충돌하여 에러가 발동했다.

간단하게 vpc 엔드포인트 정책에서 누구나 가능하도록 principal 부분을 "*"로 수정하고 다시 시도했다

 

#target-bucket의 list
[ec2-user@ip ~]$ aws s3 ls s3://{target-bucket-name}
2024-11-18 08:24:35     753790 비자.pdf
2024-11-18 08:24:35     111067 재직증명서.pdf
2024-11-18 08:24:36      14914 재직증명서_한글.docx
2024-11-18 08:24:35      88473 재직증명서_한글.pdf

#target-bucket으로 등록하지 않은 bucket list 시도. deny되어야 함
[ec2-user@ip ~]$ aws s3 ls s3://{non-target-bucket-name}

An error occurred (AccessDenied) when calling the ListObjectsV2 operation: User: arn:aws:sts::{accountId}:assumed-role/ec2-ssm-role/i-03f35e9bb5ce2e301 is not authorized to perform: s3:ListBucket on resource: "arn:aws:s3:::{non-target-bucket-name}" because no VPC endpoint policy allows the s3:ListBucket action

아~~~ 여러분~~~ 제가~~~ 해냈습니다~~~~

 

어제도... 액세스 포인트로 권한 충돌때문에 성질이 많이 나빠졌는데(급격히 몰려오는 피로감)

오늘은 무사히 된 것 같아요.. 호호호,,, 다행이에요...

머리가 나쁘면 손발이 고생한다. 절실히 느꼈따

하지만 몸이 좋으면 머리를 덜 써도 되잖어🤔