KMS로 인증 정보를 암호화 하고 Lambda 실행시에 복호화 하기

원문: KMSで認証情報を暗号化しLambda実行時に復号化する

데이터베이스나 API서버와 같은 외부 시스템과 연결하는 경우 종종 인증 정보를 필요로 하게 됩니다.

이번에는 AWS Key Management Service(이하 KMS)의 공통 키 암호방식을 사용하여 암호화 된 인증 정보를 AWS Lambda 함수의 코드에 포함 된 함수 호출시 인증 정보를 해독하는 방법을 소개합니다.

decrypt-sensitive-data-with-kms-on-lambda-invocation

기본적인 아이디어는 다음 블로그에 쓰여져 있으며, 이 포스팅에서는 KMS를 사용한 암호화 작업만을 추려내었습니다.

http://ijin.github.io/blog/2015/08/06/github-to-lambda-to-slack/

KMS는 마스터 키를 사용한 암호화와 복호화 처리를 API로 분리해 내었기 때문에 이를 사용하여 인증 정보를 암호화 합니다.

KMS와 Lambda의 연계

다음의 순서로 동작을 확인합니다.

  1. AWS KMS 마스터 키 생성
  2. AWS CLI로 마스터 키를 사용하여 암호화와 복호화 처리를 확인
  3. AWS Lambda에서 암호화 된 데이터(ciphertext)를 복호화 하여 출력
  4. AWS Lambda 함수에 KMS:Decrypt 권한을 부여
  5. AWS Lambda 함수를 실행하고 복호화 되어 있는지를 확인

KMS 마스터 키 생성

우선 Lambda 함수에서 사용할 마스터 키를 만듭니다.

관리 콘솔에 로그인한 후 IAM에서 Encryption Keys를 선택하면 KMS관리 화면으로 이동할 수 있습니다. KMS라는 이름은 메뉴상에서는 존재하지 않으므로 주의하시기 바랍니다.

kms_management_console

KMS 키는 리전에 보관됩니다. Filter의 풀다운 메뉴에서 키를 생성하는 지역을 선택하고 “Create Key”를 클릭하여 마스터 키 생성화면으로 이동합니다.

Key Administrative Permissions 와 Key Permissions 에는 평소 사용하는 시스템 관리자를 선택합니다.

AWS CLI에서 암호화및 복호화 처리 확인

프로그램을 작성하기 전에 CLI에서 암호화 및 복호화 작업을 확인합니다.

마스터키의 일람을 확인합니다.

$ aws kms list-keys
{
    "Keys": [
        {
            "KeyArn": "arn:aws:kms:ap-northeast-1:123456789012:key/xxx-yyy-zzz",
            "KeyId": "xxx-yyy-zzz"
        }
    ],
    "Truncated": false
}

마스터키의 ARN을 환경변수에 설정합니다. 키를 지정하는 방법에는 KeyId 또는 별칭(Alias)을 사용하는 두가지 방법이 있습니다.

$ export KEYID=arn:aws:kms:ap-northeast-1:123456789012:key/xxx-yyy-zzz # KeyId
$ export KEYID=arn:aws:kms:ap-northeast-1:123456789012:alias/lambda # Alias

마스터키를 사용한 복호화

마스터키로 암호화를 하기위해서는 Encrypt API를 사용합니다.

$ aws kms encrypt --key-id $KEYID --plaintext 'hello, world!'
{
    "KeyId": "arn:aws:kms:ap-northeast-1:123456789012:key/xxx-yyy-zzz",
    "CiphertextBlob": "CiAUkK3nep3+LDfCjRPA5NDnd5NEXv5BWWjweqEySvaTLBKUAQEBAgB4FJCt53qd/iw3wo0TwOTQ53eTRF7+QVlo8HqhMkr2kywAAABrMGkGCSqGSIb3DQEHBqBcMFoCAQAwVQYJKoZIhvcNAQcBMB4GCWCGSAFlAwQBLjARBAxHrDshpbxSGRgMAXECARCAKHfUd1sJjxRX/7tq7twil6vaXjtPZsnr9AURI1gjR+RPL4WlQTvNDjE="
}

응답(response)의 Plaintext는 복호화한 데이터(즉 plaintext)를 base64로 엔코드한 것 입니다.

base64로 디코드하면 plaintext가 됩니다.

$ aws kms decrypt --ciphertext-blob fileb://encrypted --query Plaintext --output text | base64 --decode
hello, world!

