0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

アリババクラウドアカウント間でアリババクラウドコンテナレジストリを共有する

Posted at

本記事はこちらのブログを参考にしています。
翻訳にはアリババクラウドのModelStudio(Qwen)を使用しております。

導入
コンテナ化は、アプリケーションを効率的かつ一貫性のある方法でデプロイするための普及的な選択肢となっています。コンテナはソフトウェアコードとすべての依存関係をパッケージ化し、さまざまな計算環境間でアプリケーションがスムーズに動作することを確保します。Alibaba Cloud Container Registry (ACR)は、Docker コンテナイメージやその他の OCI リソースのホスティングと管理に向けた安全で信頼性の高いプラットフォームであり、イメージ スキャン、自動ビルド、Alibaba Cloud サービスとのシームレスな統合といった機能を提供しています。これは、DevOps ワークフローにおいて不可欠なツールとなっています。貴社が複数の開発チームを持つ場合、おそらく異なるシステムを区別し、セキュリティ境界を強化し、コスト管理を改善するために複数の Alibaba Cloud アカウントを使用しています。複数アカウント構成がある場合、多くの顧客から、どのようにして効率的で管理しやすい方法で複数の Alibaba Cloud アカウント間で Alibaba Cloud Container Registry (ACR) を共有するかについて質問を受けます。Virtual Private Cloud (VPC)Cloud Enterprise Network (CEN)を活用することで、コンテナイメージや Helm チャートへのセキュアかつシームレスなアクセスを可能にし、コラボレーションを促進し、開発サイクルを加速することができます。ACR を単一アカウントの範囲外に拡張することは、企業が一貫性を持った開発環境を維持し、一貫性を確保し、重複作業を減らすことを可能にします。これは、異なる Alibaba Cloud アカウントにまたがるプロジェクトやチームを管理する企業にとって特に価値があります。複数アカウント構成についてさらに詳しく知りたい場合は、特にAlibaba Cloud の Resource Directoryを通じて、MNC Landing Zone Whitepaperをお勧めします。

解決策概要: ACR と VPC、CEN の統合
以下のように、Alibaba Cloud Resource Directory を使用して Alibaba Cloud アカウントを管理していると想定します。Resource Directory は、中央集権型の管理サービスであり、複数のアカウントを階層構造に整理し、統合リソース管理と簡単な管理を提供します。リソースを Resource Directory Organization に配置し、フォルダーにグループ化することで、顧客はセキュリティ、コンプライアンス、運用効率性を向上させることができます。この想定の設定では、共有サービスと Cloud Enterprise Network (CEN) をホストする中央インフラアカウントが存在します。CEN は、トランジット ルータを使用して異なるリージョンの Virtual Private Cloud (VPC) またはデータセンター間でプライベート接続を確立することで、ハブアンドスパイク アーキテクチャを実装する高可用性のネットワークサービスです。このデザインにより、顧客は阿里巴巴クラウドのプライベートバックボーン ネットワークを使用して、柔軟で安定的で拡張可能なグローバル ネットワークを構築できます。さらに、複数のビジネスユニット (BU) によって使用される複数の Alibaba Cloud アカウントがあると想定しています。アーキテクチャには、3つのコアコンポーネントが含まれます:

インフラアカウント内の VPC と統合された ACR によるセキュリティ強化
別々のアカウント間の VPC を橋渡しする CEN の活用
セキュアで制御されたアクセスを実現するための Resource Access Management (RAM) の実装

この設定は、セキュアな環境を維持しながら、効率的なアカウント間アクセスを可能にします:
目標アーキテクチャの図

実装
前提条件
このソリューションを自分のアカウントで実装しながら読むことをお勧めします。それには、次の前提条件が必要です:

Resource Directory のメンバーとしてのアカウント A。VPC と CEN を備えたもの。
1つ以上の Business Unit アカウント(B)を表す Resource Directory メンバー。重複しないCIDR範囲を持つVPCを備えたもの。
ACR、VPC、CEN、DNS 設定を作成および管理するために、両方のアカウントで管理者アクセスまたは十分な権限を持つ RAM ユーザー/ロール。
基本的な知識

Docker とコンテナレジストリに関する知識。VPC ネットワーキング、CEN、および Alibaba Cloud 上の DNS サービスについて理解していること。Resource Directory の設定は次のようになります:
Resource Directory のセットアップ

