kubernetes Authenticating(認証)

4982 ワード
kubetnetes

kubernetesユーザーシステム


すべてのKubernetesクラスタには、Kubernetesによって管理されるサービスアカウントと一般ユーザーの2種類のユーザーがあります.
一般ユーザーは、外部の独立したサービスによって管理されます.管理者は、Keystoneやユーザー名、パスワードリストなどのファイルを格納する秘密鍵を配布します.通常のユーザーはAPIコールでクラスタに追加できません.
逆に、サービスアカウントはKubernetes APIによって管理されるユーザである.これらは、特定のネームスペースにバインドされ、APIサーバによって自動的に作成されるか、またはAPIコールによって手動で作成されます.サービスアカウントは、コンテナにインストールされた秘密として格納された一連の証明書にバインドされ、クラスタ内のプロセスがKubernetes APIと対話できるようにします.

kubernetes認証ポリシー


Kubernetesは、クライアント証明書、bearer tokens、認証エージェントまたはHTTP基本認証を使用して、認証プラグインを介してAPI要求を認証します.APIサーバにHTTPリクエストを発行するため、プラグインは次の属性をリクエストに関連付けようとします.
≪ユーザー名｜Username｜oem_src≫:エンド・ユーザーを識別する文字列.一般的な値はkube-adminまたは[email protected]. UID:エンドユーザーを識別し、ユーザー名よりも一貫性と一意の文字列を試行します.≪グループ｜Group｜ldap≫:一般的なユーザーのグループにユーザーを関連付ける文字列のグループ.追加フィールド:追加情報を含む文字列リストの文字列マッピング権限者が役に立つ場合があります.
X 509 Client Certsクライアント証明書認証は、--client-ca-file = SOMEFILEオプションをAPIサーバに渡すことによって有効になります.参照されるファイルには、APIサーバに提示されたクライアント証明書を検証するための1つ以上の証明書発行機関が含まれている必要があります.クライアント証明書を指定して検証する場合は、トピックの共通名を要求されたユーザー名として使用します.Kubernetes 1.4から、クライアント証明書は、証明書の組織フィールドを使用して、ユーザのグループメンバーシップを示すこともできる.ユーザーに複数のグループメンバーシップを含めるには、証明書に複数の組織フィールドを含めます.たとえば
openssl req -new -key jbeda.pem -out jbeda-csr.pem -subj "/CN=jbeda/O=app1/O=app2"
//       jbeda-csr.pem  ,       jbeda      ，         app1 app2

Static Token File
コマンドラインにおいて--token-auth-file = SOMEFILEオプションが提供されると、APIサーバは、ファイルからベアラトークンを読み出す.現在、トークンは無期限に継続されており、APIサーバを再起動することなくトークンリストを変更できます.
トークンファイルは、少なくとも3列のcsvファイルです.トークン、ユーザー名、ユーザーuid、およびオプションのグループ名です.複数のグループがある場合は、列に二重引用符を使用する必要があります.たとえば、
token,user,uid,"group1,group2,group3"

この認証ポリシーは、HTTPのHEADERSに格納されている限り、例えば
Authorization: Bearer 31ada4fd-adec-460c-809a-9e56ceb75269

Bootstrap Tokensは、新しいクラスタの簡単なブートを可能にするために、Kubernetesは、Bootstrap Tokenという動的管理Bearerタグタイプを含む.これらのトークンは、kube-systemネーミングスペースに秘密として格納され、そこで動的に管理および作成することができる.コントローラマネージャにはTokenCleanerコントローラがあり、ブートトークンの有効期限が切れたときにブートトークンを削除できます.このトークンは、正規表現[a-z0-9]{6}.[a-z0-9]{16}に適合し、2つの部分からtoken IDおよびtoken secretを構成しなければならない.この方法も、例えば、HEADERSに置かれる.
Authorization: Bearer 781292.db7bc3a58fc5f07e

必要条件の使用
  • api-server起動パラメータプラス--experimental-bootstrap-token-auth
  • Controller Manager起動パラメータに--controllers=*,tokencleaner
    • を追加する.
    Static Password Fileこの認証ポリシーを有効にする方法--basic-auth-file=SOMEFILEで、パスワードを有効にするとcvsファイルであることを変更できません.構成:password, user name, user id
    password,user,uid,"group1,group2,group3"

    使用
    Authorization:Basic BASE64ENCODED(USER:PASSWORD)

    Service Account Tokens
    サービスアカウントは、署名されたベアラトークンを使用して、リクエストの自動有効化を検証するベリファイアです.このプラグインには2つのオプションフラグが必要です.--service-account-key-fileは、チケット所有者トークンに署名するためのPEM符号化鍵のファイルを含む.指定されていない場合、APIサーバのTLS秘密鍵が使用されます.--service-account-lookupがオンの場合、APIから削除されるトークンは取り消される.
    サービスアカウントは、通常、APIサーバによって自動的に作成され、ServiceAccountアクセスコントローラを介してクラスタ内で実行されるPodに関連付けられます.ベアラトークンは周知の場所にインストールされ、クラスタ内のプロセスがAPIサーバと通信することを可能にする.アカウントは、PodSpecのserviceAccountNameフィールドを使用してPodに明示的に関連付けることができる.
    apiVersion: apps/v1 # this apiVersion is relevant as of Kubernetes 1.9
kind: Deployment
metadata:
  name: nginx-deployment
  namespace: default
spec:
  replicas: 3
  template:
    metadata:
    # ...
    spec:
      serviceAccountName: bob-the-bot
      containers:
      - name: nginx
        image: nginx:1.7.9
    kubectl create serviceaccount (NAME)でserviceaccountを作成できます
    サービスアカウントは、ユーザー名システムを使用して認証されます.serviceaccount：（NAMESPACE）:( SERVICEACCOUNT）で、グループシステム:serviceaccountsおよびsystem：serviceaccounts：（NAMESPACE）に割り当てられます.
    endさらに詳しくはAuthenticatingリファレンスAuthenticatingへ
    CSSメモ
    アップロード画像のサイズスケールの調整