ゲストユーザーでAzure DevOpsからAzure環境にデプロイする

本ページにはプロモーションが含まれています。

お仕事

こんばんわ。皆さん、Azure DevOps利用してますか?

今日はAzure DevOpsからAzure環境にデプロイパイプラインを構築しようとしたが、以下のメッセージ

や、AzureサブスクリプションへのAuthorize時に以下のような

PermissionエラーではじかれるAzure Active Directoryゲストユーザー向けの対処方法です。というより、結構な頻度でゲストユーザーな自分の備忘録でもあります。

はじめに

Azure Active Directoryでのユーザータイプ

Azure Active Directory(以下AAD)のテナントにユーザーとして追加されるにはメンバーとゲストの2種類あります。また、Azure DevOpsからパイプラインを構築し、対象のAzureテナントにデプロイを行う場合、デプロイ先にそれなりの権限がないとAzure DevOpsからパイプラインを構築することはできません。

AADのユーザータイプがメンバーとゲストの場合での違いをまず整理してみます。

きったねぇ絵で申し訳ないですが、通常、あるAADテナントにユーザーが追加される場合は、メンバーとして追加されると思います。上の絵の黒いAAD内の「メンバー」ですね。この場合はUPN(アカウント)は「ユーザーID@テナント名.onmicrosoft.com」というアカウントが各ユーザーに割り当てられると思います。カスタムドメインが割り当てられていることがほとんどだと思いますのでその場合は@以降が組織のドメインとなるアカウントでメンバーはサインインを行っていると思います。

一方、黒AADに外部ユーザーとして追加されることもあります。それが、青い「ゲスト」や、緑の「ゲスト」のような感じです。ゲストユーザーは無料のGmailアカウントであろうと、別の組織のAADアカウントであろうと、参加先のAADの管理者に招待されれば参加することができます。

@以降が組織のドメインと同じ=メンバー、@以降が組織のドメインと違う=ゲストって感じだと思います。

信頼できる「メンバー」か、信頼感がそこまでではない「ゲスト」かの違いでAzure内でできることにも違いが出てきます。

Azure DevOpsでのメンバータイプの影響

「Azure DevOpsでの」と言うとちょいと違う気がしますが、メンバータイプが「メンバー」と「ゲスト」でAzure DevOpsを扱う上で何が変わってくるのかというと、「Azure上にデプロイする権限があるか?」ということが大きく影響してきます。

AADにメンバーとして属しているユーザーは、以下のAADのユーザー設定で「アプリの登録」が「はい」となっていれば自由にアプリをリリースすることができます。サービスプリンシパルともいわれますね。Azure DevOps上ではサービスコネクションとかサービス接続と言われるものを利用してサービスプリンシパルと連携します。要は外部との接続をよしなに使えるようにあらかじめ定義しておく機能がサービスコネクションです。少しややこしいですね。

では、「ゲストとして参加しているユーザーは?」というと・・・残念ながらアプリをデプロイする権限はありません。残念無念。。。

上記設定はメンバーユーザーのみに適用でして、ここを強権限者に変えてもらってもゲストユーザーには変化がありません。

ちなみに今まで、ゲストでも有効なのかと勘違いしていましたが、以下のサイトでとても参考になる答えを得ることができました。メンバーのためにも基本はデフォルト値のまま「アプリの登録」はオンがいいそうです。

ゲストユーザーでデプロイパイプラインを構築する

それでは、「ゲストユーザーはAzure上にアプリのデプロイができないのか?」というと、そんなことありません。考えられる方法として、以下が考えられます。

  1. Azure DevOpsからAzureへのパイプライン作成時に資格情報の入力を求められるので、デプロイ先テナントの強権限者に入力してもらい認証を通す。
  2. Azure DevOpsのプロジェクト設定からサービスコネクションをデプロイ先テナントの強権限者に作成してもらう。
  3. ゲストユーザーに対してアプリのデプロイが可能な権限を付与してもらう。

上記の3パターンくらいが考えられるかと思います。

