Heroku
HerokuDay 1

ここらで一度見直すHeroku Orgsの権限設定

More than 1 year has passed since last update.

はじめに

この記事はHeroku Advent Calendar 2016の1日目の記事です。

権限設定、適当にしていませんか

はい

A: 「ウーンうまくいかない、これBさんならわかると思うので、お願いできませんか」
B: 「わたしこれの権限ないので、権限もらえます?」
A: .oO(面倒だしあとから足りないと言われると困るのでとりあえず管理権限でいいよね…)
 → Orgsのadmin権限をBさんに付与
A: 「つけました!」
B: 「ありがとうございます!」

これでBさんは全てのappを消すことができるようになりました!!やりましたね!!!
最小権限の原則に沿って、適切な権限を与えましょう。ちなみにこの会話は実話じゃないです。

権限の種類

Organization

Organization(以下Orgs)は、appをまとめ、共有するシステムです。
Heroku EnterpriseではこのOrgsが使われることになります。

Orgsの権限

公式のドキュメントを参考に説明します。
Using App Permissions in Heroku Organizations

Orgs内部の権限は2種、そして外部メンバーとして1種、計3種です。
AdminMember 、そして Non-orgs User です。

Admin, Member共通

  • Orgsに紐づくappの一覧の確認
  • appの作成

後述するロックされたAppも一覧表示されます。
というか、Orgsのトップ画面はappの一覧なので、そりゃそうですねという感じ。

Admin

  • Orgsの参加者の管理
  • appでの権限割り当て
  • Orgsのapp一覧
  • Orgsのリネーム
  • ロック済みappへのアクセス
  • 全てのappのスケールやアドオン管理・削除などのパフォーマンス操作
  • pipelineの作成

その他にもありますが、詳しいことは公式ドキュメントで確認してください。
(トランスファー周りなどは除いてます)

Member

  • ロックされていないappの基本情報・割り当てユーザの確認
  • 許可されたアプリでの権限操作(後述)
  • OrgsのAdmin / Memberの確認

Non-orgs User

外部ユーザはそれぞれのappでCollaboratorとして割り当てられているユーザで、AdminやMemberでないユーザです。
他のユーザの確認や、割り当てられていないappの確認はできません。

appのロック

本番環境のような簡単に操作されては困るappでは、ロック機能が有用です。
member権限では、明確にそのappに割り当てされ、操作許可を与えられないとアクセスすらすることができません(一覧はできるので、存在は確認できます)。
admin権限はロック済みのアプリでもフルアクセスが可能となっていますので、admin権限を与える基準は 「本番環境を触っていいユーザか」 というのが1つ挙げられるかと思います。

appの権限

こちらも公式のドキュメントを参考に説明します。
同様にはしょるので、ちゃんと確認したい方は原文を読んでくださいね。
Using App Permissions in Heroku Organizations

MemberやCollaboratorはappごとに許可を与えられ、そのappを編集できるようになります。
member権限でOrgsのappにデフォルトで割り当てられる view のほか deploy, operate, そして manage の4種の許可を組み合わせて管理します。

view

  • 基本的なappの情報の確認
  • appのメンバー(Memberではなく、アクセス権のあるユーザ)と与えられている許可の一覧表示
  • Activity, Builds, Releaseの確認
  • Dynoなどの確認

deploy

  • Fetch, PushなどのGitリポジトリへの操作
  • 環境変数の編集
  • 無料のAdd-onsの追加・削除
  • one-off dynoの実行
  • ロールバック作業

名前通り、デプロイを行って確認するための許可といえます。
アドオンは無料のものしか追加できず、スケーリングを行うことはできません。

operate

  • 環境変数の編集
  • 無料/有料のアドオンの追加・削除
  • アドオンの設定(Papertrailの画面などを見る必要があれば、この許可が必要)
  • ロールバック作業
  • appの再起動
  • スケーリング

プロダクトの運用を行う担当者などが想定されるでしょうか。
コードは触らないが、ログ分析やリソース管理、ロールバックを担当するような場合、operateがいいのではないでしょうか。

manage

  • appへユーザを追加
  • appのユーザの権限(許可)管理
  • appの削除・リネーム
  • カスタムドメインの設定

他のユーザを管理します。appの可用性などには特に関係しません。
この許可をCollaboratorに与えることもできますので、Orgsのメンバーでなくともこのappに限定してユーザ管理を行えるようになります。
また、OrgsのAdminに加えてこの許可のユーザがロックされたappのユーザ管理が可能です。

ユースケース

雑に例えていきましょう。

1. 本番環境は社内でも制限したい!

社内でも制限したい、という場合はまずadmin権限を見直します。
プロダクト・プロジェクトの責任者のみをAdminに割り当てておきましょう。
Adminがアプリをロックして、社内のメンバーをそのアプリに割り当てていきます。

運用を担当していて、本番環境のログを見たり、画像のCDNサービスへアクセスする必要があるメンバーにはoperateのみでよいでしょう。
特に運用に関わっていないが、一応把握のために…というようなメンバーはviewのみにしておけばリリースされたタイミングくらいは把握できます。
責任者がいちいちメンバーの管理を行っていられない!オレは忙しいんだ!といった場合、manageのみを割り当てたユーザがいれば大丈夫ですね。

2. 外部のフリーランスの方に少し手伝ってもらうんだけど。

ステージングのappのみにCollaboratorとして割り当て、view/deploy/operateの許可を与えておけばよさそうです。
コードを編集してデプロイしたり、アドオンを設定してもらいましょう。
もし有料のアドオンなどの心配があれば、deployだけでもいいかもしれません。
というか、その場合はGitHubと連携しておいて、そのリポジトリにOutside Collaboratorとして招待してwrite権限を与えておいて、herokuにはviewだけの方が安全かもしれませんね。その場合はロールバック作業はできなくなります。

GitHubと連携させた場合、リポジトリのadmin/writeは別途しっかり管理しておく必要があります。
Herokuではdeploy権限外していてもリポジトリのmasterにpushできてしまっては意味がありませんので。

3. Adminばっかじゃダメなのはわかるけどメンバーへの許可管理めんどくさいよ〜

丸投げしましょう。
他の人にmanageだけ与えて許可管理はその人にやらせればいいのです。
丸投げすることで他人に負荷を押し付けられることで知られています。みなさんは、押し付けられていますか?

最後に

まぁ組織内に悪意のある人でも紛れ込んでなきゃそんなに厳密にやる必要はないかもしれません。
ただ、自分がぼーっとしててGitのリモートの設定を間違えて別リポジトリにpushしたことがあると、deploy周りはしっかり整備した方がいいかもしれん…と思うようになりましたのでちょっと書きました。
pipeline周りの権限が若干怪しいので、そのあたりは別途調べてみようとおもいます。

進捗ですか?

めしにしましょう - ニャオス。
1巻発売おめでとうございます。
では、やっていきましょう。