credential の扱い方について考える

[suzuki-shunsuke]

理想

• 属人化の排除
  • インフラ管理者的な強い権限を持つ人に依頼しないと設定とかできないみたいなのをなくしたい
• 操作記録を残す
  • 監査的に求められたりもする
  • いつ、誰が、なぜ変更したのか分かるようにする、レビューできるようにする
• 誰も知らない
  • インフラ管理者的な強い権限を持つ人も分からない
  • パスワードをなにかに登録する場合(ex. AWS Secrets Manager)、パスワードの発行と登録を API で発行できるなら一連の処理を自動化することで誰も知らないようにすることは可能
  • とはいえ、なにかの際に DB につないで確認とかしたいことない？
• コンテナに侵入されても分からない
  • ファイルに書き出さない(暗号化していればあり？)
  • 環境変数にも設定しない(暗号化していればあり？)
  • コードが変更できない状態でアプリケーションの初期化処理で読み込めばわからないのでは
  • アプリケーションの初期化処理で読み込むための認証・認可は結局ファイルなり環境変数なりなのでは

管理方法

• 一箇所で管理
• サービスとそのサービスが参照できるクレデンシャルの一覧(あるいはクレデンシャルを参照できるサービスの一覧) をコード管理
• サービス毎に参照するためのクレデンシャルを発行
  • そしたら今度はそのクレデンシャルをどう管理するのみたいな堂々巡りになりそうな

[suzuki-shunsuke]

直近の問題

• Argo Workflows でどうやって credential を渡すか(k8s の secret で渡せるというのは知っている)

[suzuki-shunsuke]

リポジトリ

• Credential とそれを参照できるサービスの一覧をリポジトリで管理する
• Credential の値自体は管理しない

Credential の登録

• Credential を登録するコマンドを用意する
  • 誰でも実行できるようにする
  • 参照できるサービスとの紐付けは行わず、デフォルトではどのサービスも参照できないようにする
  • description (なぜ登録したか、用途)を必須とする
  • 登録するとリポジトリに PR が作られる
  • 登録自体は自由で問題があれば消したりする

Credential の更新

• Credential をバージョンニングし、最新のものにエイリアスを貼る
• 更新時には新しいバージョンのを登録し、エイリアスを張り替える PR を作成する

Secret id

• とりあえず unapproved/<secret-id>/<version> で作られる
• approve されたら unapproved/<secret-id>/<version> が消され <secret-id>/<version> が生成される

イメージ

credentials:
- id: foo-database-password-production
  version: 5
  services:
  - foo