AWS CodeCommit は、新しいお客様では使用できなくなりました。 AWS CodeCommit の既存のお客様は、通常どおりサービスを引き続き使用できます。詳細はこちら

翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

の ID とアクセスの管理 AWS CodeCommit

AWS Identity and Access Management （IAM) は、管理者が AWS リソースへのアクセスを安全に制御 AWS のサービス するのに役立つ です。IAM 管理者は、 CodeCommit リソースの使用を認証 (サインイン) および認可 (アクセス許可を持つ) できるユーザーを制御します。IAM は追加料金なしで AWS のサービス 使用できる です。

対象者

AWS Identity and Access Management （IAM) の使用方法は、 CodeCommit で行う作業によって異なります。

サービスユーザー – CodeCommit サービスを使用してジョブを実行する場合、管理者は必要な認証情報とアクセス許可を提供します。より多くの CodeCommit 機能を使用して作業を行うと、追加のアクセス許可が必要になる場合があります。アクセスの管理方法を理解しておくと、管理者に適切な許可をリクエストするうえで役立ちます。 CodeCommit の機能にアクセスできない場合は、「」を参照してくださいAWS CodeCommit ID とアクセスのトラブルシューティング。

サービス管理者 – 社内の CodeCommit リソースを担当している場合は、おそらく CodeCommit へのフルアクセスが可能です。サービスユーザーがどの CodeCommit 機能やリソースにアクセスすべきかを判断するのは、お客様の仕事です。その後、サービスユーザーのアクセス許可を変更するには、IAM 管理者にリクエストを送信する必要があります。このページの情報を確認して、IAM の基本概念を理解します。Word で IAM を使用する方法については CodeCommit、「」を参照してくださいIAM での AWS CodeCommit 仕組み。

IAM 管理者 – IAM 管理者の場合は、 CodeCommit へのアクセスを管理するためのポリシーを記述する方法の詳細を知りたい場合があります。 CodeCommit で使用できる IAM アイデンティティベースのポリシーの例を表示するには、「」を参照してくださいAWS CodeCommit ID ベースのポリシーの例。

アイデンティティを使用した認証

認証は、アイデンティティ認証情報 AWS を使用して にサインインする方法です。として、IAM ユーザーとして AWS アカウントのルートユーザー、または IAM ロールを引き受けて認証 ( にサインイン AWS) される必要があります。

ID ソースを通じて提供された認証情報を使用して、フェデレーティッド ID AWS として にサインインできます。 AWS IAM Identity Center （IAM Identity Center) ユーザー、会社のシングルサインオン認証、Google または Facebook の認証情報は、フェデレーティッド ID の例です。フェデレーティッド ID としてサインインすると、管理者は IAM ロールを使用してアイデンティティフェデレーションを以前にセットアップしました。フェデレーション AWS を使用して にアクセスすると、間接的にロールを引き受けます。

ユーザーのタイプに応じて、 AWS Management Console または AWS アクセスポータルにサインインできます。へのサインインの詳細については AWS、 AWS サインイン ユーザーガイドの「 へのサインイン方法 AWS アカウント」を参照してください。

AWS プログラムで にアクセスする場合、 はソフトウェア開発キット (SDK) とコマンドラインインターフェイス (CLI) AWS を提供し、認証情報を使用してリクエストに暗号化で署名します。 AWS ツールを使用しない場合は、自分でリクエストに署名する必要があります。推奨される方法を使用してリクエストに署名する方法の詳細については、Word IAM ユーザーガイドのAWS API リクエストの署名バージョン 4」を参照してください。

使用する認証方法を問わず、追加セキュリティ情報の提供をリクエストされる場合もあります。例えば、 では、アカウントのセキュリティを高めるために多要素認証 (MFA) を使用する AWS ことをお勧めします。詳細については、AWS IAM Identity Center 「 ユーザーガイド」の「多要素認証」とAWS 「 IAM ユーザーガイド」の「多要素認証」を参照してください。 IAM

AWS アカウント ルートユーザー

を作成するときは AWS アカウント、アカウント内のすべての および リソースへの AWS のサービス 完全なアクセス権を持つ 1 つのサインイン ID から始めます。この ID は AWS アカウント theroot ユーザーと呼ばれ、アカウントの作成に使用した E メールアドレスとパスワードでサインインしてアクセスします。日常的なタスクには、ルートユーザーを使用しないことを強くお勧めします。ルートユーザーの認証情報は保護し、ルートユーザーでしか実行できないタスクを実行するときに使用します。ルートユーザーとしてサインインする必要があるタスクの完全なリストについては、IAM ユーザーガイドの「ルートユーザーの認証情報を必要とするタスク」を参照してください。

