継続は力なり

タイトル通り定期的な更新を心掛けるブログです。

Aurora の特定ユーザー接続検知をするために CloudWatch Logs サブスクリプションフィルターを使う

タダです.

Aurora への接続ユーザーとして管理者ユーザーを使わないように運用していることが多いと思いますが,そんな中で管理者ユーザーで接続された場合ちゃんと検知しておきたいといった要件から検証した内容をこの記事にまとめます.

Aurora のログについて

普段 Aurora MySQL を使っていて接続ユーザーのログは監査ログに残っています.そのため,監査ログを CloudWartch Logs に出力できているのが前提です.

aws.amazon.com

CloudWatch Logs サブスクリプションフィルタ

監査ログは /aws/rds/cluster/cluster-name/audit で出力されています.このログから検知したいユーザーの接続ログをフィルタリングします.フィルタリングには CloudWatch Logs のサブスクリプションフィルタを使います.

docs.aws.amazon.com

フィルタパターンで管理者ユーザーの接続を絞りたいのですが,例えば admin ユーザーであればフィルタパターンでは admin CONNECT などで絞っていきました.加えて rdsadmin というデフォルトで作成されるユーザーのログも記録されるためこのユーザーのログは除外するために admin CONNECT - rdsadmin としました.これで必要な接続ログを送ることができました.

まとめ

簡単ですが,Aurora の接続ユーザーをログから検知するためにやった検証をまとめました.

AWS Lambda のデプロイを Terraform で行う

タダです.

Terraform で Lambda のデプロイをはじめてやったので,備忘録として記事に書いておきます.

Terraform のコード

Terraform のコードは以下のように書きました.Lambda のコードは Node.js を書いたのですが,lambda/hoge ディレクトリに置いておきます.これで terraform apply をしたら Lambda がデプロイされることを確認できました.

resource "aws_lambda_function" "hoge_functions" {
  function_name = "hoge"
  handler       = "index.handler"
  role          = aws_iam_role.hoge.arn
  filename      = data.archive_file.hoge.output_path
  timeout       = 30
  publish       = true

  source_code_hash = data.archive_file.hoge.output_base64sha256
  runtime          = "nodejs14.x"
}

data "archive_file" "hoge" {
  type        = "zip"
  output_path = "${path.module}/lambda/hoge/hoge.zip"
  source_file = "${path.module}/lambda/hoge/index.js"
}

まとめ

今まで AWS SAM や CDK で Lambda のデプロイしてきたのですが,Terraform でデプロイしていけることをしれました.パッケージなどインストールする必要などないみたいな場合はこういう手段でやっていくのを考えていきます.

RDS のパッチの有無を確認する方法

タダです.

RDS 運用しているとパッチが出てきて気づかなかったみたいなことがあります.そのために必要なことを調査をしたのでこの記事にまとめます.

RDS のパッチ適用通知を確認する方法

調査する前は EventBridge か RDS のイベントサブスクリプションからうけとれるのかと思っていました.しかし,これができずパッチを確認するためには DescribePendingMaintenanceActions API 経由で行います.

docs.aws.amazon.com

AWS CLI でやる場合は describe-pending-maintenance-actions コマンドで確認できます.

# イベントがない場合のレスポンス
$ aws rds describe-pending-maintenance-actions 
{
  "PendingMaintenanceActions": [
    {
      "ResourceIdentifier": "arn:aws:rds:us-west-2:123456789012:cluster:global-db1-cl1",
      "PendingMaintenanceActionDetails": [
        {
          "Action": "system-update",
          "Description": "Upgrade to Aurora PostgreSQL 2.4.2"
        }
      ]
    }
  ]
}

# jq で抽出
aws rds describe-pending-maintenance-actions | jq -r '.PendingMaintenanceActions[].ResourceIdentifier' 
arn:aws:rds:us-west-2:123456789012:cluster:global-db1-cl1
aws rds describe-pending-maintenance-actions | jq -r '.PendingMaintenanceActions[].PendingMaintenanceActionDetails[].Action'
system-update

JavaScriptSDK 経由で describePendingMaintenanceActions API を呼び出した場合は次のようなのでいけました.Node.js 16.x の Lambda で検証しました.