Lambda 함수화

KMS로 암호화 한 후 base64로 엔코딩한 문자열을 람다 함수내에 적어넣어 Lambda함수 실행시에 복호화해 보겠습니다.

보통은 암호화한 유저데이터를 사용하여 무언가 처리를 하지만 이번에는 복호화한 문자열을 그대로 반환합니다.

Lambda함수는 파이썬으로 구현하였습니다.

import base64
import boto3

# base64 encoded ciphertext
ciphertext_blob_encoded = 'CiAUkK3nep3+LDfCjRPA5NDnd5NEXv5BWWjweqEySvaTLBKUAQEBAgB4FJCt53qd/iw3wo0TwOTQ53eTRF7+QVlo8HqhMkr2kywAAABrMGkGCSqGSIb3DQEHBqBcMFoCAQAwVQYJKoZIhvcNAQcBMB4GCWCGSAFlAwQBLjARBAxHrDshpbxSGRgMAXECARCAKHfUd1sJjxRX/7tq7twil6vaXjtPZsnr9AURI1gjR+RPL4WlQTvNDjE='

# ciphertext
ciphertext_blob = base64.b64decode(ciphertext_blob_encoded)

def lambda_handler(event, context):
    kms = boto3.client('kms')
    dec = kms.decrypt(CiphertextBlob = ciphertext_blob)
    return dec['Plaintext'] #plaintext

변수 ciphertext_blob_encoded 에는 ciphertext를 base64로 엔코드한 문자열을 설정했습니다. 위에서 CLI로 암호화한 문자열을 적어줍니다.

KMS 사용권한을 Lambda 함수에게 부여한다

Lambda함수에 설정한 역할(Role)에 마스터키를 사용한 복호화 권한을 추가합니다. 역할에 인라인 정책(Inline policy)을 추가합니다.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "Stmt1448696327000",
            "Effect": "Allow",
            "Action": [
                "kms:Decrypt"
            ],
            "Resource": [
                "arn:aws:kms:ap-northeast-1:123456789012:key/xxx-yyy-zzz"
            ]
        }
    ]
}

Resource에는 KMS 마스터키의 arn을 설정합니다.

Lambda 함수를 실행한다

$ aws lambda invoke \
        --function-name kms_demo \
        --payload '' \
        response.txt
{
    "StatusCode": 200
}

$ cat response.txt
"hello, world!"

무사히 복호화 되었군요.

마무리

민감한 정보는 KMS로 암호화 함으로서 프로그램의 소스코드 내에 안심하고 적어넣을 수 있습니다. 소스코드와 KMS의 Decrypt API를 실행권한을 모두 획득하지 않는 이상 원래 정보를 손에 넣는것은 불가능합니다.

KMS는 어떻게 써야 하는지 잘 모르겠다고 하는 이야기가 가끔 들려오지만 사용법이 단순하면서도 보안성을 높이는데 있어서 대딘히 강력한 서비스 입니다. 이번 포스팅에서는 이러한 KMS의 유즈케이스를 소개해 보았습니다.

AWS Lambda 를 이용한 테스트 구현

원문: http://engineering.pivotal.io/post/running-tests-in-aws-lambda/

본 포스팅에서는 s3cli라는 S3 및 S3호환 Go_lang 기반 클라이언트의 동작 테스트를 위해 AWS Lambda 를 사용한 예를 소개하고 있습니다. 이는 Cloud FoundryBOSH로 알려진 시스템들이 S3나 Swift와 같은 외부 Blob store에 다양한 파일 및 데이터를 저장하기 위해 사용되고 있는 도구 입니다.

아래에 소개되는 테스트의 내용은, AWS access_key_id 및 secret_key_id 없이 IAM Role 을 사용하는 경우 문제없이 S3 버켓에 주어진 권한을 사용해서 접근해야 하는 기능을 테스트하기 위해 구현되었습니다. IAM Role은 AWS가 제공하는 서비스간 상호 접근을 위해 IAM을 통해 할당받은 별도의 사용자 키가 없이도 다른 서비스에 접근 권한을 지정할 수 있는 방법입니다. 권한이 지정된 IAM Role 이 활성화된 상태로 구동된 EC2에서 동작하는 AWS SDK는 인증 정보가 코드에 주어지지 않더라도 내부적으로 임시 인증을 할당 받는 방법을 사용하여 다른 서비스에 접근할 수 있습니다.