IAM ユーザーとグループ

IAM ユーザーとは、1 人のユーザーまたはアプリケーションに対して特定のアクセス許可 AWS アカウント を持つ 内の ID です。可能であれば、パスワードやアクセスキーなどの長期的な認証情報を持つ IAM ユーザーを作成する代わりに、一時的な認証情報に依存することをお勧めします。ただし、IAM ユーザーとの長期的な認証情報を必要とする特定のユースケースがある場合は、アクセスキーをローテーションすることをお勧めします。詳細については、IAM ユーザーガイドの「長期的な認証情報を必要とするユースケースのアクセスキーを定期的にローテーションする」を参照してください。

IAM グループは、IAM ユーザーのコレクションを指定する ID です。グループとしてサインインすることはできません。グループを使用して、複数のユーザーに対して一度に権限を指定できます。多数のユーザーグループがある場合、グループを使用することで権限の管理が容易になります。例えば、IAMAdmins という名前のグループがあり、そのグループに IAM リソースを管理するアクセス許可を付与できます。

ユーザーは、ロールとは異なります。ユーザーは 1 人の人または 1 つのアプリケーションに一意に関連付けられますが、ロールはそれを必要とする任意の人が引き受けるようになっています。ユーザーには永続的な長期の認証情報がありますが、ロールでは一時認証情報が提供されます。詳細については、IAM ユーザーガイドの「Word ユーザーのユースケース」を参照してください。 IAM

IAM ロール

IAM ロールは、特定のアクセス許可 AWS アカウント を持つ 内の ID です。これは IAM ユーザーと似ていますが、特定のユーザーに関連付けられていません。で IAM ロールを一時的に引き受けるには AWS Management Console、ユーザーから IAM ロール (コンソール) に切り替えることができます。or AWS API オペレーションを AWS CLI 呼び出すか、カスタム URL を使用してロールを引き受けることができます。ロールの使用方法の詳細については、IAM ユーザーガイドの「ロールを引き受ける方法」を参照してください。

一時的な認証情報を持つ IAM ロールは、以下の状況で役立ちます。

ポリシーを使用したアクセスの管理

でアクセスを制御するには、ポリシー AWS を作成して ID AWS またはリソースにアタッチします。ポリシーは AWS 、アイデンティティまたはリソースに関連付けられているときにアクセス許可を定義するオブジェクトです。 は、プリンシパル (ユーザー、ルートユーザー、またはロールセッション) がリクエストを行うときに、これらのポリシー AWS を評価します。ポリシーでの権限により、リクエストが許可されるか拒否されるかが決まります。ほとんどのポリシーは JSON ドキュメント AWS として に保存されます。JSON ポリシードキュメントの構造と内容の詳細については、JSON ユーザーガイドの「Word ポリシーの概要」を参照してください。 IAM

管理者は、 AWS JSON ポリシーを使用して、誰が何にアクセスできるかを指定できます。つまり、どのプリンシパルがどのリソースに対してどのような条件下でアクションを実行できるかということです。

デフォルトでは、ユーザーやロールに権限はありません。必要なリソースに対してアクションを実行するアクセス許可をユーザーに付与するには、IAM 管理者は IAM ポリシーを作成できます。その後、管理者は IAM ポリシーをロールに追加し、ユーザーはロールを引き受けることができます。

IAM ポリシーは、 オペレーションの実行に使用する方法に関係なく、アクションのアクセス許可を定義します。例えば、iam:GetRole アクションを許可するポリシーがあるとします。そのポリシーを持つユーザーは AWS Management Console、、 AWS CLI、または AWS API からロール情報を取得できます。

アイデンティティベースポリシー

ID ベースのポリシーは、JSON ユーザー、ユーザーのグループ、ロールなどの ID にアタッチできる IAM アクセス許可ポリシードキュメントです。これらのポリシーは、ユーザーとロールが実行できるアクション、リソース、および条件をコントロールします。ID ベースのポリシーを作成する方法については、IAM ユーザーガイド」の「カスタマーマネージドポリシーを使用したカスタム Word アクセス許可の定義」を参照してください。 IAM