const AWS = require('aws-sdk')
const rds = new AWS.RDS();
const params = {
    Filters:[
        {
            Name: "db-cluster-id",
            Values: [
                "arn:aws:rds:ap-northeast-1:xxxx:cluster:hogedb"
            ]
        }
    ]
}
exports.handler = async(event) => {
    console.log("start")
    const hoge = rds.describePendingMaintenanceActions(params,function(err, data) {
        if (err) {
            console.log(err, err.stack)
        } else {
            console.log(data)
        }
    });
    return 'Finish rds patch chek function'
}

レスポンスデータは次のような情報が返ってきます.dataのセクションでパッチ適用があったらそのデータが入ります.

<ref *1> Request {
  domain: null,
  service: Service {
    config: Config {
      credentials: [EnvironmentCredentials],
      credentialProvider: [CredentialProviderChain],
      region: 'ap-northeast-1',
      logger: null,
      apiVersions: {},
      apiVersion: null,
      endpoint: 'rds.ap-northeast-1.amazonaws.com',
      httpOptions: [Object],
      maxRetries: undefined,
      maxRedirects: 10,
      paramValidation: true,
      sslEnabled: true,
      s3ForcePathStyle: false,
      s3BucketEndpoint: false,
      s3DisableBodySigning: true,
      s3UsEast1RegionalEndpoint: 'legacy',
      s3UseArnRegion: undefined,
      computeChecksums: true,
      convertResponseTypes: true,
      correctClockSkew: false,
      customUserAgent: null,
      dynamoDbCrc32: true,
      systemClockOffset: 0,
      signatureVersion: 'v4',
      signatureCache: true,
      retryDelayOptions: {},
      useAccelerateEndpoint: false,
      clientSideMonitoring: false,
      endpointDiscoveryEnabled: undefined,
      endpointCacheSize: 1000,
      hostPrefixEnabled: true,
      stsRegionalEndpoints: 'legacy',
      useFipsEndpoint: false,
      useDualstackEndpoint: false
    },
    isGlobalEndpoint: false,
    endpoint: Endpoint {
      protocol: 'https:',
      host: 'rds.ap-northeast-1.amazonaws.com',
      port: 443,
      hostname: 'rds.ap-northeast-1.amazonaws.com',
      pathname: '/',
      path: '/',
      href: 'https://rds.ap-northeast-1.amazonaws.com/'
    },
    _events: { apiCallAttempt: [Array], apiCall: [Array] },
    MONITOR_EVENTS_BUBBLE: [Function: EVENTS_BUBBLE],
    CALL_EVENTS_BUBBLE: [Function: CALL_EVENTS_BUBBLE],
    _clientId: 1
  },
  operation: 'describePendingMaintenanceActions',
  params: { Filters: [ [Object] ] },
  httpRequest: HttpRequest {
    method: 'POST',
    path: '/',
    headers: {
      'User-Agent': 'aws-sdk-nodejs/2.1083.0 linux/v16.14.0 exec-env/AWS_Lambda_nodejs16.x'
    },
    body: '',
    endpoint: {
      protocol: 'https:',
      host: 'rds.ap-northeast-1.amazonaws.com',
      port: 443,
      hostname: 'rds.ap-northeast-1.amazonaws.com',
      pathname: '/',
      path: '/',
      href: 'https://rds.ap-northeast-1.amazonaws.com/',
      constructor: [Function]
    },
    region: 'ap-northeast-1',
    _userAgent: 'aws-sdk-nodejs/2.1083.0 linux/v16.14.0 exec-env/AWS_Lambda_nodejs16.x'
  },
  startTime: 2022-06-17T06:23:02.561Z,
  response: Response {
    request: [Circular *1],
    data: null,
    error: null,
    retryCount: 0,
    redirectCount: 0,
    httpResponse: HttpResponse {
      statusCode: undefined,
      headers: {},
      body: undefined,
      streaming: false,
      stream: null
    },
    maxRetries: 3,
    maxRedirects: 10
  },
  _asm: AcceptorStateMachine {
    currentState: 'validate',
    states: {
      validate: [Object],
      build: [Object],
      afterBuild: [Object],
      sign: [Object],
      retry: [Object],
      afterRetry: [Object],
      send: [Object],
      validateResponse: [Object],
      extractError: [Object],
      extractData: [Object],
      restart: [Object],
      success: [Object],
      error: [Object],
      complete: [Object]
    }
  },
  _haltHandlersOnError: false,
  _events: {
    validate: [
      [Function (anonymous)],
      [Function],
      [Function: VALIDATE_REGION],
      [Function: BUILD_IDEMPOTENCY_TOKENS],
      [Function: VALIDATE_PARAMETERS]
    ],
    afterBuild: [
      [Function: COMPUTE_CHECKSUM],
      [Function],
      [Function: SET_CONTENT_LENGTH],
      [Function: SET_HTTP_HOST]
    ],
    restart: [ [Function: RESTART] ],
    sign: [ [Function (anonymous)], [Function], [Function] ],
    validateResponse: [ [Function: VALIDATE_RESPONSE], [Function (anonymous)] ],
    send: [ [Function] ],
    httpHeaders: [ [Function: HTTP_HEADERS] ],
    httpData: [ [Function: HTTP_DATA] ],
    httpDone: [ [Function: HTTP_DONE] ],
    retry: [
      [Function: FINALIZE_ERROR],
      [Function: INVALIDATE_CREDENTIALS],
      [Function: EXPIRED_SIGNATURE],
      [Function: CLOCK_SKEWED],
      [Function: REDIRECT],
      [Function: RETRY_CHECK],
      [Function: API_CALL_ATTEMPT_RETRY]
    ],
    afterRetry: [ [Function] ],
    build: [ [Function: buildRequest] ],
    extractData: [ [Function: extractData], [Function: extractRequestId] ],
    extractError: [ [Function: extractError], [Function: extractRequestId] ],
    httpError: [ [Function: ENOTFOUND_ERROR] ],
    success: [ [Function: API_CALL_ATTEMPT] ],
    complete: [ [Function: API_CALL] ]
  },
  emit: [Function: emit],
  API_CALL_ATTEMPT: [Function: API_CALL_ATTEMPT],
  API_CALL_ATTEMPT_RETRY: [Function: API_CALL_ATTEMPT_RETRY],
  API_CALL: [Function: API_CALL]
}

