Kubernetesの管理が簡単なロールベースアクセス制御(RBAC)について知っておくべきこと #gitlab #kubernetes #k8s
この記事は1年以上前に投稿されました。情報が古い可能性がありますので、ご注意ください。
いまやRBACはデフォルトとなり、ほぼすべてのKubernetesによるデプロイメントに求められています。RBACとは何か、なぜ必要か、そしてどのように使えばよいのかをご紹介します。
リソースへのアクセス管理は、あらゆるインフラストラクチャにおける信頼性、安全性、効率性の確保に役立ちますが、すぐに管理が複雑化する恐れがあります。Kubernetesでは、属性ベースアクセス制御(ABAC)はとても強力な半面、とても複雑です。一方ロールベースアクセス制御(RBAC)はkubectlとKubernetes APIを直接使用することで、パーミッションを簡単に管理できます。この記事ではRBACの始め方および、導入例のベストプラクティスをご紹介します。
RBAC対ABAC
RBACはKubernetes 1.6でベータ版リリースとなり、Kubernetes 1.8で一般公開となりました。Kubernetesの基本的な構成要素であるRBACは、KubernetesのAPIがどのように許可を得て接続するかを制御する、認可メカニズムです。
現在RBACは、管理も理解も複雑なABACよりも好まれる傾向にあります。またABACでは認可ポリシーを変更する際に、SSHおよびルートアクセスが必要です。
リソース管理は、クラスタマスターVMにSSHアクセスする権限を渡さずに、RBACを使用することで代行できます。パーミッションのポリシーはkubectlかKubernetes APIを使用することで設定が可能です。
RBACリソース
RBACを使用することで、ネームスペース限定または全クラスタに対するパーミッション群を使用することで認可を与えることができます。これを行うためには、ネームスペース内で定義するロールと呼ばれる一連のパーミッションを定義します。全クラスタをカバーするロールが必要な場合はClusterRoleとして定義します。
次にロール定義の例を示します:
Role
kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
namespace: default
name: pod-reader
rules:
- apiGroups: [""] # ""はコアAPIグループを指す
resources: ["pods"]
verbs: ["get", "watch", "list"]
Kubernetesの他のリソースのように、ロール定義はkindやapiVersion、そしてmetadataを含み、さらにrulesを追加しています。
rulesキーには、パーミッションをどのように機能させるかを定義します。apiGroup内で、どのリソースを許可するか、また、動詞(create, delete, deletecollection, get, list, patch, update, watchなど)を使用してどのようにアクセス可能とするかなどを指定することができます。apiGroupsキーは、リソースが見つかるAPI内の場所を定義します。リストに空の値を提供する場合、それはコアAPIグループということになります。
ClusterRole
kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
# ClusterRoleはnamespaceを限定しないので"namespace"キーは取り除く
name: secret-reader
rules:
- apiGroups: [""]
resources: ["secrets"]
verbs: ["get", "watch", "list"]
ClusterRole用の定義の主な特徴はネームスペース指定がないことです。ClusterRoleで定義するパーミッションはクラスタ全体に範囲が及ぶからです。ただし、RoleBindingから参照を受けた場合は、RoleBindingのネームスペース内のClusterRoleロールで定義されたネームスペース内のリソースに許可を与えるために、ClusterRoleを使用します。
RoleBindingとClusterRoleBinding
RoleBindingでは、ユーザやユーザリストに対してロールを関連づけることができます。これはロールのパーミッションをユーザに与えるものです。ユーザはsubjectsキー以下に定義し、ロールの関連性はロールの参照(roleRefキー)以下に定義します。例:
RoleBinding:
kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
name: read-pods
namespace: default
subjects:
- kind: User
name: abu
apiGroup: rbac.authorization.k8s.io
roleRef:
kind: Role
name: pod-reader
apiGroup: rbac.authorization.k8s.io
ClusterRoleBinding:
kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1
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
ベストプラクティス
最小権限の原則を適用することは、漏洩と脆弱性を軽減するために極めて重要です。いくつかの必須ベストプラクティスとして、次のようなものがあります:
- アクセス権を与えるリソース、および使用する動詞について明確化しましょう。ワイルドカードを避けましょう。
- 可能な場所ではClusterRoleの代わりにRoleを使用しましょう。
- ユーザが取り組むべき特定のタスクに必要となるパーミッショのみを与え、それを越えたパーミッションは与えないでおきましょう。
- デフォルトのサービスアカウントを使用する代わりに、パーミッションを要求するTillerのようなサービスアカウントを作成し、それを使用しましょう。
GitLab + RBAC
現在、RBACが有効なKubernetesクラスタとGitLabの統合はサポート外になります。GitLabでは、レガシーなABACメカニズム(こちらのドキュメントを参照)を有効にし使用してください。RBACは将来的にサポート対象となります。これはGitLab.comおよび、すべてのセルフホストされたバージョンのGitLabに共通です。