アイデンティティベースのポリシーは、さらにインラインポリシーまたはマネージドポリシーに分類できます。インラインポリシーは、単一のユーザー、グループ、またはロールに直接埋め込まれています。マネージドポリシーは、 内の複数のユーザー、グループ、ロールにアタッチできるスタンドアロンポリシーです AWS アカウント。マネージドポリシーには、 AWS マネージドポリシーとカスタマーマネージドポリシーが含まれます。マネージドポリシーまたはインラインポリシーを選択する方法については、IAM ユーザーガイドの「マネージドポリシーとインラインポリシーの選択」を参照してください。

リソースベースのポリシー

リソースベースのポリシーは、リソースにアタッチする JSON ポリシードキュメントです。リソースベースのポリシーの例としては、IAM ロールの信頼ポリシーと Amazon S3 バケットポリシーがあります。リソースベースのポリシーをサポートするサービスでは、サービス管理者はポリシーを使用して特定のリソースへのアクセスをコントロールできます。ポリシーがアタッチされているリソースの場合、指定されたプリンシパルがそのリソースに対して実行できるアクションと条件は、ポリシーによって定義されます。リソースベースのポリシーでは、プリンシパルを指定する必要があります。プリンシパルには、アカウント、ユーザー、ロール、フェデレーティッドユーザー、または を含めることができます AWS のサービス。

リソースベースのポリシーは、そのサービス内にあるインラインポリシーです。リソースベースのポリシーでは、IAM の AWS マネージドポリシーを使用できません。