まとめ

RDS のパッチの有無を確認する方法を調べたのでまとめました.こういうのも EventBridge 経由で送られたらいいのになと思います.

SageMaker から Amazon OpenSearch Service への接続方法を調べた

タダです.

小ネタですが,SageMaker Notebook Instance から Amazon OpenSearch Service(Elasticsearch)への接続をする機会がありどうやってやるのかなと思って調べたり検証したので,この記事にまとめます.

TL;DR

SageMaker Notebook Instance にはセキュリティグループの設定ができるので,Amazon OpenSearch Service のセキュリティグループで HTTPS の接続を許可してあげれば接続ができるようになりました.

まとめ

やったことはないといえ,本当に小ネタでした.

GitHub Actions のコードをモノレポで管理したいと思った時に呼び出し方を試した

タダです.

プライベートリポジトリで GitHub Actions のコードを複数管理しているような状況で,呼び出す時どうすればいいのかなと思い,検証した時の小ネタをまとめていきます.

検証の概要

コードを管理するリポジトリでは下記のように GitHub Actions のコードがディレクトリ別に配備されていくような構成になっていたとします.この中で actions01 を呼び出したい場合に検証していった内容をまとめます.

.
├── actions01
└── actions02

検証した結果

検証した結果ですが,下記のような定義をしていきました.default セクションで Actions を実行するディレクトリを固定しつつ,uses でも Actions を実行するディレクトリで actions01 を指定すれば actions01 のコードが実行できました.

defaults:
  run:
    shell: bash
    working-directory: ./.github/actions/[repo-name]/actions01

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout
        uses: actions/checkout@v3
        with:
          repository: hoge/[repo-name]
          ref: main
          path: .github/actions/[repo-name]
          token: ${{ secrets.PERSONAL_GITHUB_TOKEN }} 
      - name: hoge actions
        uses: ./.github/actions/[repo-name]/actions01
        with:
          param1: value1
          param2: value2

まとめ

プライベートリポジトリの GitHub Actions で特定のディレクトリのコードを実行させたい場合の動作検証を行ったのでまとめました.

関連記事

sadayoshi-tada.hatenablog.com

sadayoshi-tada.hatenablog.com