ShingoOmura氏

多くのクラウドプロバイダの提供する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にアクセスできる環境を実現できます。