アクセスコントロールリスト (ACLs）

アクセスコントロールリスト (ACLs) は、どのプリンシパル (アカウントメンバー、ユーザー、またはロール) がリソースにアクセスするアクセス許可を持っているかを制御します。ACLs はリソースベースのポリシーに似ていますが、JSON ポリシードキュメント形式を使用していません。

Amazon S3、および Amazon VPC は AWS WAF、ACLs をサポートするサービスの例です。ACLs の詳細については、Amazon Simple Storage Service デベロッパーガイドの「アクセスコントロールリスト (ACL) 概要」を参照してください。

その他のポリシータイプ

AWS は、追加であまり一般的ではないポリシータイプをサポートしています。これらのポリシータイプでは、より一般的なポリシータイプで付与された最大の権限を設定できます。

複数のポリシータイプ

1 つのリクエストに複数のタイプのポリシーが適用されると、結果として作成される権限を理解するのがさらに難しくなります。複数のポリシータイプが関与する場合にリクエストを許可するかどうか AWS を決定する方法については、IAM ユーザーガイドの「ポリシー評価ロジック」を参照してください。

CodeCommit リソースベースのポリシー

CodeCommit はリソースベースのポリシーをサポートしていません。

CodeCommit タグに基づく認可

タグを CodeCommit リソースにアタッチしたり、リクエストのタグを CodeCommit に渡すことができます。タグに基づいてアクセスを管理するには、codecommit:ResourceTag/key-name、aws:RequestTag/key-name、または aws:TagKeys の条件キーを使用して、ポリシーの 条件要素でタグ情報を提供します。Tagging CodeCommit リソースの詳細については、「」を参照してください例 5: タグを使用してリポジトリに対するアクションを許可または拒否する。タグ付け戦略の詳細については、AWS 「リソースのタグ付け」を参照してください。

CodeCommit は、セッションタグに基づくポリシーもサポートしています。詳細については、「セッションタグ」を参照してください。

タグを使用して CodeCommit で ID 情報を提供する

CodeCommit はセッションタグの使用をサポートしています。これは、IAM ロールを引き受けたり、一時的な認証情報を使用したり、 AWS Security Token Service () でユーザーをフェデレーションしたりするときに渡すキーと値のペア属性ですAWS STS。タグを IAM ユーザーに関連付けることもできます。これらのタグで提供される情報を使用して、変更を行ったユーザーやイベントを引き起こしたユーザーを簡単に特定できます。 CodeCommit には、 CodeCommit イベントで次のキー名を持つタグの値が含まれます。

この情報が提供されると、 CodeCommit は AmazonWord および Amazon EventBridge CloudWatch Events に送信されるイベントにこの情報を含めます。詳細については、「Amazon EventBridge および Amazon CloudWatch Events の CodeCommit イベントのモニタリング」を参照してください。

セッションタグを使用するには、ロールに、sts:TagSession アクセス許可を Allow に設定したポリシーが含まれている必要があります。フェデレーティッドアクセスを使用している場合は、設定の一部として表示名と E メールタグ情報を構成できます。たとえば、Azure Active Directory を使用している場合は、次のクレーム情報を提供できます。

を使用して AWS CLI 、 displayNameと emailAddressのセッションタグを渡すことができますAssumeRole。例えば、 という名前のロールを引き受けるユーザー Developer 自分の名前を関連付けるユーザー Mary Major では、次のような assume-role コマンドを使用できます。

aws sts assume-role \
--role-arn arn:aws:iam::123456789012:role/Developer \
--role-session-name Mary-Major \
–-tags Key=displayName,Value="Mary Major" Key=emailAddress,Value="mary_major@example.com" \
--external-id Example987

詳細については、AssumeRole」を参照してください。

AssumeRoleWithSAML オペレーションを使用して、displayName タグと emailAddress タグを含む一時的な認証情報のセットを返すことができます。これらのタグは、 CodeCommit リポジトリにアクセスするときに使用できます。そのためには、会社またはグループがすでにサードパーティーの SAML ソリューションを と統合している必要があります AWS。その場合は、セッションタグとして SAML 属性を渡すことができます。例えば、 という名前のユーザーの表示名と E メールアドレスに ID 属性を渡す場合 Saanvi Sarkar セッションタグとして：

<Attribute Name="https://aws.amazon.com/SAML/Attributes/PrincipalTag:displayName">
  <AttributeValue>Saanvi Sarkar</AttributeValue>
</Attribute>
<Attribute Name="https://aws.amazon.com/SAML/Attributes/PrincipalTag:emailAddress">
  <AttributeValue>saanvi_sarkar@example.com</AttributeValue>
</Attribute>

詳細については、SAML AssumeRoleWith を使用したセッションタグの渡す」を参照してください。

AssumeRoleWithIdentity オペレーションを使用して、displayName タグと emailAddress タグを含む一時的な認証情報のセットを返すことができます。これらのタグは、 CodeCommit リポジトリにアクセスするときに使用できます。OpenID Connect (OIDC) からセッションタグを渡すには、セッションタグを JSON Web Token (JWT) に含める必要があります。例えば、 という名前のユーザーの displayNameとemailAddressセッションタグAssumeRoleWithWebIdentityを含む、 の呼び出しに使用されるデコードされた JWP トークンです。Li Juan:

{
    "sub": "lijuan",
    "aud": "ac_oic_client",
    "jti": "ZYUCeREXAMPLE",
    "iss": "https://xyz.com",
    "iat": 1566583294,
    "exp": 1566583354,
    "auth_time": 1566583292,
    "https://aws.amazon.com/tags": {
        "principal_tags": {
            "displayName": ["Li Juan"],
            "emailAddress": ["li_juan@example.com"],
        },
        "transitive_tag_keys": [
            "displayName",
            "emailAddress"
        ]
    }
}

詳細については、 AssumeRoleWithWebIdentity を使用したセッションタグの渡す」を参照してください。

GetFederationToken オペレーションを使用して、displayName タグと emailAddress タグを含む一時的な認証情報のセットを返すことができます。これらのタグは、 CodeCommit リポジトリにアクセスするときに使用できます。例えば、 を使用して、 displayNameと emailAddress タグを含むフェデレーショントークン AWS CLI を取得するには：

aws sts get-federation-token \
--name my-federated-user \
–-tags key=displayName,value="Nikhil Jayashankar" key=emailAddress,value=nikhil_jayashankar@example.com

詳細については、 GetFederationToken を使用したセッションタグの渡す」を参照してください。

IAM CodeCommit ロール

IAM ロールは、Amazon Web Services アカウント内の特定のアクセス許可を持つエンティティです。

CodeCommit での一時的な認証情報の使用

一時的な認証情報を使用して、フェデレーションでサインインしたり、IAM ロールを引き受けたり、クロスアカウントロールを引き受けたりすることができます。Word や AWS STS API などの GetFederationToken オペレーションを呼び出して、一時的なセキュリティ認証情報を取得します。 AssumeRole

CodeCommit は一時的な認証情報の使用をサポートしています。詳細については、「認証情報をローテーションして AWS CodeCommit リポジトリに接続する」を参照してください。

サービスにリンクされたロール

サービスにリンクされたロールを使用すると、 AWS サービスが他のサービスのリソースにアクセスして、ユーザーに代わってアクションを実行できます。サービスにリンクされたロールは IAM アカウントに表示され、サービスによって所有されます。IAM 管理者は、サービスにリンクされたロールのアクセス許可を表示できますが、編集することはできません。

CodeCommit はサービスにリンクされたロールを使用しません。

サービスロール

この機能により、ユーザーに代わってサービスがサービスロールを引き受けることが許可されます。このロールにより、サービスがお客様に代わって他のサービスのリソースにアクセスし、アクションを完了することが許可されます。サービスロールは IAM アカウントに表示され、アカウントによって所有されます。つまり、IAM 管理者はこのロールのアクセス許可を変更できます。ただし、それにより、サービスの機能が損なわれる場合があります。

CodeCommit はサービスロールを使用しません。

AWS CodeCommit ID ベースのポリシーの例

デフォルトでは、IAM ユーザーとロールには CodeCommit リソースを作成または変更するアクセス許可がありません。また、 AWS Management Console、 AWS CLI、または AWS API を使用してタスクを実行することはできません。IAM 管理者は、必要な特定のリソースに対して特定の IAM オペレーションを実行するアクセス許可をユーザーとロールに付与する API ポリシーを作成する必要があります。その後、管理者は、これらのアクセス許可を必要とする IAM ユーザーまたはグループにこれらのポリシーをアタッチする必要があります。

ポリシーの例については、以下のトピックを参照してください。

これらのサンプル IAM ポリシードキュメントを使用して JSON アイデンティティベースのポリシーを作成する方法については、「Word IAM ユーザーガイド」のJSON タブでのポリシーの作成」を参照してください。

ポリシーのベストプラクティス

ID ベースのポリシーは、アカウント内の CodeCommit リソースを作成、アクセス、または削除できるかどうかを決定します。これらのアクションを実行すると、 AWS アカウントに料金が発生する可能性があります。アイデンティティベースポリシーを作成したり編集したりする際には、以下のガイドラインと推奨事項に従ってください:

IAM のベストプラクティスの詳細については、Word ユーザーガイドのIAM のセキュリティのベストプラクティス」を参照してください。 IAM

CodeCommit コンソールの使用

AWS CodeCommit コンソールにアクセスするには、最小限のアクセス許可のセットが必要です。これらのアクセス許可により、Amazon Web Services アカウントの CodeCommit リソースの詳細を一覧表示して表示できます。最小必須アクセス許可よりも制限の厳しいアイデンティティベースのポリシーを作成すると、コンソールは、そのポリシーを持つエンティティ (IAM ユーザーまたはロール) に対して意図したとおりに機能しません。

これらのエンティティが引き続き CodeCommit コンソールを使用できるようにするには、次の AWS 管理ポリシーをエンティティにアタッチします。詳細については、IAM ユーザーガイドの「ユーザーへのアクセス許可の追加」を参照してください。

詳細については、「アイデンティティベースのポリシー (IAM ポリシー) for CodeCommit の使用」を参照してください。

AWS CLI または AWS API のみに呼び出しを行うユーザーに対して、最小限のコンソールアクセス許可を付与する必要はありません。代わりに、実行しようとしている API オペレーションに一致するアクションにのみアクセスを許可します。

自分の権限の表示をユーザーに許可する

この例では、IAM ユーザーがユーザー ID にアタッチされているインラインポリシーとマネージドポリシーを表示できるようにするポリシーを作成する方法を示します。このポリシーには、コンソールで、または AWS CLI or AWS API を使用してプログラムでこのアクションを実行するアクセス許可が含まれています。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "ViewOwnUserInfo",
            "Effect": "Allow",
            "Action": [
                "iam:GetUserPolicy",
                "iam:ListGroupsForUser",
                "iam:ListAttachedUserPolicies",
                "iam:ListUserPolicies",
                "iam:GetUser"
            ],
            "Resource": ["arn:aws:iam::*:user/${aws:username}"]
        },
        {
            "Sid": "NavigateInConsole",
            "Effect": "Allow",
            "Action": [
                "iam:GetGroupPolicy",
                "iam:GetPolicyVersion",
                "iam:GetPolicy",
                "iam:ListAttachedGroupPolicies",
                "iam:ListGroupPolicies",
                "iam:ListPolicyVersions",
                "iam:ListPolicies",
                "iam:ListUsers"
            ],
            "Resource": "*"
        }
    ]
}

