Skip to content

IAM Credentials

앱 배포에 사용되는 IAM 자격 증명을 설정합니다.

IAM 자격 증명

SST는 여러분의 AWS 자격 증명을 사용해 AWS 리소스를 배포합니다. 이 가이드에서는 이러한 자격 증명을 설정하는 방법, 필요한 기본 권한 세트, 그리고 이를 커스터마이징하는 방법을 살펴보겠습니다.


자격 증명

여러분의 앱이 사용할 자격 증명을 설정하는 방법에는 여러 가지가 있습니다. 가장 간단한 방법은 자격 증명 파일을 사용하는 것입니다.

하지만 아직 AWS 계정을 어떻게 구성해야 할지 모르겠다면, AWS 계정 설정 가이드를 따라 해 보시길 권장합니다.


파일에서

기본적으로 여러분의 AWS 자격 증명은 파일에 저장됩니다:

  • Linux, Unix, macOS에서는 ~/.aws/credentials
  • Windows에서는 C:\Users\USER_NAME\.aws\credentials

만약 자격 증명 파일이 여러분의 머신에 존재하지 않는다면:

  1. IAM 사용자 생성을 따라 진행하세요.
  2. 그리고 나서 AWS CLI 설정을 사용하여 자격 증명을 구성하세요.

아래에서는 이 사용자에게 부여된 권한을 어떻게 커스터마이징하는지 살펴보겠습니다.


여러분의 자격 증명 파일은 다음과 같이 보일 수 있습니다:

~/.aws/credentials
[default]
aws_access_key_id = <YOUR_ACCESS_KEY_ID>
aws_secret_access_key = <YOUR_SECRET_ACCESS_KEY>

여기서 default는 자격 증명 프로필의 이름입니다.

만약 여러 개의 자격 증명이 있다면, 다음과 같이 보일 수 있습니다:

~/.aws/credentials
[default]
aws_access_key_id = <DEFAULT_ACCESS_KEY_ID>
aws_secret_access_key = <DEFAULT_SECRET_ACCESS_KEY>
[staging]
aws_access_key_id = <STAGING_ACCESS_KEY_ID>
aws_secret_access_key = <STAGING_SECRET_ACCESS_KEY>
[production]
aws_access_key_id = <PRODUCTION_ACCESS_KEY_ID>
aws_secret_access_key = <PRODUCTION_SECRET_ACCESS_KEY>

기본적으로 SST는 default 프로필의 자격 증명을 사용합니다. 다른 프로필을 사용하려면 sst.config.ts에서 profile을 설정하세요.

sst.config.ts
{
providers: {
aws: {
profile: "staging"
}
}
}

여러분은 앱이 배포되는 스테이지에 따라 이를 커스터마이징할 수 있습니다.

sst.config.ts
app(input) {
return {
// ...
providers: {
aws: {
profile: input?.stage === "staging" ? "staging" : "default"
}
}
};
},

만약 AWS_PROFILE 환경 변수나 .env 파일을 통해 AWS 자격 증명을 이전에 설정했다면, 이는 sst.config.ts에서 설정한 프로필을 덮어쓸 것입니다. 따라서 AWS_PROFILE에 대한 모든 참조를 제거해야 합니다.


환경 변수에서

SST는 여러분의 환경에 있는 AWS 자격 증명을 감지하고 이를 사용해 배포할 수 있습니다.

  • AWS_ACCESS_KEY_ID
  • AWS_SECRET_ACCESS_KEY

임시 자격 증명을 사용하는 경우 AWS_SESSION_TOKEN도 설정할 수 있습니다.

이 기능은 CI 환경을 통해 배포할 때 자격 증명 파일이 없는 경우에 유용합니다.

우선순위

여러분이 여러 곳에 AWS 자격 증명을 설정한 경우, SST는 다음 순서대로 확인합니다:

  1. 환경 변수

    여기에는 AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, AWS_SESSION_TOKEN, 그리고 AWS_PROFILE이 포함됩니다. .env 파일에 설정된 환경 변수도 포함됩니다.

  2. SST 설정

    그다음으로 sst.config.ts 파일에서 자격 증명이나 profile을 확인합니다.

  3. AWS 설정

    그런 다음 ~/.aws/config 또는 C:\Users\USER_NAME\.aws\config 파일에서 [default] 프로필을 확인합니다.

  4. 자격 증명 파일

    마지막으로 ~/.aws/credentials 또는 C:\Users\USER_NAME\.aws\credentials 파일에서 정적 자격 증명을 확인합니다.


