EKS에서 EFS 마운트 실패 문제 해결: IAM 마운트 옵션 미스터리
Source: Dev.to
위 링크에 포함된 전체 텍스트를 제공해 주시면, 해당 내용을 한국어로 번역해 드리겠습니다. 현재는 번역할 본문이 없으므로, 번역이 필요한 부분을 복사해서 알려 주세요.
TL;DR
EKS에서 EFS 볼륨을 마운트할 때 mount.nfs4: access denied by server while mounting 127.0.0.1:/ 오류가 나타나고 보안 그룹이 올바른 경우, EFS 파일 시스템 정책을 사용할 때 PersistentVolume 정의에 iam 마운트 옵션이 누락된 것일 가능성이 높습니다.
문제
새로운 보고 서비스를 EKS 클러스터에 통합하면서 공유 EFS 파일 시스템에 보고서를 기록해야 했는데, 파드가 다음과 같은 난해한 오류로 마운트에 계속 실패했습니다:
MountVolume.SetUp failed for volume "efs-pv": rpc error: code = Internal desc = Could not mount "{efs_id}:/"
Output: mount.nfs4: access denied by server while mounting 127.0.0.1:/조사 여정
초기 의심 (전부 오답)
가설 1: 보안 그룹 문제
- 워커 노드와 EFS 마운트 대상 간에 NFS 트래픽(TCP 2049)이 허용되는지 확인했습니다.
- 모든 가용 영역에 마운트 대상이 존재했습니다.
결과: 보안 그룹은 완벽했습니다. 문제가 아니었습니다.
가설 2: EFS 파일 시스템 정책
- 최근에 IAM 기반 파일 시스템 정책을 추가하여 접근을 제한했습니다.
- 정책에
aws:PrincipalArn와 같은 조건을 포함시켜 특정 IAM 역할만 허용하도록 했습니다.
돌파구: 정책을 제거하니 작동했습니다!
유레카 순간
AWS EFS 문제 해결 문서를 읽어보니 다음과 같은 내용이 있었습니다:
제한적인 파일 시스템 정책과 함께
iam마운트 옵션을 추가하지 않으면, 파드가 다음 오류 메시지와 함께 실패합니다:
mount.nfs4: access denied by server while mounting 127.0.0.1:/
근본 원인 분석
1. EFS 파일 시스템 정책 조건
우리는 정책 조건에 aws:PrincipalArn을 사용했습니다:
{
"Condition": {
"ArnLike": {
"aws:PrincipalArn": [
"arn:aws:iam::123456789012:role/worker-node-role",
"arn:aws:iam::123456789012:role/efs-csi-driver-role"
]
}
}
}문제: AWS 문서에 따르면 aws:PrincipalArn 및 대부분의 IAM 조건 키는 EFS에 대한 NFS 클라이언트 마운트에 적용되지 않습니다. 다음 조건 키만 작동합니다:
aws:SecureTransport(Boolean)aws:SourceIp(String – 공용 IP만)elasticfilesystem:AccessPointArn(String)elasticfilesystem:AccessedViaMountTarget(Boolean)
2. 누락된 IAM 마운트 옵션
우리 PersistentVolume 정의에서 iam 마운트 옵션을 빼먹었습니다:
# BEFORE – Missing iam mount option
apiVersion: v1
kind: PersistentVolume
metadata:
name: efs-pv
spec:
storageClassName: aws-efs-csi-sc
csi:
driver: efs.csi.aws.com
volumeHandle: "{efs_id}"iam 옵션이 없으면 EFS CSI 드라이버가 IAM 역할을 사용해 인증하지 않으므로, IAM 제한이 포함된 파일 시스템 정책이 모두 실패합니다.
3. EFS 마운트 흐름
tls 마운트 옵션과 함께 EFS CSI 드라이버를 사용할 때:
- 노드 수준 마운트가 먼저 수행됩니다 (워커 노드 IAM 역할을 통해).
iam없이 → 익명 NFS 마운트.iam과 함께 → IAM 역할 자격 증명을 사용한 인증된 마운트.
해결책
해결책 1: mountOptions에 iam 추가
# AFTER – With iam mount option
apiVersion: v1
kind: PersistentVolume
metadata:
name: efs-pv
spec:
storageClassName: aws-efs-csi-sc
mountOptions:
- tls # Encryption in transit
- iam # Enable IAM authentication
csi:
driver: efs.csi.aws.com
volumeHandle: "{efs_id}"해결책 2: 지원되는 EFS 조건 키만 사용
파일 시스템 정책이 필요하다면, 지원되는 조건으로 제한하십시오:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": { "AWS": "*" },
"Action": [
"elasticfilesystem:ClientMount",
"elasticfilesystem:ClientWrite",
"elasticfilesystem:ClientRootAccess"
],
"Resource": "arn:aws:elasticfilesystem:us-east-1:123456789012:file-system/{efs_id}",
"Condition": {
"Bool": {
"elasticfilesystem:AccessedViaMountTarget": "true",
"aws:SecureTransport": "true"
}
}
}
]
}이 정책은:
- TLS 암호화(
aws:SecureTransport)를 요구합니다. - 마운트 대상(
elasticfilesystem:AccessedViaMountTarget)을 통한 접근을 요구합니다. - 지원되는 조건 키만 사용합니다.
- 네트워크 수준 접근 제어는 보안 그룹에 의존합니다.
주요 학습 내용
-
IAM 마운트 옵션은 IAM 인증에 필요합니다
-o iam옵션 없이 마운트하면 EFS는 익명으로 연결됩니다. IAM 기반 파일 시스템 정책은 접근을 거부합니다. -
모든 IAM 조건이 EFS와 호환되는 것은 아닙니다
NFS 마운트에 대해 적용되는 조건 키는 네 개뿐입니다. 다른 조건을 사용하면 보안이 실제보다 높은 것처럼 보일 수 있습니다. -
보안을 계층적으로 구성하세요
- 네트워크 계층: 보안 그룹 (마운트 대상에 도달할 수 있는 대상).
- IAM 계층: 역할에 대한 IAM 정책 (허용되는 작업).
- 파일 시스템 계층: EFS 정책 (추가 제한).
-
오류 로그를 꼼꼼히 확인하세요
오류에127.0.0.1이 표시되는 이유는 EFS 마운트 헬퍼가 TLS를 위해 로컬 stunnel 프록시를 생성하기 때문입니다. 실제 실패는 네트워크 계층이 아니라 IAM 인증 계층에서 발생합니다. -
마운트 작업을 수동으로 테스트하세요
워커 노드에 SSH로 접속한 뒤 EFS 마운트 헬퍼를 사용해 마운트를 테스트합니다:sudo mount -t efs -o tls,iam {efs_id}:/ /mnt/test이는 Kubernetes 외부에서 구성을 검증하는 방법입니다.
Conclusion
What seemed like a complex IAM policy issue turned out to be a missing mount option. The key insight was that EFS file system policies require explicit IAM authentication via the iam mount option, and that most IAM condition keys don’t apply to NFS mounts.