sts:Assume Roleは第三者に自分のAWSアカウントのAPI権限を委譲する仕組みです。
ここで言う第三者というのは
のように様々なモノに委譲が可能です。
具体的にこの仕組みがどういったことに使えるかをざっと挙げてみます。
| ポリシー （付与する権限） |
信頼関係 （誰に付与するか） |
どうなるか |
|---|---|---|
| EC2ReadOnly | EC2 | EC2インスタンスから http://169.254.169.254/latest/meta-data にアクセスが可能 |
| PowerUser | IAMユーザ | IAMユーザ自体は権限を持っていなくても、 AssumeRoleでPowerUserの 一時的な権限を取得できる |
| S3ReadOnly | 他AWSアカウント | 他AWSアカウントから自分の S3バケットへアクセス可能 |
で説明したようにHashiCorp Vaultでは柔軟な権限設定ができますが、触っていて「え、こういう挙動・設定なの？」とハマった事がいくつかあったのでまとめます。
例えば
path "secret/foo*" {
capabilities = ["create"]
}
と権限を付与すれば、
のそれぞれでcreate権限が付与されます。
dockerのコンテナは指定したコマンドがPID 1で起動されており、使い方によってはシグナルハンドリングできないことがありますよ、という話です。
それによってプロセスをGracefulに終了できなかったりリソースリークが起きたりするので注意する必要があります。
こちらでとてもわかり易く説明されてます。
Dockerケースを要約すると、親、子、孫の3プロセスが起動している状態で
| ケース | 何が起きる | 問題点 |
|---|---|---|
| 親が死ぬ | 子も孫も強制的に死ぬ | 処理中リクエストを ハンドリングできない |
| 子が死ぬ | 孫は親に紐付けられるが、 親はそれを知らないので孫はゾンビになる |
リソースリーク |
という問題が起きます。
親、子だけのケースであれば前者が起きます。
