Kubernetes Service Account As Multi-Cloud Identity
多くのクラウドプロバイダの提供するManaged Kubernetesサービスでは、Kubernetes Service Accountから、クラウドAPIを自動的に認証する機能を提供しています。EKSであればIAM Roles for Service Account(IRSA), GKEであればWorkload Ideneity等です。これらの機能を使えば、アプリケーションはクラウドSDKを呼び出すだけで、適切な権限をもつ、自動的に払い出された一時的なクレデンシャルを使って、シームレスかつ安全にクラウドAPIにアクセスすることが可能です。 しかし、これがオンプレミスで稼働しているようなUnmanagedなKubernetesであればどうでしょうか。永続的なAPI キーをクラウドプロバイダで発行し、それらを各アプリケーションPodにマウントすることでクラウドAPIの認証を実現していることが多いのではないでしょうか。永続的なAPIキーはそれ自体がセキュリティリスクとなりますし、リスク低減のためにはローテーションの運用負荷も存在します。アプリケーションが利用するAPIキーが複数存在したり、複数のクラウドプロバイダとやり取りする環境だと、これらのリスク・運用負荷はより大きくなります。 本セッションでは、KubernetesのServiceAccountIssuerDiscoveryの機能と、各種クラウドプロバイダが提供しているIdentity Federationの機能を活用して、永続的なAPI Keyを利用せず、KubernetesのService Accountを複数クラウド共通のIdentityとして利用可能にする方法について共有します。これによって、クラウドプロバイダ側でKubernetes Service Accountへの権限を付与するだけで、シームレスかつ安全に、複数クラウドAPIにアクセスできる環境を実現できます。
Shingo Omura
Shingo Omura
Preferred Networks, Inc.
エンジニア
中堅SIer, Web系スタートアップを経て、 2018年1月より現職。Preferred Networks(PFN)でエンジニアとして従事。分散システム 、コンテナ技術全般に興味がある。PFNでは深層学習向け大規模GPU Kuberntes クラスタの開発運用に携わっている。