EC2 를 사용한 테스트

이러한 IAM Role 기능은 AWS 서비스에서만 유효한 것이며, 따라서 종래의 s3cli 에 대한 기능 테스트 방법은 EC2와 S3 버켓을 준비하고 s3cli가 EC2 위에서 문제없이 동작하는지 확인하는 것이었습니다. 이 테스트를 위해 이전에 우리는 다음과 같은 방법을 사용했었습니다.

  1. CloudFormation 을 사용하여 VPC, IAM Role, 그리고 CI worker로 부터 SSH를 받을 수 있도록 구성된 EC2 인스턴스를 start
  2. 생성된 EC2 인스턴스에 s3cli 바이너리를 SCP로 복사하고 실행하여 바이너리가 의존성 문제 없이 동작하는지 확인
  3. CI Worker는 EC2 인스턴스에 SSH 로 접근하여 테스트를 수행하고 0 이외의 exit 이 발생했는지 확인

위에 설명된 방법의 문제는 일단 CloudFormation 을 사용한 환경의 구성에 시간이 매우 오래 걸린다는 것과, 테스트를 위해 관련이 없는 자잘한 리소스들이 함께 생성되어 비용을 낭비한다는 점, 그리고 기본적으로 이 잠깐의 테스트 하나를 위해 사용되는 EC2의 비용이 낮지 않다는 점에 있습니다. 이를테면 CloudFormation 은 VPC를 생성 수의 제한, EC2 생성 수의 제한등, s3cli의 기능 테스트와는 관계 없는 다른 수많은 원인으로 인해 스택의 생성이 실패할 수 있는 가능성이 있기 때문에, 이를 추적하기 위한 시간과 비용의 낭비를 초래할 가능성이 있겠습니다.

Lambda 를 사용한 테스트

AWS Lambda는 이런 문제를 해결하기에 매우 적절한 도구입니다. Lambda는 이런 간단한 테스트를 위해 EC2를 구동하기 위해 필요한 전체 네트워크 스택과 CloudFormation을 사용할 필요를 없앨 수 있습니다. 또한 CloudFormation을 사용해 스택을 구성하고 EC2 인스턴스를 기동하는데 필요한 기나긴 시간을 낭비할 필요도 없습니다.

한가지 더, s3cli의 기능을 테스트하기에 더 없이 좋았던 것중 하나는 바로 s3cli 도구의 IAM Role 을 사용한 AWS 서비스 연동의 테스트에 10초 이상 필요하지 않다는 것입니다. 즉, 기존 한번 켜면 무조건 1시간의 EC2 비용을 지불하는 대신 10초의 Lambda 사용료만 지불하면 되므로 매우 저렴한 테스트를 구현할 수 있게 된 것입니다.

현재 AWS Lambda 를 사용하는데 있어 제약 조건 중 하나는 바로 Node.js, Python, Java 이 세가지만 사용할 수 있다는 것입니다. 또한 별도의 BASH 지원이 없으므로 임의의 패키지를 만들어 업로드 하는 방법을 사용하고, 이 업로드된 패키지를 읽기 전용 파일 시스템을 통해 접근해서 구동합니다. (물론 Lambda 에서도 /tmp 를 사용하면 파일시스템에 읽기 쓰기 모두 가능합니다.)

배포용 패키지 작성

위에 설명한 방법을 사용하여 s3cli를 테스트 하고 그 결과를 확인하기 위해 아래의 코드를 참조합니다. 여기 예제에서는 Ginko 를 사용 했습니다.

import os
import logging
import subprocess

def test_runner_handler(event, context):
    os.environ['S3_CLI_PATH'] = './s3cli'
    os.environ['BUCKET_NAME'] = event['bucket_name']
    os.environ['REGION'] = event['region']
    os.environ['S3_HOST'] = event['s3_host']

    logger = logging.getLogger()
    logger.setLevel(logging.DEBUG)

    try:
        output = subprocess.check_output(['./integration.test', '-ginkgo.focus', 'AWS STANDARD IAM ROLE'],
                                env=os.environ, stderr=subprocess.STDOUT)
        logger.debug("INTEGRATION TEST OUTPUT:")
        logger.debug(output)
    except subprocess.CalledProcessError as e:
        logger.debug("INTEGRATION TEST EXITED WITH STATUS: " + str(e.returncode))
        logger.debug(e.output)
        raise

