More than 5 years have passed since last update.

Kubernetes 1.18: SIG-Auth の変更内容

kubernetes

Last updated at 2020-04-03Posted at 2020-04-03

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の権限が必要になりました。

Changes by Kind

API Change

New API types/versions:

New API fields:

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:

kube-scheduler:

kube-proxy:

Features graduated to beta:

Features graduated to GA:

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" を指定します。
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 counter exportするようになりました (#84614, @rphillips) [SIG API Machinery, Auth, CLI, Cloud Provider, Cluster Lifecycle, Instrumentation, Node and Release]

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のパフォーマンスを改善 (#87696, @liggitt) [SIG Auth]
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

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up