5

を使用kubectlしてkops 1.8

作成されたクライアント証明書 (のフィールドに 文字列として存在する)awsを使用してクラスターをスピンする場合、次の値があります。kopsclient-certificate-data~/.kube/config

    Subject: O=system:masters, CN=kubecfg

私が間違っていない限り、 から始まるrganitazionkubernetes 1.4の値は情報として解釈されます (値に関連付けられた文字列は、いわゆるユーザーです。本質的にそのような概念を持っていないためです)OgroupCNk8s

1system:masters :グループやユーザーに関連付けられている権限を確認するにはどうすればよいkubecfgですか?

  • (上記に関連): 現在使用しているすぐに使用できる認証方法は何ですか? RBAC? どうすればこれを確認できますか?

2 : my のエントリにユーザーが組み込まれて~/.kube/configいないのはなぜですか? kubecfg(むしろ、私のクラスター名を持つユーザーと、という名前の別のユーザーadminですか?)

$ kubectl config view
apiVersion: v1
clusters:
- cluster:
    certificate-authority-data: REDACTED
    server: <server_url>
  name:  <my_cluster_name>
contexts:
- context:
    cluster:  <my_cluster_name>
    user:  <my_cluster_name>
  name:  <my_cluster_name>
current-context:  <my_cluster_name>
kind: Config
preferences: {}
users:
- name: <my_cluster_name>
  user:
    client-certificate-data: REDACTED
    client-key-data: REDACTED
    password: <some_pass>
    username: admin
- name: <my_cluster_name>.local-basic-auth
  user:
    password: <some_pass>
    username: admin

kubectl結局のところ、コマンドを実行するときに、API 呼び出しを実行しているユーザーは?

更新: の値を台無しにしようとしましたが、client-certificate-data取得~/.kube/configしました

エラー: TLS: 秘密鍵が公開鍵と一致しません

x509これは、ベース認証を使用していることを意味すると想定しています(?)

だから私はAPI呼び出しを行っていkubecfgますか？

4

1 に答える 1

1

認証と認可には違いがあることに注意してください。

  • 認証は、ユーザーが本人であることを保証します。Kubernetes API の呼び出しには、常に認証の成功が​​必要です。
  • 承認は、ユーザーが (RBAC を介して) 特定の Kubernetes API リソースにアクセスできるかどうかを決定します。RBAC は、 kube-apiserverサーバーの構成オプションとして明示的に有効にする必要があります。

Kubernetes認証

  • Kubernetes には、トークン、パスワード、OIDC 接続トークン、SSL x509 クライアント証明書など、ユーザーの認証に使用できるメカニズムが多数あります。

  • 上記で発見したように、kopsSSL x509 クライアント証明書が埋め込まれた ~/.kube/config ファイルが自動生成されます。kube-apiserver への REST 呼び出しとともにクライアント証明書を提示すると、kube-apiserver は、クライアント証明書がクラスター認証局 (CA) によって署名されていることを検証することにより、呼び出し元を認証できます。クライアント証明書が適切に署名されている場合、呼び出し元は彼らが言う人です。

  • クライアント証明書の所有者の ID は、SSL x509 クライアント証明書のサブジェクト フィールドによって決定されます。

    • Subject Common Name は、ユーザー ID を決定します。(例: CN=ボブ)
    • サブジェクト組織は、ユーザーのグループを決定します。(例: O=管理者、O=システム:マスター)。複数の組織 (グループ) を指定できることに注意してください。
  • userkubeconfig ファイル内の名前は、kubectl ツールの便宜上、不透明な値のユーザーであることに注意してください。の実際の ID はuser、SSL x509 クライアント証明書またはその他のトークンに埋め込まれているものです。
  • 典型的な Kubernetes デプロイメントのすべてのコンポーネント (kubelet、スケジューラーなど) の各インスタンスには、他のコンポーネントと通信する際の認証に使用される独自の SSL x509 クライアント証明書があることに注意してください。このリンクを参照してください

Kubernetes承認

  • Kubernetes では、RBACロールとロールバインディングによって、特定のユーザーがアクセスできる kube-apiserver REST エンドポイントと、verb許可される操作 ("get"、"list"、"watch"、"create"、"update"、"patch" など) が正確に決定されます。 "、 "消去"）。
  • rolekube-apiserver REST エンドポイントへのアクセスを定義する権限のセットである を作成できます。
  • rolebinding次に、ユーザー ID またはグループ ID を特定の にバインドする を作成できますrole。
  • クラスター全体と名前空間全体の両方のロールバインディングが利用できることに注意してください。
  • 次に例を示します。

    apiVersion: rbac.authorization.k8s.io/v1
    kind: ClusterRole
    metadata:
      name: role-grantor
    rules:
    - apiGroups: ["rbac.authorization.k8s.io"]
      resources: ["rolebindings"]
      verbs: ["create"]
    - apiGroups: ["rbac.authorization.k8s.io"]
      resources: ["clusterroles"]
      verbs: ["bind"]
      resourceNames: ["admin","edit","view"]
    ---
    apiVersion: rbac.authorization.k8s.io/v1
    kind: RoleBinding
    metadata:
      name: role-grantor-binding
      namespace: user-1-namespace
    roleRef:
      apiGroup: rbac.authorization.k8s.io
      kind: ClusterRole
      name: role-grantor
    subjects:
    - apiGroup: rbac.authorization.k8s.io
      kind: User
      name: user-1
  • RBAC は、可能な承認メカニズムの 1 つにすぎません。Kubernetes ABACはあまり人気がありません。

RBAC が有効になっているかどうかの確認

kube-apiserver の起動オプションを確認するだけです。kube-apiserver がポッドとして実行されている場合は、次のように確認できます。

$ kubectl get po kube-apiserver-ubuntu-18 -n kube-system -o name |grep api
pod/kube-apiserver-ubuntu-18

$ kubectl get po kube-apiserver-ubuntu-18 -n kube-system  -o yaml
# THEN SEARCH FOR RBAC
spec:
  containers:
  - command:
    - kube-apiserver
    - --authorization-mode=Node,RBAC
于 2019-01-10T05:13:56.963 に答える