はじめに
このページではKubernetes v1.17におけるSIG-Authに関連する取り組みをまとめています。
必ずしもすべての sig/auth ラベルがついた変更についてまとめているわけではありません。ここに記載されていないものは別のまとめで記載されていると思いますので、 Kubernetes 1.17: 変更点まとめ(後日公開) も合わせて参照してみてください。
がついた文章は、CHANGELOGの公式内容ではなく筆者の補足です。
その他の注目機能 (Other notable changes)
docker-credential-desktop によってファイルに出力されたクレデンシャル情報はパディング無しのBase64エンコードされたデータのため、デコード時にエラーになっていたようです。修正後ははパディング有り・無しどちらでも対応できるようになったようです。
- kubelet と aggregated API servers で認証・認可に v1 TokenReview と SubjectAccessReview endpointを使うようになりました (#84768, @liggitt)
修正前は v1beta1 を使っていたようです。
- kube-apiserver で authentication/authorization webhookとの通信で v1 TokenReview and SubjectAccessReview APIが利用できるようになりました (#84768, @liggitt)
--authentication-token-webhook-version=v1 または --authorization-webhook-version=v1 を指定することにより利用できるようです
認証ロジックのパフォーマンスチューニングの一環でアクティブなトークンの数がキャッシュのサイズを超えないように対応されたようです。
トークンの数がキャッシュのサイズを超えるとパフォーマンスが著しく低下するとのこと。
キャッシュのサイズとしては 5k nodes and 10k namespaces のスケールで十分なサイズのようです。
参考: https://kubernetes.io/docs/tasks/access-kubernetes-api/
- Configmaps/extension-apiserver-authentication は kube-apiserver によって定期的に更新するように修正されたました (#82705, @deads2k)
ClusterAuthenticationTrustController というものが追加されて認証情報をメンテナンスするようです。
これまで複数のkube-apiserverが起動している場合にConfigMapに保管される認証情報は一番最後に起動したkube-apiserverのものが上書きされていましたが、これによりkube-apiserevr単位で異なる認証情報を持っていいた場合には、いずれかのkube-apiserverしか信頼できない状況になってしまいます。修正後はそれぞれのkube-apiserverの情報がConfigMapに保管するようになりました。