serverless framework에서 .yml 파일을 작성할 때, 개인적으로 AWS Systems
Manager (SSM)의 Parameter Store를 활용하는 방법이 맘에 든다.
parameter store는 secrets manager보다 더 저렴하고 가벼우며, 범용적이기 때문이다. 둘의 차이는 여기에 잘 정리되어있다.
참고로 Systems Mananger는 원래 EC2 Simple Systems Manager이었기 때문에 SSM으로 축약된다고 한다.
변수를 encrypt할 키로 cmk를 선택할 수 있다. 기본 키 사용해도 무방하다
대칭키를 선택해야 한다.
parameter store에 변수를 생성할 계정이 해당 키를 참조해야 하므로 그에 맞추어 adminstrative, usage 권한을 잘 설정해준다.
Parameter store에서 변수를 생성해준다.
이름은 fully qualified여야 한다. 중간에 '/'를 넣을 것이라면 맨 앞에도 넣어주자.
secureString 타입을 선택하고 key source로 위에서 설정한 CMK를 넣어준다. 기본 키를 넣어도 상관없다. 이 키를 통해 파라미터를 암/복호화하게 된다. 자세한 매커니즘은 여기를 참고. 현재는 이 과정에서 대칭키만 사용할 수 있어, 위 과정에서 대칭키를 선택한 것이다.
람다에 붙은 role에 AmazonSSMFullAccess나 ReadOnly를 준다.
serverless를 배포하는 계정에도 SSM 권한이 있어야 한다.
배포 과정에서 해당 환경변수를 참조하는 것은 람다이기에 람다에만 붙이면 된다고 생각했는데, 아니다. 유저에도 붙어있어야 한다. 직접 계정의 SSM 권한을 deny해서 실험해본 결과이다.)
${ssm:변수명}
의 형식이다. 나는 function의 env에 쓸 것이라 아래처럼 해줬다.
functions:
noti:
handler: handler.noti
environment:
BOT_TOKEN: ${ssm:BOT_TOKEN_ENCRYPTED}
CHAT_ID: ${ssm:CHAT_ID_ENCRYPTED}
events:
- schedule: cron(0 10 * * ? *)
serverless framework v3부터는 decrypt를 위해 ~true
옵션을 붙이지 않아도 된다.
v2라면 ${ssm:BOT_TOKEN_ENCRYPTED~true}
처럼 선언해야 한다.
해당 변수를 secureString을 통해 encrypt하지 않은 경우는 신경 쓸 필요 없다.
(해당 변수가 잘 참조되는지 확인하기 위해서는 단순히 deploy를 초반 yml 파일 빌드하는 과정까지만 진행해보는 것이 더 편하다)
Serverless Offline SSM 플러그인을 통해 로컬에서 테스트할 때도 SSM을 사용할 수 있다.
$ npm install serverless-offline serverless-offline-ssm --save-dev
serverless.yml 파일에 추가
plugins:
- serverless-offline-ssm
- serverless-offline
local에서 테스트
$ sls invoke local --function {function name}
이와 관련된 내용은 여기에서 확인