チュートリアルで理解するBinary Authorization

川村航平 - Nomura Research Institute, Ltd.

はじめに
- 想定読者
Binary Authorization 概要
チュートリアルの流れ
チュートリアル
まとめ

はじめに

こんにちは、NRIの川村です。

近年、コンテナ技術の利用は一般的になりましたが、それに伴いセキュリティの考慮事項も増えています。例えば、「NIST Special Publication 800-190(アプリケーションコンテナセキュリティガイド」では、「コンテナ技術のコアコンポーネントの主なリスク」として、「信頼できないイメージの使用」や「未承認コンテナ」が挙げられています。これらのリスクに対するソリューションが、Google Cloud が提供する Binary Authorization です。

Binary Authorization を大まかに言うと、定義したポリシーを遵守したコンテナイメージのみデプロイを許可するサービスです。本ブログでは、公式チュートリアル「Google Cloud CLI の使用を開始する（GKE）」をベースに、実際に手を動かしながら Binary Authorization の仕組みを確認します。

公式チュートリアルでは Google が管理するコンテナイメージリポジトリの使用や、kubectl run コマンドでのデプロイを行っています。本ブログでは、より実践的なシナリオを想定し、Google Cloud プロジェクト内に作成した Artifact Registry の使用やマニフェストファイルを使用したデプロイで確認を行います。
適宜コンソール画面やログも補足しながらリソースの状態を確認していくので、ぜひ一緒に試してみてください。

想定読者

Binary Authorization がどのようなものか、ざっくりと把握したい方
Binary Authorization のドキュメントを読んだ上で、実際に触ってみたいと考えている方

Binary Authorization 概要

「Binary Authorization の概要」では、Binary Authorization を次のように説明しています。

Binary Authorization は、コンテナベースのアプリケーションを開発してデプロイするときに、ソフトウェアサプライチェーンのセキュリティ対策を実装するために使用できる Google Cloud プロダクトです。

もう少し具体化すると、信頼できると検証されたコンテナイメージのみがデプロイされることを保証するサービスです。
Binary Authorization によるデプロイ制御の中心となるのが ポリシーです。ポリシーには、どのようなイメージを許可/拒否するかを定義する評価モードを設定します。評価モードの種類は以下の通りです。

すべてのイメージを許可: デフォルトの状態。すべてのイメージのデプロイを許可
すべてのイメージを拒否: すべてのイメージのデプロイを禁止
認証者によって承認されたイメージのみを許可: 指定した「認証者」によって承認されたイメージのみデプロイを許可

本ブログでは、「認証者によって承認されたイメージのみを許可」の評価モードを使用します。この評価モードを理解する上で重要なのが、認証者 と 署名者 の役割です。

認証者 (Attestor): ポリシーに設定され、デプロイの可否を判断する。公開鍵を使って署名を検証する役割を担う。
署名者 (Signer): 秘密鍵を用いて署名を行う（証明書を作成する）役割を担う。

認証者と署名者の関係により、「署名者が秘密鍵で署名したイメージ」を、「認証者が公開鍵で署名を検証し、デプロイを許可する」という流れが実現されます。

チュートリアルの流れ

今回のチュートリアルは、以下の流れで行います。

実行環境準備
プロジェクト設定と API の有効化
Binary Authorization を有効にした GKE クラスタの作成
デフォルトポリシーの確認
認証者の作成
署名・検証用の鍵ペアを生成
認証者に公開鍵を追加
ポリシーの設定変更
検証用イメージを Artifact Registry に格納
署名なしイメージのデプロイ（失敗確認）
イメージへの署名とデプロイ（成功確認）

また、本チュートリアルで構成する環境の全体イメージを以下に示します。

チュートリアル

実行環境準備

前提として、gcloud CLI 、 kubectl 、 Docker を使える環境が必要となります。準備手順については、本ブログでは割愛します。

プロジェクト設定と API の有効化

まずは、チュートリアルを進めるためにプロジェクト設定と API の有効化を行います。

デフォルトプロジェクトを設定

作業対象の Google Cloud プロジェクト ID を変数に設定し、gcloud コマンドのデフォルトプロジェクトとして設定します。

PROJECT_ID=<作業プロジェクトID>
gcloud config set project ${PROJECT_ID}

必要な API を有効化

今回のチュートリアルでは、以下のサービスを使用します。それぞれの API を有効にします。

Google Kubernetes Engine (GKE)
Artifact Registry
Binary Authorization
Cloud Key Management Service (Cloud KMS)

gcloud --project=${PROJECT_ID} \
  services enable \
  container.googleapis.com \
  artifactregistry.googleapis.com \
  binaryauthorization.googleapis.com \
  cloudkms.googleapis.com

Binary Authorization を有効にした GKE クラスタの作成

次に、Binary Authorization を有効にした GKE クラスタを作成します。
--binauthz-evaluation-mode=PROJECT_SINGLETON_POLICY_ENFORCE オプションを付けることで、作成するクラスタが Binary Authorization ポリシーに従うようになります。また、binauthz-evaluation-modeで指定できる値は、disabled または PROJECT_SINGLETON_POLICY_ENFORCE です。
※以下コマンドを実行するにあたって、default の VPC ネットワークが必要となります。

gcloud container clusters create \
  --binauthz-evaluation-mode=PROJECT_SINGLETON_POLICY_ENFORCE \
  --zone us-central1-a \
  test-cluster

補足: オプションに binauthz とありますが、AuthZ は認可 (Authorization) を意味します。また、AuthN は認証 (Authentication) を意味します。 Google Cloud ブログの「Identity & Access management: Authentication with Cloud Identity」にも記載があります。

デフォルトポリシーの確認

現在の Binary Authorization ポリシーを確認します。

gcloud container binauthz policy export

出力結果は以下のようになっているはずです。evaluationMode: ALWAYS_ALLOW という部分に注目してください。この設定が「すべてのイメージを許可する」というデフォルトの評価モードです。

defaultAdmissionRule:
  enforcementMode: ENFORCED_BLOCK_AND_AUDIT_LOG
  evaluationMode: ALWAYS_ALLOW
globalPolicyEvaluationMode: ENABLE
name: projects/<作業プロジェクトID>/policy

ポリシーの各項目の詳細については、ドキュメント「ポリシー YAML のリファレンス」も参照してください。
参考として、コンソール画面でのポリシー表示は以下の通りです。

認証者の作成

ポリシーを変更し、「認証者によって承認されたイメージのみを許可」する評価モードを適用します。はじめに、認証者を作成していきます。

認証者を作成する前に、Artifact Analysis メモを作成する必要があります。Binary Authorization ではイメージの署名を検証しますが、署名情報である証明書を保存する場所として Artifact Analysis を利用します。
Artifact Analysis の詳細は割愛しますが、Artifact Analysis の概要やメモについては以下ドキュメントを参照ください。

Artifact Analysis メモの作成

最初に、証明書を格納するためのメモを作成します。
メモの内容を定義した JSON ファイルを作成後、Artifact Analysis API を呼び出してメモの作成と確認をします。

NOTE_ID=test-attestor-note

cat > /tmp/note_payload.json << EOM
{
  "name": "projects/${PROJECT_ID}/notes/${NOTE_ID}",
  "attestation": {
    "hint": {
      "human_readable_name": "Attestor Note"
    }
  }
}
EOM

curl -X POST \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer $(gcloud auth print-access-token)"  \
  --data-binary @/tmp/note_payload.json  \
  "https://containeranalysis.googleapis.com/v1/projects/${PROJECT_ID}/notes/?noteId=${NOTE_ID}"

curl \
  -H "Authorization: Bearer $(gcloud auth print-access-token)" \
  "https://containeranalysis.googleapis.com/v1/projects/${PROJECT_ID}/notes/${NOTE_ID}"

実際の確認ログは以下の通りです。

$ curl \
  -H "Authorization: Bearer $(gcloud auth print-access-token)" \
  "https://containeranalysis.googleapis.com/v1/projects/${PROJECT_ID}/notes/${NOTE_ID}"
{
  "name": "projects/<作業プロジェクトID>/notes/test-attestor-note",
  "kind": "ATTESTATION",
  "createTime": "2025-09-10T07:41:45.990712Z",
  "updateTime": "2025-09-10T07:41:45.990712Z",
  "attestation": {
    "hint": {
      "humanReadableName": "Attestor Note"
    }
  }
}
$

認証者の作成

作成したメモを紐付けて、認証者の作成と確認をします。

ATTESTOR_NAME=test-attestor

gcloud container binauthz attestors create ${ATTESTOR_NAME} \
  --attestation-authority-note=${NOTE_ID} \
  --attestation-authority-note-project=${PROJECT_ID}

gcloud container binauthz attestors list

実際の確認ログは以下の通りです。

$ gcloud container binauthz attestors list
┌───────────────┬──────────────────────────────────────────────────────────┬─────────────────┐
│      NAME     │                           NOTE                           │ NUM_PUBLIC_KEYS │
├───────────────┼──────────────────────────────────────────────────────────┼─────────────────┤
│ test-attestor │ projects/<作業プロジェクトID>/notes/test-attestor-note     │ 0               │
└───────────────┴──────────────────────────────────────────────────────────┴─────────────────┘
$

コンソール画面で認証者が作成され、詳細を見ると先ほど作成したメモが紐づいていることを確認できます。

署名・検証用の鍵ペアを生成

次に、イメージへの署名と検証に使うための鍵ペアを Cloud KMS で作成します。
鍵の作成に必要な情報を変数として設定し、キーリングと鍵を順に作成します。

KMS_KEYRING_NAME=my-binauthz-keyring
KMS_KEY_NAME=my-binauthz-kms-key-name
KMS_KEY_LOCATION=global
KMS_KEY_PURPOSE=asymmetric-signing
KMS_KEY_ALGORITHM=ec-sign-p256-sha256
KMS_PROTECTION_LEVEL=software
KMS_KEY_VERSION=1

gcloud kms keyrings create ${KMS_KEYRING_NAME} \
  --location ${KMS_KEY_LOCATION}

gcloud kms keys create ${KMS_KEY_NAME} \
  --location ${KMS_KEY_LOCATION} \
  --keyring ${KMS_KEYRING_NAME}  \
  --purpose ${KMS_KEY_PURPOSE} \
  --default-algorithm ${KMS_KEY_ALGORITHM} \
  --protection-level ${KMS_PROTECTION_LEVEL}

認証者に公開鍵を追加

作成した鍵のうち公開鍵を、先ほど作成した認証者に関連付けます。
この設定により、認証者は追加された公開鍵を使って署名を検証できるようになります。

gcloud --project="${PROJECT_ID}" \
  container binauthz attestors public-keys add \
  --attestor="${ATTESTOR_NAME}" \
  --keyversion-project="${PROJECT_ID}" \
  --keyversion-location="${KMS_KEY_LOCATION}" \
  --keyversion-keyring="${KMS_KEYRING_NAME}" \
  --keyversion-key="${KMS_KEY_NAME}" \
  --keyversion="${KMS_KEY_VERSION}"

コンソールで認証者の詳細を確認すると、Cloud KMS の公開鍵が追加されていることがわかります。

ポリシーの設定変更

ポリシーを更新し、作成した認証者による証明書の検証を必須に変更します。
evaluationMode を REQUIRE_ATTESTATION に変更し、requireAttestationsBy で先ほど作成した認証者を指定するポリシーファイルの作成とインポートをします。

cat > /tmp/policy.yaml << EOM
  globalPolicyEvaluationMode: ENABLE
  defaultAdmissionRule:
    evaluationMode: REQUIRE_ATTESTATION
    enforcementMode: ENFORCED_BLOCK_AND_AUDIT_LOG
    requireAttestationsBy:
      - projects/${PROJECT_ID}/attestors/${ATTESTOR_NAME}
  name: projects/${PROJECT_ID}/policy
EOM

gcloud container binauthz policy import /tmp/policy.yaml

コンソールでポリシーを確認すると、デフォルトルールが「次のすべての認証者によって承認されたイメージのみを許可。」に変更され、今回作成した認証者が指定されていることを確認できます。

検証用イメージを Artifact Registry に格納

リポジトリ作成
ポリシーの動作をテストするために、デプロイするコンテナイメージを Artifact Registry に格納します。
Docker リポジトリを作成し、ローカルの Docker クライアントからイメージを push できるように認証を設定します。実行コマンドは、「Docker コンテナイメージを Artifact Registry に保存する」を参考にしています。

gcloud artifacts repositories create quickstart-docker-repo --repository-format=docker \
  --location=us-central1 --description="Docker repository"

gcloud auth configure-docker us-central1-docker.pkg.dev

テスト用イメージの pull と作成したリポジトリへの push

Google が提供しているサンプルイメージを pull し、作成したリポジトリに push します。

docker pull us-docker.pkg.dev/google-samples/containers/gke/hello-app:1.0

docker tag us-docker.pkg.dev/google-samples/containers/gke/hello-app:1.0 \
  us-central1-docker.pkg.dev/${PROJECT_ID}/quickstart-docker-repo/hello-app:1.0

docker push us-central1-docker.pkg.dev/${PROJECT_ID}/quickstart-docker-repo/hello-app:1.0

署名なしイメージのデプロイ（失敗確認）

タグを指定したデプロイ確認
デプロイを行うための準備が整ったので、ポリシーの動作をテストします。まずは、まだ署名されていないイメージのタグを指定してデプロイします。

kubectlで操作できるように認証情報の取得と GKE へのデプロイ用マニフェストを作成します。マニフェストは「Hello app deployment」をベースとしています。

gcloud container clusters get-credentials \
  --zone us-central1-a \
  test-cluster

cat > /tmp/deployment_tag.yaml << EOM
  apiVersion: apps/v1
  kind: Deployment
  metadata:
    name: helloweb
    labels:
      app: hello
  spec:
    selector:
      matchLabels:
        app: hello
        tier: web
    template:
      metadata:
        labels:
          app: hello
          tier: web
      spec:
        containers:
        - name: hello-app
          image: us-central1-docker.pkg.dev/${PROJECT_ID}/quickstart-docker-repo/hello-app:1.0 #タグ指定
          ports:
          - containerPort: 8080
          resources:
            requests:
              cpu: 200m
EOM

イメージのデプロイと確認をします。

kubectl apply -f /tmp/deployment_tag.yaml

kubectl get pods

kubectl get deployments

kubectl get event --template \
  '{{range.items}}{{"\033[0;36m"}}{{.reason}}:{{"\033[0m"}}\{{.message}}{{"\n"}}{{end}}'

実際のログは以下の通りです。

$ kubectl apply -f /tmp/deployment_tag.yaml
deployment.apps/helloweb created
$ kubectl get pods
No resources found in default namespace.
$ kubectl get deployments
NAME       READY   UP-TO-DATE   AVAILABLE   AGE
helloweb   0/1     0            0           13s
$ kubectl get event --template \
  '{{range.items}}{{"\033[0;36m"}}{{.reason}}:{{"\033[0m"}}\{{.message}}{{"\n"}}{{end}}'
～～～一部のログ割愛～～～
FailedCreate:\Error creating: admission webhook "imagepolicywebhook.image-policy.k8s.io" denied the request: Image us-central1-docker.pkg.dev/<作業プロジェクトID>/quickstart-docker-repo/hello-app:1.0 denied by Binary Authorization default admission rule. Image us-central1-docker.pkg.dev/<作業プロジェクトID>/quickstart-docker-repo/hello-app:1.0 denied by attestor projects/<作業プロジェクトID>/attestors/test-attestor: Expected digest with sha256 scheme, but got tag or malformed digest
～～～一部のログ割愛～～～
$

Deployment は作成されたものの、kubectl get pods では Pod が見つからないことがわかります。kubectl get event でイベントを確認すると、FailedCreate イベントが発生しており、denied by Binary Authorization default admission rule. といったメッセージから、Binary Authorization によってデプロイがブロックされたことが確認できます。
また、エラーメッセージにある Expected digest with sha256 scheme, but got tag or malformed digest から、タグを指定したデプロイをできないことがわかります。以下ドキュメントに記載の通り、GKE で Binary Authorization を使用する場合、タグではなくダイジェストを指定する必要があります。タグではデプロイ時に使用される正確なイメージを特定できないため、タグベースのデプロイは許可されないためです。

コンテナイメージのダイジェストについて

Google Kubernetes Engine（GKE）で Binary Authorization を使用する場合、Pod の作成時に使用される正確なイメージを特定できないため、タグベースの Deployment は許可されません。

コンテナをデプロイする（GKE、Distributed Cloud）

Binary Authorization はダイジェストを使用して証明書を検索するため、1.0 や latest などのタグではなく、ダイジェストを使用してイメージをデプロイする必要があります。

次の手順に進むために、作成されたDeploymentを削除します。

kubectl delete deployment helloweb

ダイジェストを指定したデプロイ確認

マニフェストでダイジェストを使用したイメージパスを指定します。マニフェストの変更点は、imageのみです。

IMAGE_PATH="us-central1-docker.pkg.dev/${PROJECT_ID}/quickstart-docker-repo/hello-app"
IMAGE_DIGEST=$(gcloud artifacts docker images describe "${IMAGE_PATH}:1.0" --format='get(image_summary.digest)')
IMAGE_TO_ATTEST="${IMAGE_PATH}@${IMAGE_DIGEST}"

cat > /tmp/deployment_digest.yaml << EOM
  apiVersion: apps/v1
  kind: Deployment
  metadata:
    name: helloweb
    labels:
      app: hello
  spec:
    selector:
      matchLabels:
        app: hello
        tier: web
    template:
      metadata:
        labels:
          app: hello
          tier: web
      spec:
        containers:
        - name: hello-app
          image: ${IMAGE_TO_ATTEST} #ダイジェスト指定
          ports:
          - containerPort: 8080
          resources:
            requests:
              cpu: 200m
EOM

ダイジェストを指定してイメージのデプロイと確認をします。

kubectl apply -f /tmp/deployment_digest.yaml

kubectl get pods

kubectl get deployments

kubectl get event --template \
  '{{range.items}}{{"\033[0;36m"}}{{.reason}}:{{"\033[0m"}}\{{.message}}{{"\n"}}{{end}}'

実際のログは以下の通りです。

$ kubectl apply -f /tmp/deployment_digest.yaml
deployment.apps/helloweb created
$ kubectl get pods
No resources found in default namespace.
$ kubectl get deployments
NAME       READY   UP-TO-DATE   AVAILABLE   AGE
helloweb   0/1     0            0           12s
$ kubectl get event --template \
  '{{range.items}}{{"\033[0;36m"}}{{.reason}}:{{"\033[0m"}}\{{.message}}{{"\n"}}{{end}}'
～～～一部のログ割愛～～～
FailedCreate:\Error creating: admission webhook "imagepolicywebhook.image-policy.k8s.io" denied the request: Image us-central1-docker.pkg.dev/<作業プロジェクトID>/quickstart-docker-repo/hello-app@sha256:98d0e48b3dd51f8ab92cddc33efc5e1b1385bbaad09a4c1b2c3b0eeb3c8dc403 denied by Binary Authorization default admission rule. Image us-central1-docker.pkg.dev/<作業プロジェクトID>/quickstart-docker-repo/hello-app@sha256:98d0e48b3dd51f8ab92cddc33efc5e1b1385bbaad09a4c1b2c3b0eeb3c8dc403 denied by attestor projects/<作業プロジェクトID>/attestors/test-attestor: No attestations found that were valid and signed by a key trusted by the attestor
～～～一部のログ割愛～～～
$

ダイジェストを指定してもデプロイは失敗しました。今回はエラーメッセージが No attestations found that were valid and signed by a key trusted by the attestor となっており、認証者の信頼する鍵で署名された有効な証明書がないために失敗したことがわかります。

次の手順に進むために、作成されたDeploymentを削除します。

kubectl delete deployment helloweb

イメージへの署名とデプロイ（成功確認）

前の手順では、証明書がないことでデプロイがブロックされました。次に秘密鍵でイメージへの署名を行い、正常にデプロイできることを確認します。署名対象のイメージは、前の手順で設定した変数（$IMAGE_TO_ATTEST）をそのまま使用します。
まずは、署名による証明書の作成と確認をします。

gcloud beta container binauthz attestations sign-and-create \
  --project="${PROJECT_ID}" \
  --artifact-url="${IMAGE_TO_ATTEST}" \
  --attestor="${ATTESTOR_NAME}" \
  --attestor-project="${PROJECT_ID}" \
  --keyversion-project="${PROJECT_ID}" \
  --keyversion-location="${KMS_KEY_LOCATION}" \
  --keyversion-keyring="${KMS_KEYRING_NAME}" \
  --keyversion-key="${KMS_KEY_NAME}" \
  --keyversion="${KMS_KEY_VERSION}"

gcloud container binauthz attestations list \
  --attestor=${ATTESTOR_NAME} --attestor-project=${PROJECT_ID}

実際の確認ログは以下の通りです。

$ gcloud container binauthz attestations list \
  --attestor=${ATTESTOR_NAME} --attestor-project=${PROJECT_ID}
---
attestation:
  serializedPayload: <詳細は割愛>
  signatures:
  - publicKeyId: //cloudkms.googleapis.com/v1/projects/<作業プロジェクトID>/locations/global/keyRings/my-binauthz-keyring/cryptoKeys/my-binauthz-kms-key-name/cryptoKeyVersions/1
    signature: <詳細は割愛>
createTime: '2025-09-10T07:54:00.783969Z'
kind: ATTESTATION
name: projects/<作業プロジェクトID>/occurrences/62e3bb9e-fffc-4248-b6aa-7a3e62ef22b5
noteName: projects/<作業プロジェクトID>/notes/test-attestor-note
resourceUri: us-central1-docker.pkg.dev/<作業プロジェクトID>/quickstart-docker-repo/hello-app@sha256:98d0e48b3dd51f8ab92cddc33efc5e1b1385bbaad09a4c1b2c3b0eeb3c8dc403
updateTime: '2025-09-10T07:54:00.783969Z'
$

同じダイジェストを持つイメージの再デプロイと確認をします。

kubectl apply -f /tmp/deployment_digest.yaml

kubectl get pods

kubectl get deployments

kubectl get event --template \
  '{{range.items}}{{"\033[0;36m"}}{{.reason}}:{{"\033[0m"}}\{{.message}}{{"\n"}}{{end}}'

実際のログは以下の通りです。

$ kubectl apply -f /tmp/deployment_digest.yaml
deployment.apps/helloweb created
$ kubectl get pods
NAME                        READY   STATUS    RESTARTS   AGE
helloweb-6b68fdb858-2ljtr   1/1     Running   0          5s
$ kubectl get deployments
NAME       READY   UP-TO-DATE   AVAILABLE   AGE
helloweb   1/1     1            1           11s
$ kubectl get event --template \
  '{{range.items}}{{"\033[0;36m"}}{{.reason}}:{{"\033[0m"}}\{{.message}}{{"\n"}}{{end}}'
～～～一部のログ割愛～～～
Scheduled:\Successfully assigned default/helloweb-6b68fdb858-2ljtr to gke-test-cluster-default-pool-5caef5a4-hndn
Pulling:\Pulling image "us-central1-docker.pkg.dev/<作業プロジェクトID>/quickstart-docker-repo/hello-app@sha256:98d0e48b3dd51f8ab92cddc33efc5e1b1385bbaad09a4c1b2c3b0eeb3c8dc403"
Pulled:\Successfully pulled image "us-central1-docker.pkg.dev/<作業プロジェクトID>/quickstart-docker-repo/hello-app@sha256:98d0e48b3dd51f8ab92cddc33efc5e1b1385bbaad09a4c1b2c3b0eeb3c8dc403" in 2.588s (2.588s including waiting). Image size: 13516885 bytes.
Created:\Created container: hello-app
Started:\Started container hello-app
SuccessfulCreate:\Created pod: helloweb-6b68fdb858-2ljtr
～～～一部のログ割愛～～～
$

ログから、Pod と Deployment が正常に作成され、Pod のステータスが Running になっていることが確認できます。イベントログからもイメージの Pull から Pods の作成まで成功していることがわかります。

以上の手順で、Binary Authorization のポリシーに従い、署名されたイメージが正常にデプロイされることが確認できました。

まとめ

今回は、Binary Authorization のチュートリアルを通して、定義したポリシーを遵守したコンテナイメージのみデプロイを許可する流れを確認しました。実際に手を動かすことで、各リソースの役割と全体の流れをイメージできたのではないでしょうか。

改めてですが、今回のチュートリアルで主に実施したことは以下です。

ポリシーでデプロイのルールを定義
認証者に公開鍵を追加
秘密鍵でイメージに署名し、証明書を作成
ポリシーで指定された認証者が証明書を検証し、イメージをデプロイ

Binary Authorization は、セキュアなソフトウェアサプライチェーンを実現するための有用なサービスです。今回は手元の作業端末で署名を行いましたが、実際の開発現場では、CI/CD パイプラインに組み込み、Cloud Build などのサービスを使用して証明書作成を自動化することもできます。

本ブログが、Binary Authorization への理解を深め、コンテナ運用のセキュリティを考える一助となれば幸いです。

各種SNSでも情報を発信しています。ぜひフォローをお願いいたします。

atlax では、ソリューション・サービス全般に関するご相談やお問い合わせを承っております。

お問い合わせ

・atlax / クラウドの取り組み / Google Cloud

・2025/07/07 Google Cloud 新資格『Generative AI Leader』取得までにやったこと

・2025/06/04 Agent Development Kit (ADK) と MCP サーバーを Cloud Run で動かすための実践ガイド

採用情報

NRIの IT基盤サービスでは、キャリア採用を実施しています。様々な職種で募集しておりますので、ご興味を持たれた方はキャリア採用ページもぜひご覧ください。

・NRI / キャリア採用情報 / 職種一覧　※NRIサイトへ

※ 記載された会社名およびロゴ、製品名などは、該当する各社の登録商標または商標です。
※ アマゾンウェブサービス、Amazon Web Services、AWS およびロゴは、米国その他の諸国における、Amazon.com, Inc.またはその関連会社の商標です。
※ Microsoft、Azure は、米国 Microsoft Corporation の米国およびその他の国における登録商標または商標です。
※ Google Cloud、Looker、BigQuery および Chromebook は、Google LLC の商標です。
※ Oracle、Java、MySQL および NetSuite は、Oracle Corporation、その子会社および関連会社の米国およびその他の国における登録商標です。NetSuite は、クラウド・コンピューティングの新時代を切り開いたクラウド・カンパニーです。