위에 사용된 Lambda 함수는 매우 간단합니다. 첫째, event를 통해 필요한 환경 변수를 가져옵니다. 이 event는 Lambda 함수가 호출될때 함께 전달 됩니다. 그리고 테스트에서 발생하는 로그를 확인하기 위해 STDOUT과 STDERR 로거를 구성합니다. 또한 Lambda의 exit 코드를 확보하기 위해서 try 블럭 안에 서브 프로세스 콜을 구성하고 subprocess.CalledProcessError를 통해 로그를 확보합니다.

s3cli와 테스트를 위한 실행 파일들이 스크립트로서 동일한 디렉토리에서 호출되는 것에 주의 합니다.

다음으로, 테스트 도구와 s3cli에 64-bit Linux 아키텍처를 사용하도록 컴파일 옵션을 구성합니다.

git clone https://github.com/pivotal-golang/s3cli
cd s3cli
GOOS=linux GOARCH=amd64 go build s3cli/s3cli
GOOS=linux GOARCH=amd64 ginkgo build src/s3cli/integration

이제 필요한 파일을 모두 묶어 패키지로 구성합니다.

zip -j deployment.zip src/s3cli/integration/integration.test s3cli lambda_function.py

AWS 환경 준비

s3cli 테스를 위한 사전 준비는 아래와 같습니다.

  • 테스트용 S3 버켓 생성
  • AWS IAM 사용자 생성 A) Lambda 함수 실행 권한 B) CloudWatch 읽기/쓰기 권한 다음 링크의 정책을 적용
  • AWS IAM Service role 생성 AWS Lambda 서비스가 CloudWatch와 S3버켓에 다음의 권한을 허용하도록 구성 s3::GetObject*, s3::PubObject*, s3::List*, s3::DeleteObject*. 이 Role을 생성할때 “AWS Lambda”를 선택하여 Lambda가 CloudWatch와 S3에 쓰기 접근을 할 수 있도록 구성. 이 과정을 거쳐 신규로 생성된 IAM Role 의 ARN 정보를 복사해 두는 것을 잊지 않고 생성될 Lambda 함수에 IAM_ROLE_ARN 환경 변수로 전달 해야 함.

위의 설정 구성은 CloudFormation 템플릿을 사용하여 간편하게 구성이 가능합니다. 아래에 소개된 단계는 AWS 명령줄 인터페이스 를 설정하고 사용하는 방법에 대해서 소개합니다.

# example session
$ aws configure

AWS Access Key ID [****************AAAA]:
AWS Secret Access Key [****************AAAA]:
Default region name [us-east-1]:
Default output format [json]:

Lambda 함수 실행

이제 우리는 압축된 배포 패키지를 준비했으므로 아래의 AWS 명령을 사용하여 Lambda 함수를 생성하고 호출할 수 있습니다.

aws lambda create-function \
  --region us-east-1 \
  --function-name MY_LAMBDA_FUNCTION \
  --zip-file fileb://deployment.zip \
  --role ${IAM_ROLE_ARN} \
  --timeout 300 \
  --handler lambda_function.test_runner_handler \
  --runtime python2.7

aws lambda invoke \
  --invocation-type RequestResponse \
  --function-name MY_LAMBDA_FUNCTION \
  --region us-east-1 \
  --log-type Tail \
  --payload '{"region": "us-east-1", "bucket_name": "YOUR_BUCKET_NAME", "s3_host": "s3.amazonaws.com"}' \
  lambda.log

중요: 위의 내용에 fileb:// 는 잘못 기재된 것이 아님 fileb

aws lambda invoke 명령의 실행 결과는 아래와 같이 JSON 으로 표시 될 것입니다.

{
  "LogResult": "<BASE64 ENCODED OUTPUT TRUNCATED TO LAST 4KB>",
  "FunctionError": "(Unhandled|Handled)",
  "StatusCode": 200
}

첫째로, aws lambda invoke 명령 자체는 실행한 Lambda 함수가 에러 없이 종료 되었는지 아닌지와 관계 없이 동작합니다. 이는 출력되는 FunctionError 키를 통해 해당 Lambda 함수의 실행에 에러가 있었는지를 판단할 수 있으며, 이러한 output에 jq 와 같은 도구를 사용하여 간단히 테스트가 성공인지 실패인지 알수 있겠습니다.