手順解説
実装ステップを進めます:

  1. インフラアカウント内の VPC に ACR をデプロイする:

まず、インフラアカウント内で ACR をデプロイしましょう。こちらのページの指示に従って、ACR インスタンスを作成してください。ACR Enterprise Edition(Basic Edition 以上)を選択してください。ACR のプライベート版は VPC へのアタッチメントをサポートしていないため、Enterprise Edition が必要です。コンテナレジストリの初期起動には数分かかる場合があります。次に、ACR インスタンスをインフラストラクチャ VPC にアタッチする必要があります。これにより、プライベート接続を使用して ACR にアクセスできるようになり、コンテナレジストリのセキュリティ強化が行われます。VPC ACL の設定の手順に従ってください。VPC ACL の設定により、Alibaba Cloud DNS PrivateZone が作成され、ACR はローカル VPC エンドポイントを指す DNS エントリを管理します。VPC エンドポイントが作成された後、コンソールで作成された DNS Private Zone を確認できます。プライベートゾーンを開いて、ACR の IP(VPC 内)であるレコード値をメモしてください。
2. ACR で名前空間を作成する:

ACR 名前空間は、リポジトリのコレクションであり、チームやプロジェクトのすべてのリポジトリをグループ化するために使用できます。アクセスポリシーを作成する際に役立ちます。後でテストするために使用する名前空間を作成しましょう。名前空間の管理の手順に従ってください。名前空間の名前を覚えておいてください。ステップ 7 で必要になります。
3. CEN インスタンスの作成:

ACR の部分が設定されたので、ネットワークの手順に進みます。Cloud Enterprise Network (CEN) は、アカウント間の通信に高速で柔軟なネットワークバックボーンを提供します。ここに記載されているように CEN インスタンスを作成してください。これは、すべての VPC 間の中央ルーティングバックボーンを提供します。
4. VPC ネットワークを CEN にアタッチする:

次に、ACR にアタッチされた VPC を CEN に接続するには、[ネットワークインスタンスのアタッチ](https://www.alibabacloud.com/jp/help/en/cen/user-guide/manage-network-instances#section-g
はじめに、ACR(Alibaba Cloud Container Registry)へのプルとプッシュのためのポリシーを、名前空間<NAMESPACE>に限定して作成しましょう。アカウントAで、以下のJSONを使用して、こちらに記載されている手順に従ってカスタムポリシーを作成してください。プレースホルダーを置き換えてください。

Placeholder
INSTANCE_ID ステップ1で作成したACRコンテナレジストリのID
NAMESPACE ステップ2で設定したACRの名前空間
ORGANIZATION_ID アリババクラウド・リソースディレクトリのID
FOLDER_ID アリババクラウド・アカウントBが属するリソースディレクトリのパス
{
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "cr:GetAuthorizationToken",
        "cr:ListInstance",
        "cr:GetInstance",
        "cr:ListNamespace",
        "cr:GetNamespace",
        "cr:ListRepository",
        "cr:GetRepository",
        "cr:ListTag",
        "cr:GetTag",
        "cr:ListArtifact",
        "cr:GetArtifact",
        "cr:ListChart",
        "cr:GetChart",
        "cr:PullRepository",
        "cr:CreateRepository",
        "cr:PushRepository"
      ],
      "Resource": [
        "acs:cr:*:*:instance/<INSTANCE_ID>",
        "acs:cr:*:*:repository/<INSTANCE_ID>/<NAMESPACE>/*"
      ]
    }
  ],
  "Version": "1"
}

次に、アカウント間アクセス用のRAMロールを作成します。こちらの手順に従ってください。RAMロールの信頼ポリシーを正確に構成することは重要であり、どのエンティティがロールを担うことができるかを定義しています。例えば、ecs.aliyuncs.comをプリンシパルとして指定することで、Elastic Compute Service(ECS)インスタンスがロールを担うことができます。Function Computeがこのロールを担う場合、プリンシパルをfc.aliyuncs.comに修正する必要があります。当該例では、テストでECSインスタンスからACRアクセスを行うため、ECSをプリンシパルとして使用し、またリソースディレクトリ内の特定のパスへのアクセスを制限する条件を追加します。これはビジネスユニットなどであるかもしれません。