CodeCommit の表示repositories タグに基づく

ID ベースのポリシーの条件を使用して、タグに基づいて CodeCommit リソースへのアクセスを制御できます。これを行う方法を示すポリシーの例については、「例 5: タグを使用してリポジトリに対するアクションを許可または拒否する」を参照してください。

詳細については、IAM ユーザーガイドのJSON「Word ポリシー要素: 条件」を参照してください。 IAM

AWS CodeCommit ID とアクセスのトラブルシューティング

以下の情報を使用して、 CodeCommit と IAM の使用時に発生する可能性のある一般的な問題を診断して修正します。

CodeCommit でアクションを実行する権限がありません

がアクションを実行する権限がないこと AWS Management Console を指示する場合は、管理者に連絡してサポートを求めてください。管理者とは、サインイン認証情報を提供した担当者です。

詳細については、「 CodeCommit コンソールの使用に必要な許可」を参照してください

iam:PassRole を実行する権限がありません

iam:PassRole アクションを実行する権限がないというエラーが表示された場合は、ロールを CodeCommit に渡すことができるようにポリシーを更新する必要があります。

一部の AWS のサービス では、新しいサービスロールまたはサービスにリンクされたロールを作成する代わりに、そのサービスに既存のロールを渡すことができます。そのためには、サービスにロールを渡す権限が必要です。