추가적으로, 이 테스트는 기본적으로 4kb 이상의 output 을 생성할 것이며, Base64로 인코딩 된 LogResult를 디코드 하더라도 일부 로그가 삭제되는 현상이 있을 수 있습니다.

완전한 로그를 가져오기

다행이 우리에겐 logging.Logger 로부터 생성되는 console output 은 AWS CloudWatch Logs 로그로 보내도록 구성했습니다. 물론, 이를 위해서는 IAM Role에 Labmda 함수가 로그 그룹, 로그 스트림, 로그 이벤트에 대한 생성 권한이 주어져야 합니다.

CloudWatch 에서 로그를 가져오기 위해서는 Lambda 함수 이름을 바탕으로 로그 그룹의 이름을 사용해야 합니다. 이후 아래의 명령어를 사용하여 누락 없는 전체 로그를 가져올 수 있습니다.

LOG_GROUP_NAME="/aws/lambda/MY_LAMBDA_FUNCTION"
LOG_STREAM_NAME=$(
  aws logs describe-log-streams --log-group-name=${LOG_GROUP_NAME} \
  | jq -r ".logStreams[0].logStreamName"
)
LOG_STREAM_EVENTS_JSON=$(
  aws logs get-log-events \
    --log-group-name=${LOG_GROUP_NAME} \
    --log-stream-name=${LOG_STREAM_NAME}
)

echo ${LOG_STREAM_EVENTS_JSON} | jq -r ".events | map(.message) | .[]"

정리

이와 같은 방법을 사용하면 고가의 EC2 대신 간단한 테스트에 대해 Lambda 를 사용하여 비용과 시간, 그리고 EC2와 VPC 네트워크를 생성하는데 있어 발생할 수 있는 실패요인을 줄일 수 있습니다. 여기서는 s3cli 라는 도구의 IAM Role 동작에 대한 테스트를 구성하는 방법에 대해 기술하였으나, 이와 유사한 목적에 어디든 응용하실 수 있겠습니다.

Amazon API Gateway + Lambda: 텔레그램 및 슬랙 전달 봇 만들기

안녕하세요! GS SHOP에서 IT Driven Open Communication 이라는 프로젝트를 하고 있는 김승연입니다.

저는 전부터 Labmda에 관심이 많았는데요. 아무리 t1.micro로 돌린다고 해도 Tokyo region 기준으로 한 달에 15달러가 나오는게 너무 아깝더라고요. 실제로 서버가 필요한(Web 서버가 요청을 받고 처리하고 응답해주는) 시간은 한 달에 많아도 7분(90ms * 4300 request) 내외였는데 한 달동안 언제든 요청을 받기 위해서 29일 23시간 53분을 기다리는 요금을 내는게 비효율적이라고 생각했어요.

하지만 Lambda는 EC2와는 달리 가입 후 12개월이 지나도 프리티어를 유지해주고 저 정도의 request면 무료로 이용이 가능했습니다!

Lambda-Free

Lambda-Bill

그래서 Lambda를 좋아하고, 이번에 회사에서 텔레그렘을 이용하는 팀과 슬랙을 이용하는 팀이 같이 소통해야될 일이 있어서 텔레그렘과 슬랙을 이어주는 봇을 만들어주면 어떨까? 하는 생각이 있어서 Lambda랑 API Gateway로 만들고 과정 일부를 공유하면 재밌겠다 싶어서 이 글을 쓰게 되었습니다 😀

Lambda 시작하기

먼저 Lambda console에 들어가봅시다! 좌측의 Create a Lambda function 클릭 여러 가지 형태의 lambda function을 만들 수 있는데 한 단계씩 올라갈 것이기 때문에 일단 Skip 하겠습니다! Name에는 TelegramToSlack, 그리고 저는 Python 2.7을 이용할게요. 코드는 Code entry type은 Edit code inline을 선택하고 내용은 간단하게 event를 그대로 return해볼게요.

def lambda_handler(event, context):
  return event

Nodejs version: https://gist.github.com/news700/6f1cbe80663a8965a0832ad277b4970e

Lambda function에는 eventcontext 두 개의 파라미터가 넘어오는데, event는 lambda function으로 넘어오는 파라미터들이 Dictionary 형태로 넘어오는 곳이고 context는 함수 이름, 버젼, arn, 메모리 제한, 남은 시간 등을 가져올 수 있는 객체에요..

