AWS Configの通知をSNS、Lambdaを通してSlackへ 〜準備編〜

2日目も遅れているからってめげたりしません。日付が変わってからネタを決めているこの体たらくを笑って許して。まずは続けることに意義がある、そう思ってやっています。

本日のお題はAWS Config + SNS + Lambda + Slack で行きたいと思います。最近はLambdaをつかってSlackと戯れるのが好きなので許してやってください。今回も突貫ゆえ大したことはできませんが、生暖かく流し読みでもしていただければと思います。

AWS ConfigはAWSのリソースの状況を可視化してくれたり変更を検知して通知してくれ、いわゆる監査的なことに使えるサービスです。詳細はこちら。まあ、細かい部分の説明はブログの会社さんなり、プレミアコンサルティングパートナーの会社さんが書いてくださっているはずですので割愛いたします。

作業開始

SNSの枠を準備

まずはSNSのコンソールから、config-topicというTopicを作成しておきます。Subscriptionは特に設定しなくても良いです。

f:id:matetsu:20151203015337p:plain

Lambda Functionの作成

次にLambda Functionの設定を行います。簡易手順は下記の通り。

  1. Blue print
    • sns-message-pythonを選択(下のキャプチャ参照)
  2. Congirure event source
    • Event source type: SNS
    • SNS Topic: config-topic
  3. Configure function
    • Name: config-bot
    • Description: (そのまま)
    • Runtime: Python2.7
  4. Lambda function code
    • とりあえず通知されるメッセージの中身が見たいので「Edit code inline」を選択して、サンプルをそのまま利用
  5. Lambda function handler and role
    • Handler: (そのまま)
    • role: lambda_exec_role (LambdaからCreate roleするときにデフォルトで作ることができるrole)
  6. Advanced settings
    • Memory: 128MB
    • Timeout: 10sec (なんとなく)
  7. Event source
    • Enable now ※こまけえことは(ry
  8. 「Create function」!!!!

f:id:matetsu:20151203014846p:plain

SNSにLambdaの情報を反映

ふたたびSNSに戻ってきて、subscriptionの設定をします。

  1. Create Subscription
    • TopicARN: (そのまま)
    • Protocol: AWS Lambda
    • Endpoint: 先ほど作成した config-bot のARNを指定
    • Version or ALIAS: default
  2. Create subscription

本日のメインAWS Config

それでは、本題の Config の設定です*1。今回は、Network ACL, Security Group, Route Tableの勝手に触られると困ることの多い3つのリソースに関しての記録を取りたいと思います。

f:id:matetsu:20151203020241p:plain

  1. (はじめてなので)「Get Started Now」
  2. Resource Type: 「EC2: NetworkAcl」「EC2: SecurityGroup」「EC2: RouteTable」
  3. Amazon S3 Bucket
    • Create a new bucketを選択
    • Bucket Name: matetsu-config-record-test (デフォルトのまま or 各自好きな名前をつけてください)
    • Prefix: (今回はなし)
  4. Amazon SNS Topic
    • Enable configuration... にチェックが入っているのでそのまま
    • Choose a topic from your accountを選択
    • Topic Name: config-topic (先に作成しておいたLambdaにEvent通知できるもの)
  5. Continue
  6. (IAMのコンソールになるのでなされるがままに)「許可」
    • 下に示すPolicyで config-role という IAM Roleが作成されます。Policyを編集したい場合は適宜どうぞ。

最初Policyの権限が足りないようなエラーメッセージがでて、最初に戻されたが、もう一度やったら完了した。S3との何か順番的な何かがあったかな?

ちなみに、config-roleはこんなPolicyになってます。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Action": [
        "appstream:Get*",
        "autoscaling:Describe*",
        "cloudformation:DescribeStacks",
        "cloudformation:DescribeStackEvents",
        "cloudformation:DescribeStackResource",
        "cloudformation:DescribeStackResources",
        "cloudformation:GetTemplate",
        "cloudformation:List*",
        "cloudfront:Get*",
        "cloudfront:List*",
        "cloudtrail:DescribeTrails",
        "cloudtrail:GetTrailStatus",
        "cloudwatch:Describe*",
        "cloudwatch:Get*",
        "cloudwatch:List*",
        "config:Put*",
        "directconnect:Describe*",
        "dynamodb:GetItem",
        "dynamodb:BatchGetItem",
        "dynamodb:Query",
        "dynamodb:Scan",
        "dynamodb:DescribeTable",
        "dynamodb:ListTables",
        "ec2:Describe*",
        "elasticache:Describe*",
        "elasticbeanstalk:Check*",
        "elasticbeanstalk:Describe*",
        "elasticbeanstalk:List*",
        "elasticbeanstalk:RequestEnvironmentInfo",
        "elasticbeanstalk:RetrieveEnvironmentInfo",
        "elasticloadbalancing:Describe*",
        "elastictranscoder:Read*",
        "elastictranscoder:List*",
        "iam:List*",
        "iam:Get*",
        "kinesis:Describe*",
        "kinesis:Get*",
        "kinesis:List*",
        "opsworks:Describe*",
        "opsworks:Get*",
        "route53:Get*",
        "route53:List*",
        "redshift:Describe*",
        "redshift:ViewQueriesInConsole",
        "rds:Describe*",
        "rds:ListTagsForResource",
        "s3:Get*",
        "s3:List*",
        "sdb:GetAttributes",
        "sdb:List*",
        "sdb:Select*",
        "ses:Get*",
        "ses:List*",
        "sns:Get*",
        "sns:List*",
        "sqs:GetQueueAttributes",
        "sqs:ListQueues",
        "sqs:ReceiveMessage",
        "storagegateway:List*",
        "storagegateway:Describe*",
        "trustedadvisor:Describe*"
      ],
      "Effect": "Allow",
      "Resource": "*"
    },
    {
      "Effect": "Allow",
      "Action": [
        "s3:PutObject*"
      ],
      "Resource": [
        "arn:aws:s3:::matetsu-config-record-test/AWSLogs/[ACCOUNT_NO]/*"
      ],
      "Condition": {
        "StringLike": {
          "s3:x-amz-acl": "bucket-owner-full-control"
        }
      }
    },
    {
      "Effect": "Allow",
      "Action": [
        "s3:GetBucketAcl"
      ],
      "Resource": "arn:aws:s3:::matetsu-config-record-test"
    },
    {
      "Effect": "Allow",
      "Action": "sns:Publish",
      "Resource": "arn:aws:sns:ap-northeast-1:[ACCOUNT_NO]:config-topic"
    }
  ]
}

Configの設定が完了すると Resource Inventory の画面になります。ここでは、各種リソースがいつ変更されたかとかを見ることができます。初めて見たけど、これ、いいですね!Inventoryからリソースの詳細に移動すると、こんな感じの画面でいろいろ確認ができます。

f:id:matetsu:20151203013710p:plain

そして、Configが作成されるとまず、作成イベントとしてSNSに指定した記録対象Resourceの通知が来ていることが確認できます。確認はCloudWatch LogsからLambda Functionのログを見てみてください。

f:id:matetsu:20151203014012p:plain

ズラーっと出てますね。ここから、どんな形式の通知が来ているかが確認できるので、これを利用してSlackに通知をします。

次回予告

次回は実際に構成変更を検知させて、Slackに通知させる部分をやりたいと思います。

すみません、エネルギー切れです。。。そして、微妙なキャプチャを挟んでなんとなくコンテンツがある風にみせかけててすみません。。。とりあえず触ってみた的な内容なので、(マサカリではなく)ツッコミ歓迎です。

では、また明日。

*1:「Configの設定」って日本語にすると不思議な感じですね