k8s 1.18 update
はじめに
このページではKubernetes v1.18におけるSIG-Authに関連する取り組みをまとめています。必ずしもすべての sig/auth ラベルがついた変更についてまとめているわけではありません。ここに記載されていないものは別のまとめで記載されていると思いますので、 Kubernetes 1.18: 変更点まとめ(後日公開) も合わせて参照してみてください。
がついた文章は、CHANGELOGの公式内容ではなく筆者の補足です。
Urgent Upgrade Notes
(No, really, you MUST read this before you upgrade)
kube-apiserver:
-
certificatesigningrequests/approvalAPIのコンシューマはCSRsに指定されたsignerに対するapproveの権限を持つ必要があります。
新しく追加されたsingerNameフィールドおよび必要な権限については https://kubernetes.io/docs/reference/access-authn-authz/certificate-signing-requests/#authorization を参照してください。(#88246, @munnerz) [SIG API Machinery, Apps, Auth, CLI, Node and Testing]-
CertificateSigningRequestリソースにsingerNameフィールドが追加されたことにより、利用用途などによってsingerを変更可能になりました。
(kubernetes.io/kube-apiserver-client-kubelet,kubernetes.io/kubelet-serving,kubernetes.io/legacy-unknownといったビルトインのsingerから、カスタムsingerを用意して指定することも可能)
singerNameの拡張により、CertificateSigningRequestのapprovalの権限に変更が必要です。
certificatesigningrequestsに対するget,listおよびertificatesigningrequests/approvaに対するupdateの他にsignersリソースに対してapproveの権限が必要になりました。
-
Changes by Kind
- N/A
API Change
New API types/versions:
- N/A
New API fields:
- N/A
Other API changes:
-
ServiceAccountIssuerDiscoveryの機能がalpha版として利用可能になり、/.well-knwon/openid-configurationと/openid/v1/jwksエンドポイントがAPIサーバによって構成されるようになります。これらのエンドポイントからはOIDC Discoveryの情報とServiceAccount Tokenの検証鍵を得ることができます。(#80724, @cceckman) [SIG API Machinery, Auth, Cluster Lifecycle and Testing]-
この機能を有効にするとAPIサーバによってOpenID Provider Configuration と JWKS エンドポイントを提供され、
https://<api-server>/.well-known/openid-configurationにアクセスすると、ServiceAccount Tokenに関する情報(Issuerや署名アルゴリズム、JWKSエンドポイントのURLなど)を取得することができます。JWKSエンドポイントではTokenの署名を検証するための鍵情報をJWK形式で取得することができます。 これまではTokenReview APIなどを介してTokenを検証することはできましたが、この機能ではServiceAccount Tokenによって送信元を認証したいサービスは一般的はOIDCのRelying PartyのようにJWKSエンドポイントからServiceAccountトークン(JWT)の署名を検証するための鍵を取得することができます。KubernetesのServiceAccount Tokenによる認証をより汎用的に利用することができます。またサービスが自身でトークンを検証することによってAPIサーバへの負荷を軽減することもできます。
-
Configuration file changes:
- N/A
kube-scheduler:
- N/A
kube-proxy:
- N/A
Features graduated to beta:
- N/A
Features graduated to GA:
- N/A
Feature
-
Azure auth module に config-mode flag が追加され、有効にするとAzureADトークンのaudience claimから
spn:プリフィックスが省かれます。指定しない場合いは動作に影響はありません。(#87630, @weinong) [SIG API Machinery, Auth, CLI and Cloud Provider]-
Azureの認証 APIのバージョンによって(?)ID Token内の
audclaimにspn:プリフィックスがついているかどうかが異なり、Token検証に失敗するようなケースがあるようです。AzureADを使っているコードで複数の同じようなissueがありました。audclaimにspn:プリフィックスを付与しないようにするには kubectlのconfigで--auth-provider-arg=config-mode="1"を指定します。
-
-
kubeadm: 実験的な機能として
PublicKeysECDSAを追加しました。kubeadm initにてECDSAの証明書を使ってクラスタを作成することができます。ECDSA 証明書の更新はkubeadm alpha certs renewでサポートされますが、on the fly での RSAからECDSAへのアルゴリズム切り替えやアップグレードはサポートされません。(#86953, @rojkov) [SIG API Machinery, Auth and Cluster Lifecycle] -
SafeSysctlWhitelistに
net.ipv4.ping_group_rangeが追加されました (#85463, @AkihiroSuda) [SIG Auth] -
Authentication, Authorization Webhook で network proxyがalphaサポートされました。
-
該当のKEPはこちら(https://github.com/kubernetes/enhancements/blob/master/keps/sig-api-machinery/20190226-network-proxy.md)。Kubernetes APIサーバからの外向きの通信についてEgressSelectorで設定されたコンテキストにもとづいたProxy経由で通信させるような機能のようです。
-
-
クライアント証明書が提供された場合、新しい接続のために証明書をリロードし、証明書が変更されるとコネクションを閉じます。(#79083, @jackkleeman) [SIG API Machinery, Aupth, Node and Testing]
-
クライアント証明書のローテーション対応
-
-
kubectlの
--tls-server-nameによってkubecofigに設定された値でTLS Server Nameを上書きできるようになりました (#88769, @deads2k) [SIG API Machinery, Auth and CLI]
Metrics:
-
クライアント証明書に関する２つのメトリクスを追加: (#84382,@sambdavidson) [SIG API Machinery, Auth, Cluster Lifecycle and Instrumentation]
-
rest_client_certificate_expiration_seconds: 現在のクライアント証明書の有効期限を1970/1/1UTCからの秒単位で表します -
rest_client_certificate_rotation_age: ローテーションされたクライアント証明書の経過時間を秒単位で表します
-
-
- Kubelet 証明書のローテーションに失敗した場合に
server_expiration_renew_failureおよびclient_expiration_renew_failure metric counterexportするようになりました (#84614, @rphillips) [SIG API Machinery, Auth, CLI, Cloud Provider, Cluster Lifecycle, Instrumentation, Node and Release]
- Kubelet 証明書のローテーションに失敗した場合に
Other (Bug, Cleanup or Flake)
-
client-goの証明書マネージャのローテーションによって発行された証明書に付随する中間証明書を保持する機能が得られました。(#88744, @jackkleeman) [SIG API Machinery and Auth]
-
kubectlによって取得されたAADトークンがon-behalf-ofおよびoidcフローと互換性がない問題を修正します。修f正前の
audclaimは、spn:というプリフィックスが付いていましたが、この修正後はspn:プレフィックスは省略されました。(#86412, @weinong) [SIG API Machinery, Auth and Cloud Provider]-
#87507でrevertされ、#87630 でフラグによる挙動の変更になりました。
-
-
EndpointSlicefeature gateをWindowsで有効した場合の問題を修正. (#86016, @robscott) [SIG Auth and Network] -
kubeletでクライアント証明書ローテーションするケースの不具合を修正 (#88079, @liggitt) [SIG API Machinery, Auth and Node]
-
service account token controllerが動いていないクラスターでのFixes service account token admissionのエラーを修正 (#87029, @liggitt) [SIG Auth]
-
serviceaccount-token controllerを動かさない場合(レガシーSA Tokenは使わずboundServiceAccountTokenVolumeのみを使っているような環境)、ServiceAccount AdmissionでPodにSA Tokenがセットされていないと判定されてエラーになる問題があったようです。
-
-
Node Authorizerのindexの再計算についてのパフォーマンス問題を解決 (#87693, @liggitt) [SIG Auth]
-
oidc claimから
spn:プリフィックスが省略されたkubectl azure auth moudleの変更について、既存のAzure AD OIDC が有効になったapi-serverの動作が壊れるため、変更を戻しました。(#87507, @weinong) [SIG API Machinery, Auth and Cloud Provider]-
#86412の変更をrevert
-
-
CSRの署名に対する証明書と秘密鍵のペアについて、kube-apiserverの証明書と秘密鍵のペアと同様にディスクからリロードされるようになります (#86816, @deads2k) [SIG API Machinery, Apps and Auth]
-
audit eventのsourceIPsのリストは常にAPIサーバに直接リクエストを送信したIPで終わるようになります。(#87167, @tallclair) [SIG API Machinery and Auth]
-
リストの最後は常にremoteAddrの値がセットされるようになったようです
-
Dependencies
- N/A