BLOG
애플리케이션 설계자들은 그들의 시스템을 설계하고 구현하는 과정에서 중요한 결정에 직면하게 됩니다. 거의 모든 솔루션에 공통적으로 적용되는 한가지 결정은 애플리케이션 구성의 스토리지 및 액세스 권한을 관리하는 방법입니다. 공유된 구성은 각 시스템 구성 요소의 작동에 필요한 속성에만 액세스 할 수 있도록 중앙에 안전하게 저장되어야 합니다.
AWS Systems Manager Parameter Store를 사용하여, 개발자는 애플리케이션 구성과 비밀 유지를 위해 중앙 집중형의 안전하고 내구성이 뛰어난 고가용성 스토리지에 액세스 할 수 있습니다. Parameter Store 는 AWS IAM 과도 통합이 되는데 이는 계층의 부서 혹은 개별 파라미터에 대한 세분화된 액세스 제어를 지원합니다.
이 포스트는 AWS Lamda에서 Parameter Store에 있는 공유 구성을 만들고 액세스 하는 방법을 보여 줍니다. 암호화된 매개 변수와 일반 텍스트 매개 변수 값 모두 비밀 번호를 해독할 수 있는 권한이 탑재된 Lamda 기능과 함께 저장됩니다. AWS 엑스레이를 사용하여 기능을 프로파일링 할 수도 있습니다.
솔루션 개요
이번 예는 다음의 요소를 구성하고 있습니다.
- 다음을 정의하는AWS SAM 템플릿
- Lamda 기능과 승인 (permission)
- Lamda 기능이 적재하는 암호화되지 않은 Parameter Store 의 매개변수
- Lamda 기능만 액세스 할 수 있는 KMS키. 이 키를 사용하면 나중에 암호화된 매개 변수를 생성할 수 있습니다.
- 요청서 (invocation) 전반에 걸쳐 재사용하기 위한 기능 초기화 시에 Parameter 스토어에서 값을 적재하는 방법을 보여 주는 파이썬의 3.6의 Lamda 기능 코드.
AWS SAM 템플릿 런칭
이 게시물에 표시된 리소스를 생성하려면 SAM템플릿을 다운로드하거나 stack을 시작하기 위한 버튼을 선택하면 됩니다. 이 템플릿에는 IAM사용자 이름이라는 Parameter가 필요합니다. 이는 IAM사용자가 생성하는 KMS키의 관리자 역할을 하는 이름입니다.
이 포스트에 열거된 단계를 수행하려면, 이 IAM사용자가 Lamda 기능을 실행하고, Parameter Store에 매개 변수를 생성하고, KMS에서 키를 관리하고, X-ray 콘솔을 볼 수 있는 권한이 있어야 합니다. IAM사용자 계정에 이러한 권한이 있는 경우 사용자 자신의 계정을 사용하여 관리운용 검토를 완료할 수 있습니다. 루트 사용자를 이용하여 KMS키를 관리할 수는 없습니다.
SAM 템플릿 자원
다음 섹션은 이 템플릿에 정의된 리소스 용 코드를 보여줍니다.
이 YAML코드에서는 ParameterStoreBlogFunctionDev이란 이름의 Lamda 기능을 SAM AWS:Serverless:Function 타입을 사용하여 정의합니다. 이 기능의 환경 변수에는 ENV(dev.)와 APP_CONFIG_PATH가 포함되어 있으며, 여기서Parameter Store의 애플리케이션에 대한 구성을 찾을 수 있습니다. X-ray 추적 기능 또한 후에 프로파일링을 위해 설정할 수 있습니다.
이 기능의 IAM역할은X-ray에 쓰고 /dev/parameterStoreBlog*에 속한 경로에 제한하는 Parameter Store 에서 매개변수를 얻을 수 있게 돕는 기능 허가를 부여하는 IAM 정책을 추가함으로써 AWSLambdaBasicExecutionRole 를 확장하는 것입니다.
이 YAML코드는 아래 두 가지를 포함하는 키 정책으로 암호화 키를 생성합니다.
첫 번째 문장은 주어진 사용자 ($IAmusername})가 키를 관리하도록 허용합니다. 중요한 점은 이 키를 사용하여 value를 암호화하고 이 키를 비활성화 또는 삭제할 수 있는 기능이 포함되어 있지만, 관리자가 이 키로 암호화한 값을 해독할 수 없습니다.
두 번째 문장은 이 키를 사용하여 값을 암호화하고 해독할 수 있는 Lamda 기능 권한을 부여합니다. KMS의 이 키 별칭은 ParameterStoreBlogKeyDev이며, 이를 참고해주시기 바랍니다.
Lamda 기능
Lamda 기능 코드에 대해서 차례대로 알려드리겠습니다.
‘Import (가져오기)’아래의 AWS X-ray 라이브러리에서 patch_all기능을 가져옵니다. 이 기능을 사용하면 모든 boto 3작업에 대한 X-ray 세그먼트를 생성하기 위해 boto3에 패치를 적용할 수 있습니다.
다음으로, 다음 Lamda best practice에 따라 글로벌 범위에서 Boto3 SSM클라이언트를 생성하여 여러 기능 호출에서 재사용할 수 있습니다. 기능 환경 변수를 사용하여 Parameter Store에서 구성을 찾을 수 있을 것으로 예측되는 경로를 설정합니다. 클래스 My App은 설치 시 구성을 주입해야 하는 애플리케이션의 예로 사용하도록 되어 있습니다. 이 예에서는 Python의 표준 라이브러리에 있는 기본 설정을 취급하는 클래스인 ConfigParser를 생성하여 My App에 제공할 수 있습니다.
load_config기능은 Lamda 기능 환경변수에 제공된 경로 바로 아래 레벨에서 Parameter Store의 모든 매개 변수를 탑재합니다. 발견된 각 매개 변수는 ConfigParser의 새 섹션에 추가됩니다. 섹션의 이름은 기본 경로를 제거한 나머지 매개 변수의 이름입니다. 이 예의 전체 Parameter 이름은/dev/dev/parameterStoreBlog/ap .onfig이고 appConfig라는 섹션에 존재하고 있습니다.
마지막으로 lambda_Handler기능은 My App인스턴스가 아직 존재하지 않는 경우 이를 초기화하여 Parameter store에 탑재된 구성으로 이를 설정합니다. 그런 다음엔 MyApp의 현재 탑재된 설정을 반환하게 됩니다. 이 설계의 영향은 Lamda 기능 실행 환경이 처음으로 초기화될 때 Parameter스토어에서만 구성이 로드된다는 것입니다. 이후 요청(invocation)이 발생하면 기존의 MyApp인스턴스가 재사용되어 성능이 향상됩니다. 구성 변경 사항을 즉시 수신해야 하는 고급 사용 사례의 경우에는 구성 항목에 대한 만료 정책을 구현하거나 기능에 대한 통지를 push할 수 있습니다.
모든 것이 성공적으로 만들어졌음을 확인하기 위해서 Lamda 콘솔에서 기능을 테스트합니다.
- Lamda 콘솔 열기
- Navigation pane에서 ‘기능’ 선택
- ‘기능’에서 ParameterStoreBlogFunctionDev를 필터로 걸고 SAM 템플릿이 만든 기능을 찾습니다.
- ‘상세 기능’페이지의 오른쪽 윗부분에서 ‘text’ 를 선택합니다. 신규 테스트를 만들어야 할 수도 있습니다 .JSON input 은 이 기능이 input 을 무시하기에 해당사항이 없습니다.
테스트를 한 뒤에 아래와 같은 output 을 보실 수 있을 겁니다. 이는 이 기능이 Parameter 저장소에서 암호화되지 않은 구성을 성공적으로 가져왔음을 보여 줍니다.
암호화된 Parameter 만들기
지금 간단하고 암호화 되지 않은 parameter 와 이에 액세스할 수 있는 Lamda 기능을 가지고 계실 겁니다. 다음은 당신만의 Lamda 기능이 암호 해독을 위해 사용할 수 있는 암호화된 parameter 를 만들어야 합니다. 이는 이 파라미터에 대한 읽기 액세스를 이 Lamda 기능으로만 제한합니다. 이 섹션을 진행하려면 이 게시물에 대한 SAM템플릿을 사용자의 계정에 배포하고, IAM사용자 이름을 앞에서 언급한 KMS 주요 관리자로 지정합니다.
- System Manager console 에서 ‘공유 리소스’ 밑에 ‘Parameter Store’ 를 선택
- 매개변수 만들기
-이름은 /dev/parameterStoreBlog/appSecrets 넣기
– ‘타입’ 으로는 ‘ 스트링 확보’ 선택
– ‘KMS 주요 ID’ 로는 SAM 템플릿이 만든 키인 alias/ParameterStoreBlogKeyDev 선택
– Value 로는 {“secretKey”: “secretValue”} 넣기
– ‘매개변수 만들기’ 선택
3. 이제 Parameter 목록에서 매개 변수 이름을 선택하고 값 필드 옆에 ‘표시’를 선택하여 이 매개 변수의 값을 보려고 하면 값이 나타나지 않습니다. 이는 이 KMS키를 사용하여 값을 암호화할 수 있는 사용 권한이 있지만 값을 해독할 수 있는 권한이 없기 때문입니다.
4. Lamda 콘솔에서 기능을 다시 테스트합니다. 이제 사용자가 생성한 비밀 매개 변수와 해독된 값도 표시됩니다.
Lamda 출력에 새 파라미터가 표시되지 않는 경우 Lamda 실행 환경이 이전 테스트에서 여전히 활동적이기 때문일 수 있습니다. 매개 변수는 Lamda 시동 시 로드되기 때문에 값을 새로 고치려면 새로운 실행 환경이 필요합니다.
Lamda Configuration탭 하단의 ‘고급 설정’에서 기능 타임아웃을 다른 값으로 조정합니다. ‘저장 후 테스트’를 선택하여 새 람다 실행 환경을 생성합니다.
결론
중복 제거, 암호화 및 공유 구성과 기밀에 대한 제한적인 액세스는 성숙한 아키텍처의 핵심 구성 요소입니다. Lamda와 같이 이벤트 중심의 온디맨드 컴퓨팅 서비스를 사용하여 설계된 서버리스 아키텍처도 다르지 않습니다.
이 게시물에서는 Parameter 저장소에서 암호화 되지 않았거나 혹은 암호화된 값에 액세스 하는 샘플 애플리케이션을 안내하였습니다. 이러한 값은 액세스가 필요한 기능에만 제한된 비밀 값을 해독할 수 있는 액세스를 사용하여 애플리케이션 환경 및 구성 요소 이름으로 계층에서 생성되었습니다. 여기에 사용된 기술은 엔터프라이즈 서버리스 애플리케이션에서 안전하고 강력한 구성 관리의 기반이 될 수 있습니다.
원문 URL : https://aws.amazon.com/ko/blogs/compute/sharing-secrets-with-aws-lambda-using-aws-systems-manager-parameter-store/
** 메가존 TechBlog는 AWS BLOG 영문 게재글중에서 한국 사용자들에게 유용한 정보 및 콘텐츠를 우선적으로 번역하여 내부 엔지니어 검수를 받아서, 정기적으로 게재하고 있습니다. 추가로 번역및 게재를 희망하는 글에 대해서 관리자에게 메일 또는 SNS페이지에 댓글을 남겨주시면, 우선적으로 번역해서 전달해드리도록 하겠습니다.