Blog

マルチクラウド環境において、AWS から GCP のマネージドサービスに対し、OIDC によるキーレス連携を実現する GCP Workload Identity Federation の仕組みについて紹介します。多くのクラウドサービスでは、API キーや Credential（AWS アクセスキーや GSA アカウントキー）を発行することで、各種マネージドサービスにアクセスすることが可能です。しかし、永続的に使用できてしまう認証情報は、キーローテーションによる管理の煩雑化や、流出によるセキュリティリスクが存在します。GCP Workload Identity Federation では、Credential として有効期限の短い STS トークンで認証・認可を行うため、前述のセキュリティリスクを軽減できます。これらの処理はクライアントライブラリによって隠蔽されるため、サービスの開発者やワークロードは OAuth 2.0 Token Exchange の複雑な仕組みを意識することなく、通常の Credential と同じように利用することができます。GCP Workload Identity Federation は非常にセキュアで利便性が良いですが、内部でどのような手続きが行われているのか気になったので DeepDive してみました。

サイバーエージェント新卒研修にて『生成 AI を用いた SNS』というテーマで 3 週間の短期開発に取り組みました。我々のチームは 'AI で生成した美女' を共有する SNS アプリケーションを開発し、成果発表では インフラ部門で技術賞 を頂きました。今回の記事では、開発したサービスと実際に構築した運用アーキテクチャについて設計思想や技術選定を交え、紹介したいと思います。

株式会社 AbemaTV Cloud Platform Team にて ABEMA を構成するマイクロサービスのデプロイ状況を可視化するモニタリングツールの開発・導入ミッションに臨みました。本ブログは 「CyberAgent Developers Blog - ABEMA におけるマイクロサービスデプロイ状況可視化のための内製モニタリングツールの開発」 に掲載された内容です。

クラウドサービスや Third-party ベンダが普及する昨今、各サービスを連携する上で、OIDC や OAuth 2.0 という言葉をよく耳にすると思います。これらの仕組みは、サービスを利用する際のセキュリティを担保する上で重要となる、認証・認可を提供するための基本的な規約（プロトコル）になります。OAuth 2.0 や、その仕組みを流用して拡張された OIDC は複雑で、認証・認可において多くのフローを辿ります。毎回、再調査をするのが大変なので、認証・認可の仕組みについて一度整理しておきたいと思います。

現在、研究室で利用するための KaaS 基盤（プライベートクラウド）を整備するべく、ベアメタル Kubernetes の構築に取り組んでいます。今回は、CNCF cloud native landscape にもある Rook/Ceph を使用して分散ストレージシステムを導入し、Amazon S3 や Google Cloud Storage に相当するオブジェクトストレージを自前で構築してみたので、その紹介です。