넘어가서 handlerrole을 정해줘야하는데요. 기본으로 Handler에는 lambda_function.lambda_handler라는 값이 들어있어요. lambda_function이라는 모듈의 lambda_handler라 는 함수를 사용하겠다는 의미인데 inline으로 코드를 편집하게 되면 우리가 편집하는 코드의 파일명이 lambda_function.py이기 때문에 지금 우리가 짠 함수를 실행하겠다는 의미가 돼요. 나중에 프로젝트의 크기가 커지면 파일을 분리하게 되고 AWS Lambda가 실행해야할 함수를 찾아야될 때 이 값을 조정해서 사용하게 돼요.

Role은 이 함수가 어떤 권한을 가지고 실행될 것이냐를 결정해요. 최소한 lambda function을 실행할 수 있는 권한을 포함해야돼요. 그 외에 우리가 짜는 코드가 필요한 권한이 있다면(dynamodb에 데이터를 작성한다던가) 적절히 AWS IAM에서 Role을 생성하여 선택해주면 돼요. 일단 우리는 콤보박스에서 Create New Role 안의 Basic execution role을 이용할게요. lambda를 실행할 수만 있는 권한이에요. 일단 Role을 생성해준 뒤 해당 Role을 선택하여 사용할 수 있어요. Basic execution role을 클릭하면 새로운 창이 열려요(혹시 팝업이 차단돼서 안열릴 수 있으니 확인해보세요!)

IAM Management Console 창이 새로 떴는데 IAM Role에는 Create a new IAM Role을 선택해주시고 Role Name은 lambda_basic_execution으로 할게요. Allow 하고 돌아오면 Role에 lambda_basic_execution이 생성돼 있어요. 혹시 생성돼있지 않다면 새로고침을 해주세요! 다른 내용은 임시저장돼있어요 ㅎㅎ

여기까지 했다면 대략 이런 화면이 됐을거에요

Create-Lambda

Memory와 Timeout은 사용할 수 있는 memory와 최대 실행시간을 정하는건데요. 기본 값으로 두고 넘어갈게요. Next를 누르고 Create function을 누르면 Congratulations! Your Lambda function “TelegramToSlack” has been successfully created. 라는 메시지가 상단에 뜨네요!

그 위에 Test 버튼이 있어요. 이 함수를 웹상에서 테스트를 해볼 수 있는 기능이에요. JSON 형태로 파라미터를 지정할 수 있는데 이 파라미터들은 event변수에 dictionary 형태로 전달돼요. Hello World template 그대로 Save and test를 눌러봅시다. 그러면 아랫쪽에 Execution result: succeeded를 확인하실 수 있어요! 넘겼던 파라미터들이 잘 return된 모습을 확인할 수 있어요.

이렇게 Lambda의 기본 사용법을 알아봤습니다. 이제 API Gateway와의 연동을 진행해볼게요.

Lambda의 API Gateway 연동

이제 API Gateway Console로 들어가보죠. 파란색 Create API 버튼을 눌러주세요. API name에는 뭐 .. 음 .. Telegram으로 해볼게요. 이제 Create API를 눌러주세요.

이렇게 API Gateway에서 API를 생성해줬어요. Lambda와 연동해주기 위해 다시 Lambda console로 가서 TelegramToSlack을 선택해주세요. 화면에 보면 Code 탭 옆쪽에 API Endpoints 라는 탭이 있는 걸 확인할 수 있습니다.

API-Endpoints-Tab

누르고 들어가서 Add API endpoint를 클릭, API endpoint type에 API Gateway를 선택해주세요. API name을 클릭하면 Telegram이 보일거에요. Telegram을 선택해주시고 Resource name은 API path를 의미해요. /to-slack 정도로 해줄게요. Method는 POST로 설정해주세요. Telegram Bot이 POST요청을 보낼거에요. Deployment stage는 여러 단계의 stage를 두고 API 버젼을 따로 관리할 수 있는데 기본값 prod 그대로 두겠습니다. Security는 Open으로 설정해줘야 Telegram Bot이 들어올 수 있어요. 이제 Submit을 클릭합시다!

Add-Endpoint

이제 다시 API Gateway console로 가서 Telegram을 선택해보면 /to-slack 이 추가돼있는 것을 볼 수 있어요. 클릭해보면 Test를 해볼 수 있어요.

To-Slack-Added

