ACS事業部の谷合です。
SIG Authの紹介と今後の動向についてご紹介します。
今回はKEP中心だったので、この記事でも気になったKEPに絞ってご紹介します。
SIG Authの紹介
- Kubernetesの認証・認可を担当している。
KEP紹介
KEP-3325 SelfSubjectReview
kubectl auth who-am-iコマンドを実行することで、以下のようにユーザの権限情報を出力させることができる機能のようです。今までなかったので、これは便利ですね！！v1.27現在はBetaで、v1.28でGAを目指しているとのことです。
{ "apiVersion": "authentication.k8s.io/v1alpha1", "kind": "SelfSubjectReview", "status": { "userInfo": { "name": "jane.doe", "uid": "b6c7cfd4-f166-11ec-8ea0-0242ac120002", "groups": [ "viewers", "editors" ], "extra": { "provider_id": [ "token.company.dev" ] } } } }
KEP-2799 Legacy Token Reduction
1.26から導入されていますが、ServiceAccountにTokenのSecretが紐づかなくなっています。
もしTokenが必要であれば手動作成する必要があります。1.28からは完全にSecret Tokenがなくなるとのことでした。
https://github.com/kubernetes/enhancements/tree/master/keps/sig-auth/2799-reduction-of-secret-based-service-account-token
KEP-3299 KMS v2 Improvements
KMSに関して以下の機能を持たせることを目標としているとのことでした。
- 暗号化されたリソースを多数持つクラスタの準備時間の改善
- KMSのレートリミットにぶつかる可能性が低くなる
- 最新キーの完全自動キーローテーションを可能にする
- KMSプラグインのヘルスチェックの信頼性を向上
- kube-apiserver、KMSプラグイン、KMS間の操作の観測性を向上
https://github.com/kubernetes/enhancements/tree/master/keps/sig-auth/3299-kms-v2-improvements
KEP-3221 Multiple Authorization Webhooks
認証にWebhookを使うことができますが、現在は単一のWebhookしか許可されていません。
そこで、複数Webhookをチェーンのようにつなぐことで認証を強化することができるようになるそうです。
設定例は以下の通りです。
apiVersion: apiserver.config.k8s.io/v1alpha1 kind: AuthorizationConfiguration authorizers: - type: Webhook webhook: kubeConfigFile: <path/to/kubeconfigfile> authorizedTTL: 5m unauthorizedTTL: 30s timeout: 3s subjectAccessReviewVersion: v1 onError: Deny - type: Node - type: RBAC - type: Webhook webhook: kubeConfigFile: <path/to/kubeconfigfile> authorizedTTL: 5m unauthorizedTTL: 30s subjectAccessReviewVersion: v1 onError: Deny
KEP-3331 Structured config for OIDC authentication
複数OIDC Providerが使えたり、CELにて様々なvalidationができるようになることを目標にしているとのことでした。 https://github.com/kubernetes/enhancements/blob/6da022b4fc850b1bb4875a297c8db9e8f87579d7/keps/sig-auth/3331-structured-config-for-oidc-authentication/README.md
KEP-3766 ReferenceGrant
namespaceを跨いで、Objectの操作ができるようなるようです。
つまりはnamespace跨ぎの権限確認ができるようになることを表しています。
この機能はみんな待ち望んでいると思います。
かくいう私も、この間実装したOperatorでnamespace跨ぎができずに、CRをクラスターワイドにして
乗り切ったので、是非とも早く実装してほしいです。
使用例として以下が挙げられます。
- Gatewayリソースのnamespace跨ぎのTLSシークレット参照
- PVCのnamespace跨ぎのデータソースの使用
さいごに
私自身プライベートでOperatorやWebhookを実装することもあり、認証・認可は身近に感じております。
魅力的な機能ばかりなので、実装が待ち望まれます。期待してリリースを待つことにします。
ACS事業部のご紹介
私達ACS事業部はAzure・AKSなどのクラウドネイティブ技術を活用した内製化のご支援をしております。
www.ap-com.co.jp
また、一緒に働いていただける仲間も募集中です！
今年もまだまだ組織規模拡大中なので、ご興味持っていただけましたらぜひお声がけください。
www.ap-com.co.jp
