K8s StructuredAuthenticationConfiguration - Qiita
この記事は v1.29でのalphaリリース時点の情報を参考にしています。 将来のリリースではAPIや挙動が変更になる可能性があります。 KEP: https://github.com/kubernetes/enhancements/tree/master/keps/sig-auth/3331-structured-authentication-configuration Doc: https://kubernetes.io/docs/reference/access-authn-authz/authentication/#using-authentication-configuration K8sにおける認証に関する設定をフラグベースから設定ファイルで指定できるようにする機能(フィーチャーゲート)です。設定フラグが機能要求にともなって増えていく問題を解消することがモチベーションだったよう
Kubernetes 1.24: SIG-Auth の変更内容 - Qiita
はじめに このページではKubernetes v1.24におけるSIG-Authに関連する取り組みについて、ChangelogのChanges By Kindの内容から紹介しています。ここに記載されていないものは別のまとめで記載されていると思いますので、 Kubernetes 1.24: 変更点まとめ も合わせて参照してみてください。 v1.24からはLegacyServiceAccountTokenNoAutoGenerationがデフォルトで有効になり、SecretベースのService Account Tokenが作成されなくなります。 詳細はアップグレード時の注意事項を参照してください。 がついた文章は、CHANGELOGの公式内容ではなく筆者の補足です。 Changes by Kind Deprecation client.authentication.k8s.io/v1alph
BoundServiceAccountTokenVolumeを有効にしてみる - Qiita
BoundServiceAccountTokenVolumeとは BoundServiceAccountTokenVolumeはv1.13からalphaの機能として提供されており、FeatureGateで有効にすることができます。これにより、これまでのSecretに書き込まれたトークンをマウントする方式に変わり、宛先や有効期限が指定されたトークンがProjectedVolumeによってPodに渡されるようになります。似たような機能としてTokenRequestProjectionがありますが、BoundServiceAccountTokenVolumeはTokenRequestProjectionで明示的に指定する必要のあったパラメータを動的に設定してくれます。 BoundServiceAccountTokenVolumeはTokenRequest、TokenRequestProjecti
K8s 1.18でalphaになったServiceAccountIssuerDiscoveryについて - Qiita
機能を有効にする K8s 1.18でAlphaの機能として提供されたServiceAccountIssuerDiscoveryは、K8s APIサーバでOIDC DiscoveryやJWKsのエンドポイントを提供する機能です。 有効にするためにはFeatureGateで ServiceAccountIssuerDiscovery=true を設定する必要があります。そのうえで kube-apisever の --service-account-issuer を指定する必要があります。このとき、 service-account-issuer の値はエンドポイントのURLとして使われる(${service-account-issuer}/.well-known/openid-configuration)ため、scheme=httpsを含めた形でissueを指定しておく必要があります。 e.g.
Kubernetes 1.17: SIG-Auth の変更内容 - Qiita
はじめに このページではKubernetes v1.17におけるSIG-Authに関連する取り組みをまとめています。 必ずしもすべての sig/auth ラベルがついた変更についてまとめているわけではありません。ここに記載されていないものは別のまとめで記載されていると思いますので、 Kubernetes 1.17: 変更点まとめ(後日公開) も合わせて参照してみてください。 がついた文章は、CHANGELOGの公式内容ではなく筆者の補足です。 その他の注目機能 (Other notable changes) DockerのcredsStore desktopを利用して出力されたクレデンシャルがSecretから読み込む際に正しくデコードできない問題を修正 (#82148, @bbourbie) docker-credential-desktop によってファイルに出力されたクレデンシャル情報
TokenRequestProjectionについて調べてみた - Qiita
PR: kubernetes/community#1973 今回はKubernetes v1.11でalpha版の機能として追加されたTokenRequestProjectionについて簡単に調べてみました。これはServiceAccountのトークンを動的に発行して、それをProjected Volumeを使ってPodにマウントすることができる機能のようです。 Projected VolumeとはSecrets, ConfigMaps, Downward APIといった複数のVolumeソースを一つのVolumeにまとめてマウントすることができる機能であり、TokenRequestProjectionを有効にするとそのうちの一つとしてServiceAccountのトークンをPodのVolumeにマウントすることができるようになります。 k8s v1.11ではalpha版の機能のため有効に
SPIREのk8s pluginについて - Qiita
昨日はSPIFFEとその参照実装であるSPIREについてのエントリを書きましたが、本日はSPIREのワークロードとしてKubernetesのPodを対象とする場合に利用するKubernetesのworkload attestor pluginの動きを説明します。 Kubernetes workload attestor plugin とは SPIRE-Agentのworkload attestorのプラグインとして動作します。 Worload AttestorとはWorkload APIの呼び出し元の情報からSelector情報を生成するコンポーネントでした。 Kubernetes pluginの場合には呼び出し元Workloadのpidからそのpidで動作するPodのNamespaceとServiceAccountの情報を収集します。つまり、呼び出し元のワークロードが動作するPodに紐づ
SPIFFEとその実装であるSPIREについて - Qiita
はじめに SPIFFEという名前を聞いたことはあるでしょうか。KubernetesのSIG-AUTHなんかの議事録などに目を通している方は最近よく目にするようになっているのでないかと思います。 簡単にまとめてしまえばSPIFFEとはサービス間認証のフレームワークと仕様を定めたものでSPIREはそのひとつの実装になります。 Kubernetesクラスタ内においてはpod間の通信を制限したい場合はPodSecurityPolicyを使ったりすることで実現できますが、podとクラスタ外のサービスの通信を制限したい場合はどうすればいいでしょうか。そういった場合にはSPIFFEなどを使うことで解決するかもしれません。 SPIFFEとは「Secure Production Identity Framework For Everyone」の頭文字を取ったものです。 ではSPIFFEが定義している仕様とは
KubernetesのToken Review API - Qiita
KubernetesのAPIサーバと同じ認証を自前のpodとかでやりたいことがありませんか？ 例えばAPIサーバにアクセスするためのIDトークンで認証しメールアドレスを使いたいとかサービスアカウントで認証したいとか。 そんなときはTokenReview APIを使ってみるといいかもしれません。 これはKubernetesのAPIサーバに対してBearerトークンをリクエストパラメータとして渡すと、APIサーバが有効かどうかを判断して結果を返してくれるAPIです。例えばServiceAccountのトークンや、OIDCを有効にしている場合にはID Tokenなんかを渡すことができます。 v1.7以降ではTokenReview APIには以下のURIでアクセスできます。
kubernetesがサポートする認証方法の全パターンを動かす - Qiita
この記事は、「Kubernetes Advent Calendar 2016」18日目の記事です ここでは Kubernetes がサポートする認証方法全てを手元で試してみたいと思います。 機能の説明は書いてあるが実際の使い方まで詳しく書いておらず、使い方がわからないものがあったりしたのでこれを機に全パターン確認してみます。 また、この記事は kubernetes: 1.4.6 および minikube: v0.13.1 で確認しています。 まずは簡単に kubernetes における認証の流れについておさらいしておきます。 kubernetes においては、ユーザーからコンテナの操作要求(CLIなどを使って)を受け取ると、クラスタを利用可能なユーザーであるかを認証し、利用可能な操作を認可で確認するというのが基本的な認証・認可の流れになります。(+ AdmissionControl もある
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
