インフラチームがお届けするブログリレーです！既に公開されている記事もありますので、こちらから他のメンバーの投稿もぜひチェックしてみてください！

これは何

小西がこの記事を書くときにつまづいたポイントをまとめていく記事です

ちなみに、トラシューしてた時の私は半分諦めかけでした

なぜなら、JITNAは比較的新しいサービスなので、あまり知見がないのです（トラシューは言うまでもなく…）
前口上は置いておいて、こんな感じで私が七転八倒してた記録です

なにがあったの

概要を言うと、「JITNAのアクセスリクエストが勝手に却下されてしまう」という事象です

※そもそもJITNAってなんだよ、どうやって設定するんだよ、という方はぜひ私が書いた記事（【AWS】AWS Systems Managerのジャストインタイムノードアクセスの使い方か公式ドキュメントを読んでください

JITNAを利用する流れの中で、「アクセスリクエストをリクエスト承認者側から送る」段階において、リクエストを作成する部分までは問題なく動くのですが、すぐに承認ステータスが「却下済み」となってしまいました

また、承認者側からリクエストを確認しても同様のメッセージが表示され、リクエストが拒否されてしまいました
さらに、拒否されたリクエストを手動で承認することもできませんでした

アクセス送信者側の画面

承認者側の画面

 

状況整理をする

とりあえず、現状整理をして問題の切り分けをしてみました

承認ポリシーの確認

メッセージに「Cedar Policy によって自動的に拒否されました」と書いてある以上、Cedar Policyなるものが悪さをしていそうです
CedarはAWSが公開している、アプリケーションに適用される権限をわかりやすいポリシーとして表現できるオープンソース言語なので、Cedar Policyはその言語で書かれたポリシーということです

………そんなものは設定していません

私は「手動承認ポリシー」は設定していましたが、今回のアクセスリクエストはそのポリシーに合致するものでしたし、自動でアクセスを拒否するようなポリシーも設定していないことは確認していました

また、拒否ポリシーに関しては公式ドキュメントに以下の記載がありました
これを読む限りでは、自動承認ポリシーなしで手動承認ポリシーのみを設定している場合に拒否ポリシーが勝手に発動する、ということはなさそうに見えます

アクセス拒否ポリシーは、AWS 組織内のすべてのアカウントに適用されます。例えば、Production キーでタグ付けされたノードへの Intern グループの自動承認を明示的に拒否することができます。自動承認と手動承認のポリシーは、作成されたAWSアカウントとAWSリージョンにのみ適用されます。組織内の各メンバーアカウントは、独自の承認ポリシーを管理します。承認ポリシーは、次の順序で評価されます：
1.アクセス拒否
2.自動承認
3.手動

アクセス拒否ポリシーは組織ごとに1つだけ、自動承認ポリシーはアカウントとリージョンごとに1つだけ持つことができますが、アカウントには複数の手動承認ポリシーがあるでしょう。手動承認ポリシーを評価する場合、ジャストインタイムノードアクセスは常にノードのより具体的なポリシーを優先します。

ノードの承認ポリシーを作成する

加えて、今回はAWSアカウントと AWSリージョンで初めてJITNAを有効化して使用していたため、すでに既存の拒否ポリシーが作成されている、ということもなさそうです

ちなみにダメ押しで、今回使用した環境が紐づいているOrgに適用されているSCPも確認しましたが、SSM関連の拒否ポリシーは設定されていませんでした

つまり、承認ポリシーの設定には問題がなく、Cedar Policyも設定されていないということです

これで、（見る限りは）承認ポリシーには問題ないことが確認できました

IAM権限の確認

承認ポリシー＝JITNA自体の設定に問題がないということは、アクセスリクエストを送信しているユーザーか、承認者ユーザーの権限に問題がある可能性があります
この段階では、以下の設定を行なっていました

  • アクセスリクエスト送信者のユーザーを作成する。コンソールアクセスを可能にする
  • 上記ユーザーには、公式ドキュメント の「ジャストインタイムノードアクセスユーザー向けのIAMポリシー」を付与する
  • 承認者用のロールを作成する
  • 上記ロールには、同じく公式ドキュメント の「アクセスリクエスト承認者向けのIAMポリシー」を付与する

そして、以下のような方法で検証を行っていました

  1. admin権限を持つロールでログインを行い、JITNAの有効化およびポリシー設定を行う
  2. アクセスリクエスト送信者のユーザーでコンソールにログインし、JITNAのアクセスリクエストを送信する
  3. admin権限を持つロールを承認者用のロールに切り替え、承認を行う

※リクエスト送信はユーザーで、承認はロールで行っている理由は、承認ポリシーの設定で承認者の指定はロールを指定して行っていたため、「承認は専用のロールを引き受けてやらないとダメなのか」と思っていたからです

結論から言えば、この方法が良くなかったのです

が、当時はそれが分からず、てっきり権限が足りないのかと思い、試しにアクセスリクエスト送信者のユーザー、承認者用のロールのどちらにもadmin権限をつけてみました

ダメでした

結論

今回のトラブルの解決策は、結論から言うと、「アクセスリクエストも承認も、ロールでやりましょう」ということになります
つまり、先述した

  1. admin権限を持つロールでログインを行い、JITNAの有効化およびポリシー設定を行う
  2. アクセスリクエスト送信者のユーザーでコンソールにログインし、JITNAのアクセスリクエストを送信する
  3. admin権限を持つロールを承認者用のロールに切り替え、承認を行う

この方法ではなく、
アクセスリクエスト用と承認者用のロールを作成した（権限は変更不要）上で、

  1. JITNAの有効化およびポリシー設定を行う
  2. アクセスリクエスト送信者用のロールに切り替え、JITNAのアクセスリクエストを送信する
  3. 承認者用のロールに切り替え、承認を行う

という方法を取る必要があったんですね
実際にやってみたところ以下のように、先ほどと挙動が違います

アクセスリクエスト側の画面（承認ステータスが「保留中の承認」になっている）

承認者側の画面（承認ボタンが押せるようになっている）

そして、「承認」ボタンを押すと、承認ステータスが「承認済み」になり、セッションを始められるようになりました！

解決してみれば単純な話ですが、かなり沼ってしまい、2~3日苦しんでいました

ちなみに、この解決策はふと「承認者もロールで指定するなら、リクエスト送信側もロールでやらなきゃダメじゃないか…？？」と思いつきました
完全にたまたまです

まとめ

JITNAを利用する際は、リクエストを送信するのも、承認するのもロールで行いましょう
特に、この機能は外部ユーザーに使用してもらう場面が多いことが想定され、外部ユーザー用に作成したIAMユーザーに権限を付与してしまう、などの可能性もあるので、この点を意識して使用しましょう

以上です