IAM 권한

위의 자격 증명은 IAM 사용자를 위한 것이며 IAM 정책과 함께 제공됩니다. 이 정책은 해당 사용자가 접근할 수 있는 리소스를 정의합니다. 기본적으로 AdministratorAccess를 사용합니다. 이는 사용자에게 완전한 접근 권한을 부여합니다.

하지만 회사에서 SST를 사용한다면, 이러한 권한을 보호해야 합니다. 여기서는 SST가 필요로 하는 정확한 권한과 이를 어떻게 커스텀할 수 있는지 살펴보겠습니다.


먼저 복사하여 붙여넣기 할 수 있는 IAM 정책부터 시작해 보겠습니다.

IAM 정책 복사
iam-policy.json
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "ManageBootstrapStateBucket",
"Effect": "Allow",
"Action": [
"s3:CreateBucket",
"s3:PutBucketVersioning",
"s3:PutBucketNotification",
"s3:PutBucketPolicy",
"s3:DeleteObject",
"s3:GetObject",
"s3:ListBucket",
"s3:PutObject"
],
"Resource": [
"arn:aws:s3:::sst-state-*"
]
},
{
"Sid": "ManageBootstrapAssetBucket",
"Effect": "Allow",
"Action": [
"s3:CreateBucket",
"s3:PutBucketVersioning",
"s3:PutBucketNotification",
"s3:PutBucketPolicy",
"s3:DeleteObject",
"s3:GetObject",
"s3:ListBucket",
"s3:PutObject"
],
"Resource": [
"arn:aws:s3:::sst-asset-*"
]
},
{
"Sid": "ManageBootstrapECRRepo",
"Effect": "Allow",
"Action": [
"ecr:CreateRepository",
"ecr:DescribeRepositories"
],
"Resource": [
"arn:aws:ecr:REGION:ACCOUNT:repository/sst-asset"
]
},
{
"Sid": "ManageBootstrapSSMParameter",
"Effect": "Allow",
"Action": [
"ssm:GetParameters",
"ssm:PutParameter"
],
"Resource": [
"arn:aws:ssm:REGION:ACCOUNT:parameter/sst/passphrase/*",
"arn:aws:ssm:REGION:ACCOUNT:parameter/sst/bootstrap"
]
},
{
"Sid": "Deployments",
"Effect": "Allow",
"Action": [
"*"
],
"Resource": [
"*"
]
},
{
"Sid": "ManageSecrets",
"Effect": "Allow",
"Action": [
"ssm:DeleteParameter",
"ssm:GetParameter",
"ssm:GetParameters",
"ssm:GetParametersByPath",
"ssm:PutParameter"
],
"Resource": [
"arn:aws:ssm:REGION:ACCOUNT:parameter/sst/*"
]
},
{
"Sid": "LiveLambdaSocketConnection",
"Effect": "Allow",
"Action": [
"iot:DescribeEndpoint",
"iot:Connect",
"iot:Subscribe",
"iot:Publish",
"iot:Receive"
],
"Resource": [
"*"
]
}
]
}

이 목록은 대략 다음과 같이 나눌 수 있습니다:

  1. AWS 계정에서 SST를 부트스트랩하는 데 필요한 권한
  2. 앱을 배포하는 데 필요한 권한
  3. CLI가 필요로 하는 권한

이제 각각을 자세히 살펴보겠습니다.


Bootstrap

SST는 각 AWS 계정의 각 리전에서 한 번씩 bootstrap을 수행해야 합니다. 이 작업은 sst deploy 또는 sst dev를 실행할 때 자동으로 이루어집니다.

