configure aws credentials
v4.0.2
다른 GitHub 작업에 사용하기 위해 AWS 자격 증명 및 지역 환경 변수를 구성하십시오.
이 조치는 AWS JavaScript SDK 자격 증명 해상도 체인을 구현하고 다른 작업을 수행하기 위해 세션 환경 변수를 내보내십시오. AWS API 통화 용 AWS SDK와 AWS CLI에 의해 환경 가변 수출은 감지됩니다.
API 호출 AWS에 대한 호출은 자격 증명 정보와 함께 서명해야하므로 AWS SDK 또는 AWS 도구 중 하나를 사용하면 AWS 자격 증명 및 AWS 지역을 제공해야합니다. GitHub 조치에서이를 수행하는 한 가지 방법은 IAM 자격 증명과 함께 리포지토리 비밀을 사용하는 것이지만 장기 자격 증명 사용에 대한 AWS 보안 지침을 따르지 않습니다. 대신 장기 자격 증명 또는 JWT를 사용하여 임시 자격 증명을 가져와 도구와 함께 사용하는 것이 좋습니다. 이 github 동작은 바로 그것을 용이하게합니다.
AWS SDK 및 도구 표준화 된 환경 변수에서 자격 증명을 찾습니다. 본질적으로,이 조치는 표준 자격 증명 해상도 흐름을 통해 실행되며, 마지막으로 나중에 사용할 수 있도록 환경 변수를 수출합니다.
우리는 AWS에서 자격 증명을 가져 오는 5 가지 방법을 지원하지만 구성된 AWS IAD ID PROVIDER Endpoint와 함께 GitHub의 OIDC 제공 업체를 사용하는 것이 좋습니다.
이를 수행하는 방법에 대한 자세한 내용은 계속 읽으십시오.
이 문서 중 일부는 GHES (GitHub Enterprise Server)를 사용하는 경우 부정확 할 수 있습니다. 관련시 GitHub 문서를 검토하려면 확인하십시오.
예를 들어, OIDC JWT에서 발행 된 URL은 일반적인 token.actions.githubusercontent.com 과 다르며 Enterprise Server에 고유합니다. 결과적으로 Identity 제공자를 만들 때이를 다르게 구성해야합니다.
우리는 현재이 조치를 검증하기위한 GHES 테스트 환경이 없습니다. GHES를 실행하고 문제가 발생하면 알려주십시오.
GitHub Actions 워크 플로우에 사용되는 AWS 자격 증명에 대한 Amazon iAM 모범 사례를 다음과 같은 것이 좋습니다.
자격 증명을 검색하는 5 가지 지원 방법이 있습니다.
AssumeRoleWithWebIdentity )AssumeRole )AssumeRoleWithWebIdentity )AssumeRole )우리는 AWS JavaScript SDK를 사용하기 때문에 항상 node.js의 자격 증명 해상도 흐름을 사용합니다. 입력에 따라 동작 이이 흐름의 일부를 무시할 수 있습니다.
위의 첫 번째 옵션 인 Github의 OIDC 제공 업체를 사용하는 것이 좋습니다. 이 방법은 OIDC를 사용하여 귀하의 행동에 필요한 짧은 자격 증명을 얻습니다. OIDC와의 역할을 맡기 위해 AWS 계정을 설정하는 방법에 대한 자세한 내용은 OIDC를 참조하십시오.
다음 표는 조치에 제공되는 값을 기반으로 자격 증명을 얻는 데 사용할 방법을 설명합니다.
| 사용 된 정체성 | aws-access-key-id | role-to-assume | web-identity-token-file | role-chaining | id-token 허가 |
|---|---|---|---|---|---|
| [ume 권장] GitHub OIDC 제공 업체를 사용하여 직접 역할을합니다 | ✔ | ✔ | |||
| IAM 사용자 | ✔ | ||||
| IAM 사용자 자격 증명을 사용하여 역할을 가정합니다 | ✔ | ✔ | |||
| WebIdentity 토큰 파일 자격 증명을 사용하여 역할을 가정합니다 | ✔ | ✔ | |||
| 기존 자격 증명을 사용하여 역할을 가정합니다 | ✔ | ✔ |
참고 : 기존 자격 증명을 사용하는 데 role-chaining 항상 필요하지는 않습니다. "SDK에 의해로드 된 자격 증명이 일치하지 않습니다"오류가 발생하는 경우이 옵션을 활성화하십시오.
자세한 내용은 action.yml을 참조하십시오.
| 옵션 | 설명 | 필수의 |
|---|---|---|
| AWS- 지역 | 어떤 AWS 지역을 사용할 수 있습니다 | 예 |
| 역할 대의 역할 | 자격 증명을 가져 오는 역할. 일부 인증 유형에만 필요합니다. | 아니요 |
| AWS-ACCESS-KEY-ID | 사용할 AWS 액세스 키. 일부 인증 유형에만 필요합니다. | 아니요 |
| AWS-SECRET-ACCESS-KEY | AWS 비밀 키 사용. 일부 인증 유형에만 필요합니다. | 아니요 |
| AWS-SESSSION-TOKE | 사용할 AWS 세션 토큰. 드문 인증 시나리오에서 사용됩니다. | 아니요 |
| 역할 체인 | 환경의 기존 자격 증명을 사용하여 새로운 역할을합니다. | 아니요 |
| 청중 | OIDC를 사용할 때 JWT 잠재 고객. 중국 지역과 같은 비 디폴트 AWS 파티션에 사용됩니다. | 아니요 |
| http-proxy | API 호출에 사용할 HTTP 프록시. | 아니요 |
| 마스크 -AWS-ACCOUNT-ID | AWS 계정 ID는 비밀로 간주되지 않습니다. 이것을 설정하면 어쨌든 계정 ID를 출력에서 숨 깁니다. | 아니요 |
| 역할-초 | 역할을 가정하는 경우 몇 초 만에 역할 기간을 가정했습니다. 기본값은 1 시간입니다. | 아니요 |
| 역할-내부 -ID | 가정 할 역할의 외부 ID. 귀하의 역할에 필요한 경우에만 필요합니다. | 아니요 |
| 역할 세션 이름 | 기본값은 "githubactions"로 이루어 지지만 필요한 경우 변경 될 수 있습니다. | 아니요 |
| 역할-스션 세션 태깅 | 세트가 설정된 경우 세션 태깅을 건너 뜁니다. | 아니요 |
| 인라인 세션 정책 | 여기에서 인라인 정책을 정의하여 가정 된 역할 정책을 더 제한 할 수 있습니다. | 아니요 |
| 관리 세션 폴리시 | 여기에 관리 된 정책을 지정하여 가정 된 역할 정책을 추가로 제한 할 수 있습니다. | 아니요 |
| 출력 간주 | 설정하면 출력이 액션 단계 출력으로 자격 증명을 가져옵니다. 기본값으로 거짓. | 아니요 |
| 미지류 간주 | 설정하면 액션 러너의 기존 자격 증명을 설정하지 않으려 고 시도합니다. | 아니요 |
| 비활성화 | 역할 통화를 가정하기위한 비활성화 재 시도/백 오프 로직. 기본적으로 재시도가 활성화됩니다. | 아니요 |
| 레트레-맥스-템플릿 | 포기하기 전에 재시도 시도 횟수를 제한합니다. 기본값은 12까지. | 아니요 |
| 특수 특성 작업 | 드물게, 일부 환경은 비밀 키에서 특수 문자를 견딜 수 없습니다. 이 옵션은 비밀 액세스 키에 특수 문자가 포함되지 않을 때까지 자격 증명을 다시 시도합니다. 이 옵션은 비활성화 및 재시성 선식 평가를 무시합니다. | 아니요 |
기본 세션 지속 시간은 1 시간 입니다.
이 조정을 원한다면 role-duration-seconds 으로 지속 시간을 전달할 수 있지만 IAM 역할이 생성 될 때 정의 된 최대 값을 초과 할 수는 없습니다.
귀하의 역할이 외부 ID가 필요한 경우, 외부 ID에 role-external-id 입력을 제공 할 수 있습니다.
기본 세션 이름은 "githubactions"이며, 원하는 이름을 role-session-name 으로 지정하여 수정할 수 있습니다. 세션에는 다음 태그가 표시됩니다. ( GITHUB_ 환경 변수 정의에 대한 Github의 문서를 참조하십시오)
| 열쇠 | 값 |
|---|---|
| github | "행위" |
| 저장소 | github_repository |
| 워크 플로 | github_workflow |
| 행동 | github_action |
| 배우 | github_actor |
| 나뭇가지 | github_ref |
| 저지르다 | github_sha |
참고 : 모든 태그 값은 태그 요구 사항을 준수해야합니다. 특히, GITHUB_WORKFLOW 너무 길면 잘립니다. GITHUB_ACTOR 또는 GITHUB_WORKFLOW 에 잘못된 문자가 포함 된 경우 문자는 '*'로 대체됩니다.
이 조치는 권장 사항을 따르고 WebIdentity와의 역할을 가정하지 않는 한 역할 가정 중에 기본적으로 세션 태그를 사용합니다. WebIdentity 역할 가정의 경우 세션 태그를 인코딩 된 WebIdentity 토큰에 포함시켜야합니다. 이는 태그가 OIDC 제공 업체에 의해서만 공급 될 수 있으며, 동작 내에서 API 호출을 가정 할 수 없음을 의미합니다. 자세한 내용은 #419를 참조하십시오.
작업의 입력에서 role-skip-session-tagging True로 제공 하여이 세션 태깅을 건너 뛸 수 있습니다.
uses : aws-actions/configure-aws-credentials@v4
with :
role-skip-session-tagging : true세션 정책은 필요하지 않지만 IAM 역할을 변경하지 않고 가져온 자격 증명의 범위를 제한 할 수 있습니다. 워크 플로 파일에 인라인 세션 정책을 바로 지정하거나 ARN의 기존 관리 세션 정책을 참조 할 수 있습니다.
인라인 세션 정책으로 사용하려는 Stringified JSON 형식의 IAM 정책. 선호도에 따라 JSON은 다음과 같은 한 줄로 작성할 수 있습니다.
uses : aws-actions/configure-aws-credentials@v4
with :
inline-session-policy : ' {"Version":"2012-10-17","Statement":[{"Sid":"Stmt1","Effect":"Allow","Action":"s3:List*","Resource":"*"}]} '또는 우리는 멋진 형식의 JSON도 가질 수 있습니다.
uses : aws-actions/configure-aws-credentials@v4
with :
inline-session-policy : >-
{
"Version": "2012-10-17",
"Statement": [
{
"Sid":"Stmt1",
"Effect":"Allow",
"Action":"s3:List*",
"Resource":"*"
}
]
} 관리되는 세션 정책으로 사용하려는 IAM 관리 정책의 ARN (Amazon Resource Names). 정책은 역할과 동일한 계정으로 존재해야합니다. 다음과 같은 단일 관리 정책을 통과 할 수 있습니다.
uses : aws-actions/configure-aws-credentials@v4
with :
managed-session-policies : arn:aws:iam::aws:policy/AmazonS3ReadOnlyAccess그리고 우리는 다음과 같은 여러 관리 정책을 통과 할 수 있습니다.
uses : aws-actions/configure-aws-credentials@v4
with :
managed-session-policies : |
arn:aws:iam::aws:policy/AmazonS3ReadOnlyAccess
arn:aws:iam::aws:policy/AmazonS3OutpostsReadOnlyAccess 이제 STS 호출이 실패한 경우 재시도 설정을 구성 할 수 있습니다. 기본적으로, 우리는 지수 백 오프를 12 번 다시 시도합니다. disable-retry 입력을 true 로 설정 하여이 동작을 모두 비활성화하거나 retry-max-attempts 입력을 사용하여 재시험 횟수를 구성 할 수 있습니다.
계정 ID는 민감한 정보로 간주되지 않으므로 워크 플로 로그에서 기본적으로 마스킹되지 않습니다. 그러나 원하는 경우 mask-aws-account-id 입력을 true 로 설정하여 워크 플로 로그에서 계정 ID를 마스킹 할 수 있습니다.
때로는 러너의 기존 자격 증명이 의도 한 결과를 방해 할 수 있습니다. 이 문제를 해결하기 위해 unset-current-credentials 입력을 true 로 설정할 수 있습니다.
일부 에지 케이스는 특수 문자가 포함 된 경우 AWS_SECRET_ACCESS_KEY 를 올바르게 구문 분석 할 수 없습니다. 자세한 내용은 AWS CLI 문서를 참조하십시오. special-characters-workaround 옵션을 설정하면이 조치는 특수 문자가없는 것을 얻을 때까지 자격 증명을 계속 재 시도합니다. 이 옵션은 disable-retry 및 retry-max-attempts 옵션을 무시합니다. API가 성공할 때까지 무한히 재 시도하는 것이 모범 사례가 아니기 때문에 필요하지 않은 경우이 옵션을 활성화하지 않는 것이 좋습니다.
GitHub의 OIDC 제공 업체를 사용하여 귀하의 행동에 필요한 짧은 AWS 자격 증명을 얻는 것이 좋습니다. OIDC를 사용할 때는 GitHub의 OIDC 엔드 포인트에서 JWT를 수락하도록 IAM을 구성합니다. 이 작업은 OIDC 엔드 포인트를 사용하여 워크 플로 실행에 고유 한 JWT를 생성하며 JWT를 사용하여 단기 자격 증명으로 지정된 역할을 가정합니다.
이것을 작동시키기 위해
id-token: write 권한을 사용하도록 워크 플로를 구성하십시오.
필요한 경우 잠재 고객을 구성하십시오.
AWS 계정에서 IAM을 GitHub의 OIDC Identity 제공자를 신뢰하도록 구성하십시오.
적절한 클레임 제한 및 권한 범위로 IAM 역할을 구성하십시오.
참고 : "githubactions"역할의 이름 지정은 작동하지 않는 것으로보고되었습니다. #953을 참조하십시오.
이 작업을 설정할 때 해당 역할의 ARN을 지정하십시오.
먼저,이 조치가 JWT를 만들려면 워크 플로 파일이 id-token: write 권한이 있어야합니다.
permissions :
id-token : write
contents : read JWT가 만들어지면 잠재 고객을 지정해야합니다. 일반적으로 sts.amazonaws.com 사용 하며이 조치는 하나를 지정하지 않으면 기본적으로 사용합니다. 이것은 대부분의 경우에 효과가 있습니다. 중국 지역과 같은 비 디펜트 AWS 파티션을 사용할 때는 기본 청중을 변경해야 할 수도 있습니다. audience 입력을 통해 청중을 지정할 수 있습니다.
- name : Configure AWS Credentials for China region audience
uses : aws-actions/configure-aws-credentials@v4
with :
audience : sts.amazonaws.com.cn
aws-region : us-east-3
role-to-assume : arn:aws-cn:iam::123456789100:role/my-github-actions-roleGitHub의 OIDC 제공 업체를 사용하려면 먼저 IAM IDP로 제공자와 연합을 설정해야합니다. GitHub OIDC 제공 업체는 계정 당 한 번만 작성하면됩니다 (즉, GitHub의 OIDC가 가정 할 수있는 다중 IAM 역할은 단일 OIDC 제공 업체를 공유 할 수 있음). 다음은이 신뢰를 구성 할 샘플 CloudFormation 템플릿입니다.
token.actions.githubusercontent.com 인증 할 때 ThumbPrint가 사용되지 않기 때문에 아래의 ThumbPrint는 모든 F로 설정되었습니다. 이것은 Github의 OIDC가 IAM을 인증 할 때만 사용되는 특별한 경우입니다. IAM은 신뢰할 수있는 CAS 라이브러리를 사용하여 인증합니다. 값은 여전히 API이므로 지정해야합니다.
아래 템플릿을 복사하거나 여기에서로드 할 수 있습니다 : https://d38mtn6aq9zhn6.cloudfront.net/configure-aws-credentials-latest.yml
Parameters :
GitHubOrg :
Description : Name of GitHub organization/user (case sensitive)
Type : String
RepositoryName :
Description : Name of GitHub repository (case sensitive)
Type : String
OIDCProviderArn :
Description : Arn for the GitHub OIDC Provider.
Default : " "
Type : String
OIDCAudience :
Description : Audience supplied to configure-aws-credentials.
Default : " sts.amazonaws.com "
Type : String
Conditions :
CreateOIDCProvider : !Equals
- !Ref OIDCProviderArn
- " "
Resources :
Role :
Type : AWS::IAM::Role
Properties :
AssumeRolePolicyDocument :
Statement :
- Effect : Allow
Action : sts:AssumeRoleWithWebIdentity
Principal :
Federated : !If
- CreateOIDCProvider
- !Ref GithubOidc
- !Ref OIDCProviderArn
Condition :
StringEquals :
token.actions.githubusercontent.com:aud : !Ref OIDCAudience
StringLike :
token.actions.githubusercontent.com:sub : !Sub repo:${GitHubOrg}/${RepositoryName}:*
GithubOidc :
Type : AWS::IAM::OIDCProvider
Condition : CreateOIDCProvider
Properties :
Url : https://token.actions.githubusercontent.com
ClientIdList :
- sts.amazonaws.com
ThumbprintList :
- ffffffffffffffffffffffffffffffffffffffff
Outputs :
Role :
Value : !GetAtt Role.Arn 최소 특권을 부여하는 Amazon IAM 모범 사례와 일치하려면 역할 정책 문서에 대한 가정에는 역할을 가정 할 수있는 주제 ( sub )를 지정하는 Condition 포함되어야합니다. Github는 또한 올바른 잠재 고객 ( aud )을위한 필터링을 권장합니다. 신뢰 정책에서 필터링 할 수있는 클레임에 대한 AWS IAM 문서를 참조하십시오.
주제 ( sub ) 조건이 없으면 GitHub 사용자 또는 저장소가 그 역할을 잠재적으로 가정 할 수 있습니다. CloudFormation 템플릿에 표시된대로 주제는 GitHub 조직 및 저장소로 범위를 지정할 수 있습니다. 그러나 조직과 리포지트로 범위를 범하면 어떤 경우에는 역할 가정이 실패 할 수 있습니다. 워크 플로우에 따라 주제 값이 무엇인지에 대한 구체적인 세부 사항에 대한 예제 주제 클레임을 참조하십시오. 신탁 정책에서 필터링 할 수있는 정보를 완전히 제어하려면 주제 청구를 사용자 정의 할 수도 있습니다. 주제 ( sub ) 키가 무엇인지 잘 모르면 작업 플로우에 actions-oidc-debugger 조치를 추가하여 주제 ( sub ) 키의 값 및 기타 주장을 확인할 수 있습니다.
GitHub 문서에 설명 된대로 더 높은 특이성을 위해 추가 청구 조건을 추가 할 수 있습니다. 구현 세부 사항으로 인해 모든 OIDC 청구가 현재 IAM이 지원하는 것은 아닙니다.
OIDC 및 GitHub 작업에 대한 자세한 내용은 다음을 참조하십시오.
EC2 인스턴스와 같이 이미 AWS 자격 증명에 액세스 할 수있는 자체 호스트 러너에서 GitHub 작업을 실행하면이 작업에 IAM 사용자 액세스 키 자격 증명을 제공 할 필요가 없습니다. 표준 AWS JavaScript SDK 자격 증명 해상도 방법을 사용하여 자격 증명을 찾을 수 있으므로 AWS JS SDK가 러너를 인증 할 수 있다면이 작업도 마찬가지입니다.
작업 입력에 액세스 키 자격 증명이 제공되지 않으면이 작업은 JavaScript 용 AWS SDK의 기본 메소드를 사용하여 러너 환경의 자격 증명을 사용합니다.
이 조치를 사용하여 환경에서 지역 및 계정 ID를 단순히 구성한 다음 작업 워크 플로우에서 작성한 모든 AWS API 호출에 대해 러너의 자격 증명을 사용 할 수 있습니다.
uses : aws-actions/configure-aws-credentials@v4
with :
aws-region : us-east-2이 경우 러너의 자격 증명에는 작업 워크 플로우에서 호출 된 AWS API를 호출 할 권한이 있어야합니다.
또는이 조치를 사용하여 역할을 가정 한 다음 작업 워크 플로우에서 이루어진 모든 AWS API 호출에 대한 역할 자격 증명을 사용할 수 있습니다.
uses : aws-actions/configure-aws-credentials@v4
with :
aws-region : us-east-2
role-to-assume : my-github-actions-role이 경우 러너의 자격 증명에는 역할을 가정 할 권한이 있어야합니다.
Amazon EKS IRSA를 사용하는 경우와 같은 웹 아이덴티티 토큰 파일을 사용하여 역할을 맡을 수도 있습니다. 루트로 실행되지 않는 EKS 작업자 노드에서 실행되는 포드는이 파일을 사용하여 웹 아이덴티티의 역할을 가정 할 수 있습니다.
필요한 경우 HTTP 프록시를 사용하십시오. 동작에서 수동으로 설정할 수 있습니다.
또한이 작업은 항상 HTTP_PROXY 환경 변수를 고려합니다.
수동으로 구성된 프록시 :
uses : aws-actions/configure-aws-credentials@v4
with :
aws-region : us-east-2
role-to-assume : my-github-actions-role
http-proxy : " http://companydomain.com:3128 "환경 변수에서 구성된 프록시 :
# Your environment configuration
HTTP_PROXY= " http://companydomain.com:3128 " 이 워크 플로는 AWS CLI를 환경에 설치하지 않습니다 . aws 명령을 실행하기 전에이 작업을 실행하려는 자체 호스트 러너는 아직 존재하지 않으면 AWS CLI를 설치해야합니다. 대부분의 GitHub 호스팅 러너 환경에는 기본적으로 AWS CLI가 포함되어야합니다.
- name : Configure AWS Credentials
uses : aws-actions/configure-aws-credentials@v4
with :
aws-region : us-east-2
role-to-assume : arn:aws:iam::123456789100:role/my-github-actions-role
role-session-name : MySessionName 이 예에서,이 작업은 GitHub 제공 환경 변수에서 OIDC 토큰을로드하여 arn:aws:iam::123456789100:role/my-github-actions-role 의 역할 MySessionName 을 가정하는 데 사용합니다.
- name : Configure AWS Credentials
uses : aws-actions/configure-aws-credentials@v4
with :
aws-region : us-east-2
role-to-assume : arn:aws:iam::123456789100:role/my-github-actions-role
role-session-name : MySessionName
- name : Configure other AWS Credentials
uses : aws-actions/configure-aws-credentials@v4
with :
aws-region : us-east-2
role-to-assume : arn:aws:iam::987654321000:role/my-second-role
role-session-name : MySessionName
role-chaining : true 이 2 단계 예에서 첫 번째 단계는 OIDC를 사용하여 arn:aws:iam::123456789100:role/my-github-actions-role 역할을 가정합니다. 그 후, 두 번째 단계는이 역할을 사용하여 다른 역할, arn:aws:iam::987654321000:role/my-second-role 가정합니다.
- name : Configure AWS Credentials
uses : aws-actions/configure-aws-credentials@v4
with :
aws-access-key-id : ${{ secrets.AWS_ACCESS_KEY_ID }}
aws-secret-access-key : ${{ secrets.AWS_SECRET_ACCESS_KEY }}
aws-region : us-east-2
role-to-assume : ${{ secrets.AWS_ROLE_TO_ASSUME }}
role-external-id : ${{ secrets.AWS_ROLE_EXTERNAL_ID }}
role-duration-seconds : 1200
role-session-name : MySessionName 이 예에서 비밀 AWS_ROLE_TO_ASSUME 에는 arn:aws:iam::123456789100:role/my-github-actions-role 과 같은 문자열이 포함되어 있습니다. 정적 자격 증명과 동일한 계정에서 역할을 맡기 위해서는 역할 role-to-assume: my-github-actions-role 과 같은 역할 이름을 간단히 지정할 수 있습니다.
- name : Configure AWS Credentials 1
id : creds
uses : aws-actions/configure-aws-credentials@v4
with :
aws-region : us-east-2
role-to-assume : arn:aws:iam::123456789100:role/my-github-actions-role
output-credentials : true
- name : get caller identity 1
run : |
aws sts get-caller-identity
- name : Configure AWS Credentials 2
uses : aws-actions/configure-aws-credentials@v4
with :
aws-region : us-east-2
aws-access-key-id : ${{ steps.creds.outputs.aws-access-key-id }}
aws-secret-access-key : ${{ steps.creds.outputs.aws-secret-access-key }}
aws-session-token : ${{ steps.creds.outputs.aws-session-token }}
role-to-assume : arn:aws:iam::123456789100:role/my-other-github-actions-role
- name : get caller identity2
run : |
aws sts get-caller-identity 이 예제는 output-credentials true로 설정된 경우 페치 된 자격 증명을 출력으로 참조 할 수 있음을 보여줍니다. 이 예제는 또한 세션 토큰을 가져 와서이 조치로 전달되는 상황에서 aws-session-token 입력을 사용할 수 있음을 보여줍니다.
이 코드는 MIT 라이센스에 따라 제공됩니다.
이 프로젝트에서 잠재적 인 보안 문제를보고하려면 GitHub 문제를 만들지 마십시오. 대신 여기 지침을 따르거나 AWS 보안을 직접 이메일로 보내주십시오.