{
  "Statement": [
    {
      "Action": "sts:AssumeRole",
      "Effect": "Allow",
      "Principal": {
        "Service": [
          "ecs.aliyuncs.com"
        ]
      },
      "Condition": {
        "StringEquals": {
          "acs:PrincipalRDId": "<ORGANIZATION_ID>",
          "acs:PrincipalRDPath": ["/<FOLDER_ID>"]
        }
      }
    }
  ],
  "Version": "1"
}

この設定により、アカウントAで作成されたロールは、当該リソースディレクトリ内の他のアカウントが担うことができるようになりました。次のステップでは、このポリシーをECSインスタンスから使用します。

  1. アカウントBからの共有ACRへのアクセステスト:
    アクセスをテストするために、ECSインスタンスを使用します。ACRアクセスの許可には、ステップ7で作成したロールをECSインスタンスが担えるようにします。ステップ7と同じ方法でRAMロールを作成し、アカウントBで以下のJSONポリシーと信頼ポリシーを使用します。ACCOUNT_AをインフラアカウントのID、ROLE_NAMEをステップ7で作成したロール名に置き換えます。
{
  "Version": "1",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "sts:AssumeRole",
      "Resource": "acs:ram:*:<ACCOUNT_A>:role/<ROLE_NAME>"
    }
  ]
}
{
  "Statement": [
    {
      "Action": "sts:AssumeRole",
      "Effect": "Allow",
      "Principal": {
        "Service": [
          "ecs.aliyuncs.com"
        ]
      }
    }
  ],
  "Version": "1"
}

その後、アカウントBのVPC内でECSインスタンスを作成し、先ほど作成したRAMロールを使用します。これにより、アクセスキーなしでインスタンスからACRレジストリにアクセスできます。こちらの手順に従ってACRの認証情報を設定すると、別のアリババクラウドアカウントにあるACRからプルやプッシュができるようになります。

最善策とセキュリティに関する考慮事項

当該ブログ記事では、ECSインスタンスからRAMロールを作成・担うことで、永続的なアクセスキーとシークレットキーの必要性を排除しました。このアプローチにより、定期的なキーのローテーションや使用場所の文書化という負荷を軽減し、セキュリティを強化します。また、悪意のあるアクターによる攻撃対象範囲を縮小し、運用負荷も削減します。さらに、コンテナレジストリへのアクセスにプライベートネットワークを使用することでセキュリティを向上させました。VPCに接続しプライベートネットワーク経由でのアクセスにより通信が安全になります。セキュリティ体制を更に強化するためには、VPCのイングレス・エグレスを管理できるアリババクラウドファイアウォールの導入も検討してください。

リソース利用の最適化

中央集約型のACRを使用することで、複数のDockerレジストリの管理コストが削減され、例えばDockerイメージ名のホスト部分の調整などの手間が省かれます。また、RAMを使用してイメージへのアクセス権限を一元的に管理できる場所が用意されます。アリババクラウドの複数リージョンにワークロードをデプロイする計画がある場合は、リージョン間レプリケーションを有効化したACRインスタンスを各リージョンに1つずつ使用することで、ネットワーク遅延や跨リージョンデータ転送コストを削減することを検討してください。

結論

本ブログでは、異なるアカウント間でアリババクラウドコンテナレジストリ(ACR)を共有し、アリババクラウド組織内でのアクセスやリソース共有を容易にする方法を紹介しました。手順としては:

  • アカウントAでACRインスタンスを作成・構成し、Dockerイメージのセキュアなリポジトリを確立しました。
  • ACRをVPCに接続し、プライベートネットワーク経由でのアクセスを通じてセキュリティを向上させました。
  • Cloud Enterprise Network(CEN)を使用してアカウントAとBのVPCを接続し、異なるワークロードの協調を可能にしました。
  • Resource Access Managerを使用してコンテナレジストリへのアクセスを厳密に定義し、Secret KeysではなくRAMロールを実装しました。

アカウント間でACRを共有することで、開発とオペレーションチームは複製されたリポジトリのオーバーヘッドなしでリアルタイムでリソースやアップデートを共有できるようになり、協力が強化されます。さらに、同じコンテンツを持つ複数のレジストリを維持する必要がなくなり、インフラコストや管理負荷が削減されるため、コンテナレジストリの統合にも活用できます。

撤去手順

作成した環境を継続的に使用しない場合、コストと不要なリソース使用を減らすために以下のようなリソースを解放することを忘れないでください:

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?