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/approval
APIのコンシューマは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
の権限が必要になりました。
-
CertificateSigningRequestリソースにsingerNameフィールドが追加されたことにより、利用用途などによってsingerを変更可能になりました。
(
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サーバへの負荷を軽減することもできます。
-
この機能を有効にするとAPIサーバによってOpenID Provider Configuration と JWKS エンドポイントを提供され、
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内の
aud
claimにspn:
プリフィックスがついているかどうかが異なり、Token検証に失敗するようなケースがあるようです。AzureADを使っているコードで複数の同じようなissueがありました。aud
claimにspn:
プリフィックスを付与しないようにするには kubectlのconfigで--auth-provider-arg=config-mode="1"
を指定します。
-
Azureの認証 APIのバージョンによって(?)ID Token内の
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:
-
クライアント証明書に関する2つのメトリクスを追加: (#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 counter
exportするようになりました (#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正前の
aud
claimは、spn:
というプリフィックスが付いていましたが、この修正後はspn:
プレフィックスは省略されました。(#86412, @weinong) [SIG API Machinery, Auth and Cloud Provider]- #87507でrevertされ、#87630 でフラグによる挙動の変更になりました。
EndpointSlice
feature 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