여러 가지 부트스트랩 작업이 있으며, 각 작업에 필요한 권한은 다음과 같습니다:

  • 상태를 저장하기 위한 부트스트랩 버킷을 생성할 수 있는 권한.

    {
    "Sid": "ManageBootstrapStateBucket",
    "Effect": "Allow",
    "Action": [
    "s3:CreateBucket",
    "s3:PutBucketVersioning",
    "s3:PutBucketNotification",
    "s3:DeleteObject",
    "s3:GetObject",
    "s3:ListBucket",
    "s3:PutObject"
    ],
    "Resource": [
    "arn:aws:s3:::sst-state-*"
    ]
    }
  • 앱의 에셋(예: Lambda 함수 번들 및 프론트엔드의 정적 에셋)을 저장하기 위한 부트스트랩 버킷을 생성할 수 있는 권한.

    {
    "Sid": "ManageBootstrapAssetBucket",
    "Effect": "Allow",
    "Action": [
    "s3:CreateBucket",
    "s3:PutBucketVersioning",
    "s3:DeleteObject",
    "s3:GetObject",
    "s3:ListBucket",
    "s3:PutObject"
    ],
    "Resource": [
    "arn:aws:s3:::sst-asset-*"
    ]
    }
  • 앱의 Docker 이미지를 호스팅하기 위한 부트스트랩 ECR 리포지토리를 생성할 수 있는 권한.

    {
    "Sid": "ManageBootstrapECRRepo",
    "Effect": "Allow",
    "Action": [
    "ecr:CreateRepository",
    "ecr:DescribeRepositories"
    ],
    "Resource": [
    "arn:aws:ecr:REGION:ACCOUNT:repository/sst-asset"
    ]
    }
  • 배포된 부트스트랩 리소스에 대한 정보를 저장하는 부트스트랩 SSM 파라미터를 생성할 수 있는 권한.

    {
    "Sid": "ManageBootstrapSSMParameter",
    "Effect": "Allow",
    "Action": [
    "ssm:GetParameters",
    "ssm:PutParameter"
    ],
    "Resource": [
    "arn:aws:ssm:REGION:ACCOUNT:parameter/sst/passphrase/*",
    "arn:aws:ssm:REGION:ACCOUNT:parameter/sst/bootstrap"
    ]
    }

배포

SST가 여러분의 앱에 있는 리소스를 배포하기 위해 필요한 권한은 앱에 포함된 내용에 따라 달라집니다.

아래 블록은 IAM 정책에서 여러분이 커스터마이징할 수 있도록 템플릿으로 제공됩니다.

{
"Sid": "Deployments",
"Effect": "Allow",
"Action": [
"*"
],
"Resource": [
"*"
]
}

이제 이 정책을 어떻게 커스터마이징할 수 있는지 살펴보겠습니다.


CLI

SST CLI는 여러분의 AWS 계정에 몇 가지 AWS SDK 호출을 수행합니다. 다음은 필요한 IAM 권한입니다.

  • 시크릿을 관리하기 위한 권한

    {
    "Sid": "ManageSecrets",
    "Effect": "Allow",
    "Action": [
    "ssm:DeleteParameter",
    "ssm:GetParameter",
    "ssm:GetParameters",
    "ssm:GetParametersByPath",
    "ssm:PutParameter"
    ],
    "Resource": [
    "arn:aws:ssm:us-east-1:112233445566:parameter/sst/*"
    ]
    }
  • sst dev에서 함수를 Live로 실행하기 위해 IoT 엔드포인트에 연결하는 권한

    {
    "Sid": "LiveLambdaSocketConnection",
    "Effect": "Allow",
    "Action": [
    "iot:DescribeEndpoint",
    "iot:Connect",
    "iot:Subscribe",
    "iot:Publish",
    "iot:Receive"
    ],
    "Resource": [
    "*"
    ]
    }

권한 최소화

앱에 추가하는 리소스에 따라 위 정책을 수정하는 것은 번거로울 수 있습니다. 고려해볼 만한 접근 방식을 소개합니다.

  • 샌드박스 계정

    먼저 팀원들의 개발 사용을 위해 별도의 AWS 계정을 생성합니다. 이 샌드박스 계정에서는 AdministratorAccess를 부여할 수 있습니다. 이렇게 하면 팀원들이 변경할 때마다 권한을 수정할 필요가 없습니다.

  • IAM Access Analyzer

    스테이징 계정의 경우, 처음에는 광범위한 권한 정책을 부여할 수 있습니다. 앱을 배포하고 일정 기간 실행한 후, CloudTrail 이벤트를 사용해 해당 IAM 사용자가 사용한 작업과 서비스를 식별할 수 있습니다. IAM Access Analyzer를 사용하면 이 활동을 기반으로 IAM 정책을 생성할 수 있으며, 이를 원래 정책 대신 사용할 수 있습니다.

    이제 이 정책을 프로덕션 계정에 사용할 수 있습니다. IAM Access Analyzer 사용 방법에 대해 더 알아보세요.

일반적으로 IAM 권한을 정기적으로 감사하는 것이 중요합니다.