Carpe Diem

備忘録

ConsulでService登録をした時のACLでハマった話

概要

Consulではserviceを登録することでService Discovery機能を活用することができます。
例えば

  "service": {
    "name": "payment",
    "port": 9090,
    "tags": ["development"]
  }

のように設定をすると、

$ dig @localhost -p 8600 payment.service.consul

paymentサービスとして登録したノードのIP群を取得できます。
詳細を知りたい方は以下を参考にしてください。

christina04.hatenablog.com

今回はこのサービス登録でACLを設定しているとうまく行かずハマってしまった話です。

続きを読む

Assume Roleの用途・メリット

概要

sts:Assume Roleは三者に自分のAWSアカウントのAPI権限を委譲する仕組みです。
ここで言う第三者というのは

のように様々なモノに委譲が可能です。

sts:Assume Role

どういう用途として使える?

具体的にこの仕組みがどういったことに使えるかをざっと挙げてみます。

ポリシー
(付与する権限)
信頼関係
(誰に付与するか)
どうなるか
EC2ReadOnly EC2 EC2インスタンスから
http://169.254.169.254/latest/meta-data
にアクセスが可能
PowerUser IAMユーザ IAMユーザ自体は権限を持っていなくても、
AssumeRoleでPowerUserの
一時的な権限を取得できる
S3ReadOnly AWSアカウント AWSアカウントから自分の
S3バケットへアクセス可能
続きを読む

ConsulのACLを後から有効化する

概要

christina04.hatenablog.com

ではConsulのACLの基本的な設定方法を説明しました。その時は

"default_policy": "deny"のようにデフォルトで全リソースのアクセス禁止にしてwhitelist形式で扱っていきます。

と言いましたが、そもそもACL未設定なConsulを稼働中で、急にdefault denyにしたらサービスに影響が出てしまうというケースももちろんあります。
今回はACLを後から有効化(ACLマイグレーション?)する方法を説明します。

環境

  • Consul 1.4.0

ハンズオン

こちらのリポジトリで検証できます。

github.com

続きを読む

CloudWatch LogsのログをS3へ【Kinesis Firehose編】

概要

前回

christina04.hatenablog.com

にてCloudWatch Logsの過去ログをS3へエクスポートする方法を説明しました。
今回はリアルタイムにS3に転送する方法を紹介します。

手順

管理ポリシーではないIAMポリシーが何度も出てくるので、自動生成してくれるWebコンソールで作成します。

前提

はすでにあるとして進めます。

続きを読む

VaultのPolicyでハマったこと

概要

christina04.hatenablog.com

で説明したようにVaultでは柔軟な権限設定ができますが、触っていて「え、こういう挙動・設定なの?」とハマった事がいくつかあったのでまとめます。

環境

  • vault v0.11.5

ハマったところ

pathは前方一致

例えば

path "secret/foo*" {
  capabilities = ["create"]
}

と権限を付与すれば、

  • secret/foo
  • secret/foobar
  • secret/foo/bar

のそれぞれでcreate権限が付与されます。

Policies - Vault by HashiCorp

続きを読む

CloudWatch LogsのログをS3へ【エクスポート編】

概要

CloudWatch LogsはAWSでは一番簡単に用意できる検索可能なログ基盤だと思います。
一方で

  • 詳細な検索がしにくい(クエリやUI的に)
  • ログが大量に増えると料金も嵩んでくる
  • Terraformや操作ミス(保持期間の誤設定など)で間違って消してしまうリスク

といった問題もあるので、そういった場合の対策としてS3やLambdaに渡してデータを保存・変換させたりする手法が一般的です。

CloudWatch Logsではロググループを指定して簡単にS3へエクスポートできる機能も提供されているので、それを実行してみます。

続きを読む

Dockerの--initフラグについて

概要

dockerのコンテナは指定したコマンドがPID 1で起動されており、使い方によってはシグナルハンドリングできないことがありますよ、という話です。
それによってプロセスをGracefulに終了できなかったりリソースリークが起きたりするので注意する必要があります。

環境

  • docker v18.09.0

どんな問題が起きる?

こちらでとてもわかり易く説明されてます。

Unix プロセスと Docker の罠 - けちゃぶろぐ

Dockerケースを要約すると、親、子、孫の3プロセスが起動している状態

ケース 何が起きる 問題点
親が死ぬ 子も孫も強制的に死ぬ 処理中リクエストを
ハンドリングできない
子が死ぬ 孫は親に紐付けられるが、
親はそれを知らないので孫はゾンビになる
リソースリーク

という問題が起きます。
親、子だけのケースであれば前者が起きます。

続きを読む