Terraformを使用してAzureでインフラストラクチャを管理しているときに、ServicePrincipleユーザーをどのように使用する必要があるかについて少し混乱しています。
たとえば、チーム全体で共有できる単一のSPを用意することをお勧めしますか？または、ユーザーごとにSPを設定する必要がありますか？
ユーザーごとのSPの場合、1人のSPユーザーでプロビジョニングされたキーボールトなどの一部のリソースで問題が発生するため、そのユーザーに対してアクセスポリシーが定義されていますが、別のSPを持つチーム内の別の人はラップトップからそのボールトを変更するためのアクセス。
私の質問が十分に明確であるかどうかはわかりませんが、これらのシナリオに関する具体的な詳細を見つけることができません。
とても感謝しています
サービスプリンシパルは、操作を実行するサービス（人間以外）がある場合に使用する必要があります。たとえば、このシナリオでは、Terraformはサービスプリンシパルを使用して、CI / CDパイプラインの一部としてインフラストラクチャをプロビジョニングします。
サービスプリンシパル（任意の環境）は、通常、最小特権で構成されます。これは、サービスプリンシパルが、環境をプロビジョニングするためにTerraformを呼び出すなど、単一の非常に特定の目的で使用されることを目的としているためです。そのため、サービスプリンシパルには、特定のリソースグループ（またはリソースグループのセット）のリソースをプロビジョニングするために使用される、Azure KeyVaultから特定のシークレットのセットを読み取るアクセス許可がある場合があります。それでおしまい。
これを、作業に使用するものなどのユーザーアカウントと比較してください。複数のAzureサブスクリプションにアクセスしたり、必要な場所にリソースをプロビジョニングしたり、リソースを削除したり、リソースへのアクセスを構成したりできます。
サービスプリンシパルを使用する主な理由は、セキュリティにあります。上記の例を使用すると、サービスプリンシパルの資格情報（クライアントIDとシークレット）が侵害された場合、それらの資格情報で実行できるのは、キーボールトからシークレットを読み取り、特定のリソースグループのリソースをプロビジョニングすることだけです。
ここのドキュメントは、サブスクリプション全体にサービスプリンシパルコントリビューターのアクセス許可を与えることを示しています。これは、上記の例よりも制限が少なくなっています。ただし、別のベストプラクティスを想定していると思います。つまり、開発/テスト環境では、本番環境や他の環境とは異なるAzureサブスクリプションを使用する必要があります。そのため、サービスプリンシパルは、開発/テスト専用のサブスクリプションに対する完全なコントリビューター権限を持っていますが、組織が持っている他のサブスクリプションにアクセスすることも、サブスクリプション内のリソースへのアクセスを構成するために使用することもできません。
この記事はインターネットから収集されたものであり、転載の際にはソースを示してください。
侵害の場合は、連絡してください[email protected]
コメントを追加