次のエラー例は、 という名前の IAM marymajor ユーザーがコンソールを使用して CodeCommit でアクションを実行しようとすると発生します。ただし、このアクションをサービスが実行するには、サービスロールから付与された権限が必要です。メアリーには、ロールをサービスに渡す許可がありません。

User: arn:aws:iam::123456789012:user/marymajor is not authorized to perform: iam:PassRole

この場合、Mary のポリシーを更新してメアリーに iam:PassRole アクションの実行を許可する必要があります。

サポートが必要な場合は、 AWS 管理者にお問い合わせください。サインイン認証情報を提供した担当者が管理者です。

アクセスキーを表示したい

IAM ユーザーアクセスキーを作成したら、いつでもアクセスキー ID を表示できます。ただし、シークレットアクセスキーを再表示することはできません。シークレットアクセスキーを紛失した場合は、新しいアクセスキーペアを作成する必要があります。

アクセスキーは、アクセスキー ID (例: AKIAIOSFODNN7EXAMPLE) とシークレットアクセスキー (例: wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY) の 2 つで構成されています。ユーザー名とパスワードと同様に、リクエストを認証するために、アクセスキー ID とシークレットアクセスキーの両方を使用する必要があります。ユーザー名とパスワードと同様に、アクセスキーは安全に管理してください。

アクセスキーペアを作成する場合、アクセスキー ID とシークレットアクセスキーを安全な場所に保存するように求めるプロンプトが表示されます。このシークレットアクセスキーは、作成時にのみ使用できます。シークレットアクセスキーを紛失した場合は、IAM ユーザーに新しいアクセスキーを追加する必要があります。アクセスキーは最大 2 つまで持つことができます。既に 2 つある場合は、新規キーペアを作成する前に、いずれかを削除する必要があります。手順を表示するには、IAM ユーザーガイドの「アクセスキーの管理」を参照してください。

管理者であり、他のユーザーに CodeCommit へのアクセスを許可したい

他のユーザーが CodeCommit にアクセスできるようにするには、アクセスが必要なユーザーまたはアプリケーションにアクセス許可を付与する必要があります。 AWS IAM Identity Center を使用してユーザーとアプリケーションを管理する場合は、アクセスレベルを定義するアクセス許可セットをユーザーまたはグループに割り当てます。アクセス許可セットは、ユーザーまたはアプリケーションに関連付けられている IAM ロールに IAM ポリシーを自動的に作成して割り当てます。詳細については、「AWS IAM Identity Center User Guide」の「Permission sets」を参照してください。

IAM Identity Center を使用していない場合は、アクセスが必要なユーザーまたはアプリケーションの IAM エンティティ (ユーザーまたはロール) を作成する必要があります。その後、 CodeCommit で正しいアクセス許可を付与するポリシーをエンティティにアタッチする必要があります。アクセス許可が付与されたら、ユーザーまたはアプリケーション開発者に認証情報を提供します。 AWSへのアクセスにはこの認証情報を使用します。IAM ユーザー、グループ、ポリシー、およびアクセス許可の作成の詳細については、IAM ユーザーガイドの「Word の Word ID IAM とポリシー、およびアクセス許可IAM」を参照してください。

Amazon Web Services アカウント以外のユーザーに my CodeCommit リソースへのアクセスを許可したい

詳細については、「ロールを使用して AWS CodeCommit リポジトリへのクロスアカウントアクセスを設定する」を参照してください。