この例の前では、私たちが作成ServiceAccountがバインドされていると、クラスタ管理者は、デフォルトのユーザーは、最高の権威を持っている実際の生産環境、多くの場合、運用、保守要員の異なる事前に割り当てられた異なる権限が必要です。そして、実際の状況に応じてあなたは、読み取り専用に開発者が許可を与えてもよい。このセクションでは、我々は異なるユーザー権限を作成する方法について説明します。
我々が開始する前に、まずkubernetes RABAさんに関するいくつかの基本的な概念を理解しています。
- 役割
役割明示的な許可ルールのセットである唯一の役割は、名前空間で定義することができ、蓄積することができ、それだけ、リソースへのアクセスの単一の名前空間のための権限を付与するために使用することができます。たとえば、私たちは役割ポッド上のデフォルトの名前空間を作成へのアクセス権を持っています：
kind: Role
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
namespace: default
name: pod-reader
rules:
- apiGroups: [""] # "" indicates the core API group
resources: ["pods"]
verbs: ["get", "watch", "list"]- ClusterRole
ClusterRoleが同じ権限の役割の役割コントロールを持っている、違いはClusterRoleは、クラスタレベルで、それがために使用することができます：
クラスタレベルのリソース制御（例えばアクセスノード用）
非リソースベースのエンドポイント（例えば、/ healthzアクセス）
すべての名前空間のリソース制御（例えばポッドなど）
例えば、我々は秘密のクラスタの役割にアクセスするために特定の名前空間の認可または（結合様式に応じて）すべての名前空間を作成するとします。
kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
# "namespace" omitted since ClusterRoles are not namespaced
name: secret-reader
rules:
- apiGroups: [""]
resources: ["secrets"]
verbs: ["get", "watch", "list"]- RoleBinding和ClusterRoleBinding
定義されたアクセス許可の役割をRoloBindingユーザーまたはユーザーのグループに付与することができ、RoleBindingはパーミッションリスト（被験者）のセットが含まれ、リソースタイプの異なる形式もする権限（ユーザー、グループ、サービスアカウント）、RoleBinding FOR Aを付与された権限のリストが含まれています名前空間の認可内、およびClusterRoleBindingは、クラスタ全体の認証に適用されます。
例えば、我々はユーザージェーンに付与されたポッドリーダーの役割の名前空間をデフォルト設定されますので、ユーザのネームスペースの後にデフォルトのアクセス権は、ポッドリーダーを持っています。
# This role binding allows "jane" to read pods in the "default" namespace.
kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
name: read-pods
namespace: default
subjects:
- kind: User
name: jane
apiGroup: rbac.authorization.k8s.io
roleRef:
kind: Role
name: pod-reader
apiGroup: rbac.authorization.k8s.io
RoleBindingもClusterRole現在のユーザー、ユーザーグループ、またはServiceAccount内の名前空間を許可参照することができ、この操作は、クラスタ管理者がクラスタ全体でいくつかの一般的ClusterRoleを定義し、参照するために異なる名前空間RoleBindingを使用することができ
たとえば、次のようRoleBindingはClusterRoleを引用し、このClusterRoleは、クラスタ全体の秘密へのアクセス権を持っている。しかし、デイブ開発スペースの秘密にアクセスすることが許可されたユーザーのみ（RoleBindingは開発中の名前空間を定義しているため）
# This role binding allows "dave" to read secrets in the "development" namespace.
kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
name: read-secrets
namespace: development # This only grants permissions within the "development" namespace.
subjects:
- kind: User
name: dave
apiGroup: rbac.authorization.k8s.io
roleRef:
kind: ClusterRole
name: secret-reader
apiGroup: rbac.authorization.k8s.ioClusterRoleBindingは、すべての名前空間リソース許可クラスタ全体の使用を許可することができる。ClusterRoleBinding次の例では、グループ・マネージャ内のすべてのユーザーが名前空間の全てに秘密へのアクセスを許可示します
# This cluster role binding allows anyone in the "manager" group to read secrets in any namespace.
kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
name: read-secrets-global
subjects:
- kind: Group
name: manager
apiGroup: rbac.authorization.k8s.io
roleRef:
kind: ClusterRole
name: secret-reader
apiGroup: rbac.authorization.k8s.ioユーザー権利のダッシュボードを制限
上記の理論的根拠では、我々はそのような私たちは、以下の機能を実現するためにあるようなユーザのための特定のアクセス権を割り当て、新しいユーザーを作成することができるので。
新しいユーザータイラー（tyler.yml）を追加します。
ユーザーは唯一のネームスペースポッドの展開、次のシステムをKUBEし、管理することができます
まずは、作成してみましょう
ServiceAccount
タイラー-n-KUBEシステムを作成するためのkubectl
- その後、我々は新しい役割の役割・タイラー（ロールtyler.yml）を作成
kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
namespace: kube-system
name: role-tyler
rules:
- apiGroups: [""]
resources: ["pods"]
verbs: ["get", "watch", "list"]
- apiGroups: ["extensions", "apps"]
resources: ["deployments"]
verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]
管理権限ポッドと展開を：上記のルールが支配することに注意してください。
その後、我々は、ユーザーが権限の役割を持っているので、ロールタイラータイラーの役割にユーザーを結合し、役割バインディングを作成します。
ファイルを作成するコマンドを実行して、
$ kubect create -f tyler.yml
$ kubect create -f role-tyler.yml簡単なバージョン管理、より複雑な振り付け権はない私たちは役割を作成するためのコマンドを使用していて、既存の役割が結合、この方法は、簡単で行うことが迅速な、しかし複雑な振り付けの操作権限として、ここでは簡単ではありません前の1 YMLは、宣言的な方法を使用して作成をお勧めします。
トークンを使用してログインを作成します。
我々は、ユーザーのための秘密の名前を言ってきたよう用户名-token-随机字符串なフォーマットを。我々が使用できるkubectl describe secret secret名称 -n=kube-system秘密を表示する方法を、次にあなたが着陸できるダッシュボードのランディングページをトークンにトークンをコピーしてください。