このうち1番は、パイプラインが1個や2個ぐらいなら管理者に「入力してよん♪」とお願いできるかもしれませんが、パイプラインの数が結構あったり、作り直しが発生して嫌な顔されたり、「管理者?だれやねん?」といった状態ですとハードルは高いかと。

また、3番に関してですが、「そもそもゲストユーザーになんかそんな権限与えるわけないだろう!」という管理状態であればできることはありません。

ですので、現実的には2番の方法がベストプラクティスかと思われます。

しかしながら、Azureテナントを複数自社管理している状態ですと、そのテナント単位にメンバーアカウントを作成することになりアカウント管理地獄に陥ることもあります。そんな時、メインで利用している組織アカウントで各テナントにゲストユーザーとしてサインインし、なおかつ、最低限Azure DevOpsからのデプロイ権限があるとお仕事がはかどるっていうシチュエーションも無きにしも非ずかと。(ディレクトリ選択誤りによる誤操作には十分注意する必要があることは言うまでもないかもしれませんが・・・)

ということで、以下の方法で3番のゲストユーザーでAzure DevOpsからAzureテナントにデプロイを行ってみます。

権限のないゲストユーザーでAzure Pipelinesを構築してみる。

まずは試しにゲストユーザーでAzure上へのリリースパイプラインを構築してみます。今回はAzure FunctionsをAzure上にデプロイするシチュエーションです。Azure上にはデプロイ先の関数アプリがすでに作成済みである前提です。

Azure DevOpsのプロジェクトサイトに移動し、Pipelines(ビルドパイプライン)を作成します。デプロイ先のサブスクリプション選択後、以下の認証画面が出てきますので、ゲストユーザーアカウントで認証します。

次にデプロイ先の関数アプリを選択し、「Validate and configure」をクリックします。

見事に冒頭のエラーメッセージ、

Failed to create an app in Azure Active Directory. Error: Insufficient privileges to complete the operation. Ensure that the user has permissions to create an Azure Active Directory Application.

が表示されました。「ユーザーにはAzure Active Directoryアプリの作成権限がないよ」っと怒られました~。

ゲストユーザーにAADアプリ登録権限を設定する。

それではAADにアプリ登録可能な権限をゲストユーザーに設定してみたいと思います。といっても、この操作はAzureテナントの管理者などのお偉方にやっていただき、自分に権限を付与してもらうことがほとんどだと思います。

Azureポータルに遷移し、対象のサブスクリプションから「アクセス制御(IAM)」を選択します。

「追加」-「ロール割り当ての追加」から該当ユーザーに「ユーザーアクセス管理者」権限を付与し保存します。

次に該当ユーザーを開き、「割り当てられたロール」から「割り当ての追加」でディレクトリロールとして「アプリケーション管理者」を追加します。

そんではもう一度、Azure DevOpsのPipelinesから権限追加したユーザーで認証を通し、「Validate and configure」してみませう。

先ほどのエラーは発生せず無事YAMLが表示されました。実行も問題ありません。

まとめ

以上で、ゲストユーザーでもAzure DevOpsからAzure環境にデプロイする権限を得ることができます。

ゲストユーザーでAzure上にアプリの登録(サービスプリンシパルの作成)を行うには、

  • サブスクリプションに対して、「ユーザーアクセス管理者」以上の権限を付与する。
  • ディレクトリロールとして「アプリケーション開発者」を付与する。

の2点で可能です。

ちなみに、Azure DevOpsのRelease Pipeline設定時のAuthorize時やAzure DevOps上のプロジェクトからサービスコネクションを作成するときも同様の権限ですので試してみてください。

ちなみに権限が適切に付与できたかの確認にはAzureポータルからAzure Active Directoryに行き、「アプリの登録」から適当なアプリを新規登録して確認するのが手っ取り早いと思います。

サービスプリンシパルに関しては以下サイトで。

Azure Resource Managerサービスコネクションのトラブルシューティングは以下にて。

以上です。



システムエンジニアランキング


備忘録・雑記ランキング

コメント

タイトルとURLをコピーしました