Request body에 {“foo”: “bar”} 를 입력하고 Test를 눌러보면 response가 잘 오는 것을 확인할 수 있어요.

To-Slack-Test

Telegram Bot 세팅하기

Telegram Bot API에는 setWebHook이라는 API가 있는데요. 봇이 볼 수 있는 메시지를 설정한 https 주소로 보내주는 기능입니다. 먼저 Telegram에서 봇을 만들게요. https://core.telegram.org/bots 에 따라 텔레그렘에서 botfather 를 검색해 대화를 시작하면 Bot을 생성하고 API Key를 줍니다. 그 뒤에 텔레그램 Group에서 봇이 메시지를 받기 위해서는 privacy 모드를 해제해줘야돼요. botfather에게 /setprivacy 명령을 이용해 해제할 수 있어요.

Telegram

Lambda console의 API endpoints 탭에 가보면 API endpoint URL이 있습니다. Telegram bot의 web hook을 해당 URL로 걸어줄게요.

$ curl https://api.telegram.org/bot<API TOKEN>/setWebhook?url=<API endpoint URL>
{"ok":true,"result":true,"description":"Webhook was set"}

이제 해당 봇이 참여하는 대화의 메시지들은 우리가 만든 API Gateway로 가고 그 endpoint는 Lambda function을 실행시켜서 POST로 넘어온 값을 그대로 돌려줄겁니다!

Slack에 메시지 보내기

Slack의 Incoming WebHook을 이용해서 쉽게 한 채널에 메시지를 보낼 수 있습니다. Incoming WebHook은 https://slack.com/apps/build -> Make a Custom Integration -> Incoming WebHooks 에서 만들 수 있어요. 메시지를 보낼 채널을 선택하거나 만듭니다. 저는 telegram이라는 채널을 만들었어요. 초록색 Add Incoming WebHooks integration 버튼을 누르면 다음 페이지의 아랫쪽에 Webhook URL을 확인할 수 있어요.

이제 telegram에서 메시지가 올 때 마다 해당 URL에 “asdf”라는 메시지를 보내봅시다. Lambda console에 가서 코드를 다음과 같이 수정해주세요.

import httplib
import json
import urllib

def lambda_handler(event, context):
    conn = httplib.HTTPSConnection('hooks.slack.com')
    conn.request(
        'POST',
        '/services/T01234567/B0123456/abcdefghijklmnopqrstuvwxyz',  # slack에서 받은 webhook path
        urllib.urlencode({'payload': json.dumps({'text': 'asdf'})}),
        {'Content-Type': 'application/x-www-form-urlencoded'}
    )
    conn.getresponse()
    conn.close()

Nodejs version: https://gist.github.com/news700/37ab1ab1aa769c52e0361ee8a8ae0ed9

Save and test를 눌러 실행해보면 Slack telegram 채널에 asdf 라는 메시지가 온 것을 확인할 수 있어요! Telegram에서도 우리가 만든 봇 이름을 검색해서 메시지를 전송해보면 봇한테 메시지를 쓸 때 마다 Slack에 asdf가 오는 것을 확인할 수 있어요!

Slack

이제 Telegram에서 보내주는 포맷에 맞춰 전달받은 텍스트가 있으면 해당 텍스트를 슬랙에 넘겨주는 코드로 바꿔볼게요.

import httplib
import json
import urllib

def lambda_handler(event, context):
    if 'message' not in event:
        return
    if 'text' not in event['message']:
        return
    text = event['message']['text']
    conn = httplib.HTTPSConnection('hooks.slack.com')
    conn.request(
        'POST',
        '/services/T01234567/B0123456/abcdefghijklmnopqrstuvwxyz',  # slack에서 받은 webhook path
        urllib.urlencode({'payload': json.dumps({'text': text})}),
        {'Content-Type': 'application/x-www-form-urlencoded'}
    )
    conn.getresponse()
    conn.close()

Nodejs version: https://gist.github.com/news700/ce8154389f7e0bb7a8cb2b6812a73eb0

Final

이제 코드를 조금 고치면 새로운 방에 초대될 때마다 새로운 슬랙 채널을 만들 수도 있고 작성자도 표시해주거나 사진을 전송할 수도 있겠네요. 새로운 API를 추가해서 슬랙에서 쓴 메시지를 텔레그램에서도 받아볼 수 있겠네요. 여기서부터는 한 번 원하시는대로 직접 만들어보세요!

고맙습니다!