Amazon Elastic Kubernetes Service で Kiosk にソフトマルチテナンシーをセットアップする

[kube-cluster-admin] 
aws_access_key_id=<cluster-admin-access-key>
aws_secret_access_key=<cluster-admin-secret-key>

注: このガイドのすべてのコマンドは、kubectl コマンドで明示的に指定されていない限り、クラスター管理者として実行されます。クラスター管理 IAM 認証情報を使用するには、AWS_PROFILE 環境変数をオーバーライドします。

Linux または macOS の場合

$export AWS_PROFILE=kube-cluster-admin

Windows の場合

C:\> setx AWS_PROFILE kube-cluster-admin

2.aws-auth ConfigMap を更新して、2 人のユーザーに RBAC アクセスを追加します。

$kubectl edit configmap aws-auth -n kube-system

3.data.mapUsers の下に 2 人のユーザーを追加します。ユーザー ARN は IAM コンソールからコピーできます。

apiVersion: v1
data:
  mapRoles: |
    - groups:
      - system:bootstrappers
      - system:nodes
      rolearn: arn:aws:iam::11122223333:role/EKS-Worker-NodeInstanceRole-UAYZGJSHZK2K
      username: system:node:{{EC2PrivateDNSName}}
  mapUsers: |
    - userarn: arn:aws:iam::11122223333:user/dev
      username: dev
    - userarn: arn:aws:iam::11122223333:user/dba
      username: dba
kind: ConfigMap
metadata:
  name: aws-auth
  namespace: kube-system

注: クラスターを作成する IAM エンティティには、クラスターの RBAC 設定で system:masters アクセス許可が自動的に付与されます。ユーザー dev と dba は、どのグループにも追加されていないため、デフォルトで読み取り専用アクセス許可があります。

偽装ユーザー

Kubernetes では、コマンドラインから user impersonation を介して kubectl コマンドを実行するときに、ユーザーが別のユーザーとして行動することができます。これを行うには、偽装ユーザーに、偽装する属性のタイプ (この場合は user) に対して impersonate アクションを実行する権限が必要です。クラスター管理者はデフォルトで system:masters 権限を持っているため、ユーザー dev と dba に偽装することができます。ユーザーに偽装するには、kubectl コマンドの -as=<username> フラグを使用します。

各テナントに Kiosk アカウントを作成する

1.Node.js アプリケーションのアカウントの定義ファイルを作成します。

node-account.yml 
apiVersion: tenancy.kiosk.sh/v1alpha1
kind: Account
metadata:
  name: node-account
spec:
  subjects:
  - kind: User
    name: dev
    apiGroup: rbac.authorization.k8s.io

アカウントは、アカウントにアクセスできるアカウントユーザーであるサブジェクトを定義します。アカウントユーザーは、Kubernetes ユーザー、グループ、またはサービスアカウントである可能性があります。この場合のアカウントユーザーは dev です。これは以前に aws-auth ConfigMap に追加されています。

2.アカウントを作成する

$kubectl apply -f node-account.yml

3.Redis アプリケーションに対してこの手順を繰り返します。metadata.name を redis-account に、spec.subjects[0].name を dba に更新します。

4.作成したアカウントをクラスター管理者として表示します。

$kubectl get accounts

5.作成したアカウントをユーザー dev として表示します。このユーザーに関連付けられているアカウントのみを表示するアクセス権があります。

$kubectl get accounts --as=dev

アカウントごとに Kiosk スペースを作成する

1.デフォルトでは、クラスター管理者のみがスペースを作成できます。アカウントユーザーがスペースを作成できるようにするには、Kubernetes RBAC ClusterRoleBinding を作成します。ユーザー dev と dba がアカウントにスペースを作成できるようにします。

 cluster-role-binding.yml 
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: kiosk-role-binding
subjects:
- kind: User
  name: dev
  apiGroup: rbac.authorization.k8s.io
- kind: User
  name: dba
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: kiosk-edit
  apiGroup: rbac.authorization.k8s.io

注: kiosk-edit は、Kiosk のグラフがクラスターにインストールされたときに作成された ClusterRole です。これは、ClusterRoleBinding 設定に含まれるサブジェクトによるスペースリソースの作成、更新、削除アクションを許可します。kiosk-edit ロールの完全な設定は、次のコマンドを実行して確認できます。

$kubectl get clusterroles kiosk-edit -n kiosk -o yaml

2.クラスター管理者として ClusterRoleBinding を作成します。

$kubectl apply -f cluster-role-binding.yml

3.Node.js アプリケーション用のスペースを作成します。まず、定義ファイルを作成します。

node-space.yml

apiVersion: tenancy.kiosk.sh/v1alpha1
kind: Space
metadata:
  name: node-space
spec:
  account: node-account

4.ユーザー dev に偽装し、node-account 用のスペースを作成します。

$kubectl apply -f node-space.yml --as=dev

5.Redis アプリケーションに対してこの手順を繰り返します。metadata.name を redis-space に、spec.account を redis-account に更新します。

6.ユーザー dev として redis-account にスペースを作成しようとすると、エラーが発生することに注意してください。

Error from server (Forbidden): error when creating "redis-space.yml": space.tenancy.kiosk.sh "redis-space" is forbidden: User "dev" cannot create resource "spaces" in API group "tenancy.kiosk.sh" at the cluster scope

7.現在のスペースをクラスター管理者として表示します。node-space と redis-space の両方が表示されます。

$kubectl get spaces

8.現在のスペースをユーザー dev として表示します。ユーザー dev が所有するスペースのみにアクセスできることに注意してください。この場合、これは node-space で、node-account に属しています。

$kubectl get spaces --as=dev

9.スペースは Kubernetes 名前空間の仮想表現であるため、コマンドラインで同じ構文を使用できます。たとえば、スペース内のすべてのポッドを一覧表示するには:

$kubectl get pods -n redis-space 

Kiosk アカウントに制限を適用する

アカウントごとのスペース数を制限する

1.アカウントに関連付けることができるスペースの数を制限します。定義ファイル node-account.yml を更新して、スペース制限を追加してみましょう。

node-account.yml

apiVersion: tenancy.kiosk.sh/v1alpha1
kind: Account
metadata:
  name: node-account
spec:
  space:
    limit: 2
  subjects:
  - kind: User
    name: dev
    apiGroup: rbac.authorization.k8s.io

2.変更をクラスター管理者として node-account に適用します。

$kubectl apply -f node-account.yml

現在、node-account は 2 つのスペースのみを持つことができます。3 番目のスペースを作成しようとすると、エラーがスローされます。

Error from server (Forbidden): [...]: space limit of 2 reached for account node-account

3.定義ファイル redis-account.yml を更新して、2 番目のアカウントに同じ制限を適用します。

既存のアカウントにアカウントクォータを適用する

1.アカウントクォータを定義して、アカウントのコンピューティングリソースの制限を定義します。クォータ定義ファイルを作成します。

node-quota.yml

apiVersion: config.kiosk.sh/v1alpha1
kind: AccountQuota
metadata:
  name: default-user-limits
spec:
  account: node-account
  quota:
    hard:
      pods: "2"
      limits.cpu: "4"

2.クラスター管理者としてアカウントクォータを作成します。

$kubectl apply -f node-quota.yml

AccountQuotas は、同じリソースを制限する点で Kubernetes リソースクォータと非常に似ていますが、単一の名前空間に適用されるリソースクォータとは異なり、アカウントのすべてのスペースに制限が適用されるという利点があります。

3.AccountQuota は、クラスター管理者のみが作成できます。アカウントユーザーとしてアカウントクォータを作成しようとすると、エラーが発生します。

$kubectl apply -f node-quota.yml –-as=dev
User "dev" cannot get resource "accountquotas" in API group "config.kiosk.sh" at the cluster scope

4.クラスター管理者として、クラスター全体のアカウントクォータを表示します。

$kubectl get accountquotas

スペース用のテンプレートを作成する

1.Kiosk のテンプレートは、スペースの設計図として機能します。テンプレートは、デフォルトでクラスター管理者が定義および管理します。

2.このスペースにデプロイされたすべてのコンテナに 500 milli CPU の CPU リクエストと 1 CPU の CPU 制限が割り当てられるように制限するテンプレートを作成してみましょう。

template-definition.yml 
apiVersion: config.kiosk.sh/v1alpha1
kind: Template
metadata:
  name: space-template
resources:
  manifests:
  - apiVersion: v1
    kind: LimitRange
    metadata:
      name: container-limit-range
    spec:
      limits:
      - default:
          cpu: 1
        defaultRequest:
          cpu: 0.5
        type: Container

3.テンプレートをクラスター管理者として作成します。

$kubectl apply -f template-definition.yml

4.デフォルトでは、テンプレートはオプションです。テンプレートルールに従うようにスペースの作成を強制するには、これをアカウント設定に追加する必要があります。アカウント内にスペースが作成されたときにテンプレートに従うように redis-account を更新しましょう。

redis-account.yml 
apiVersion: tenancy.kiosk.sh/v1alpha1
kind: Account
metadata:
  name: redis-account
spec:
  space:
    limit: 2
    templateInstances:
    - spec:
        template: space-template
  subjects:
  - kind: User
    name: dba
    apiGroup: rbac.authorization.k8s.io

5.クラスター管理者としてアカウントに変更を適用します。

$kubectl apply -f redis-account.yml

6.redis-account 内にスペースを作成して、これをテストしてみましょう。

redis-mandatory-space.yml 
apiVersion: tenancy.kiosk.sh/v1alpha1
kind: Space
metadata:
  name: redis-mandatory-space
spec:
  account: redis-account

7.クラスター管理者としてスペースを作成します。

$kubectl apply -f redis-mandatory-space.yml

8.スペースが作成されると、LimitRange リソースが作成されたことを確認できます。

$kubectl get limitrange -n redis-mandatory-space

9.テンプレートから作成されたスペースごとに、テンプレートインスタンスが作成されます。テンプレートインスタンスを使用して、テンプレートから作成されたリソースを追跡できます。新しいスペースのインスタンスを表示します。

$kubectl get templateinstances -n redis-mandatory-space

10.テンプレートが適用されていることをテストするには、新しいスペースにテストポッドをデプロイし、制限範囲が適用されているかどうかを確認します。

$kubectl run nginx --image nginx -n redis-mandatory-space --restart=Never

11.ポッド設定を確認し、適用されたリソース制限を確認します。

$kubectl describe pod nginx -n redis-mandatory-space

12.ポッドを削除してセットアップを続行します。

$kubectl delete pod nginx -n redis-mandatory-space

2 つのアカウントでアプリケーションをデプロイする

1.node-account のアカウントクォータが作成されているため、必要なコンピューティングリソースをデプロイの定義ファイルで指定する必要があります。

node-deployment.yml 
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nodejs
  labels:
    app: nodejs
spec:
  replicas: 1
  selector:
    matchLabels:
      app: nodejs
  strategy:
    rollingUpdate:
      maxSurge: 25%
      maxUnavailable: 25%
    type: RollingUpdate
  template:
    metadata:
      labels:
        app: nodejs
    spec:
      containers:
      - image: brentley/ecsdemo-nodejs:latest
        imagePullPolicy: Always
        name: nodejs
        ports:
        - containerPort: 3000
          protocol: TCP
        resources:        
          requests:
            cpu: "1"
          limits:
            cpu: "2"

$kubectl apply -f node-deployment.yml -n node-space --as=dev

2.Redis データストアをユーザー dba として 2 番目のアカウントにデプロイします。

$kubectl create deploy redis --image redis -n redis-space --as=dba

アカウントの分離を確認する

1.アカウントユーザー dev がアクセスできるリソースを確認します。

$kubectl get all -n node-space --as=dev

2.アカウントユーザー dev が redis-space のリソースにアクセスできるかどうかを確認します。多くのエラーが発生するでしょう。

$kubectl get all -n redis-space --as=dev

テナント間のアクセスを確認する

1.node-account のポッドを確認します。ポッドの名前をメモします。

$kubectl get pods -n node-space --as=dev

2.redis-account のポッドを確認します。ポッドの IP アドレスをメモします。

$kubectl get pods -n redis-space -o wide --as=dba

3.2 つのポッド間の接続をテストします。

$kubectl exec -n node-space <pod-name> --as=dev -- ping <ip-address>

テナントはスペースを越えてアクセスできることがわかります。より厳密なセキュリティ制御のために、ネイティブの Kubernetes Network Policies と Pod Security Policies を利用できます。

クリーンアップ

Amazon Elastic Kubernetes Service クラスターを削除して、コストが余計にかかるのを回避しましょう。

まとめ

プラットフォームの進化とこの機能を実装する複雑さのため、最近では、Kubernetes のマルチテナンシーがオープンソースコミュニティのホットトピックになっています。最新情報を取得するには、kubernetes-sigs/multi-tenancy で Kubernetes マルチテナンシー Special Interest Group コミュニティをフォローできます。

この記事では、Kiosk の 1 つの Kubernetes クラスターでソフトマルチテナンシーを簡単に設定できることと、ネイティブの Kubernetes 機能にはない利点があることについて説明しました。アカウントクォータを通じてクラスター全体でリソースを分離し、アカウント、アカウントユーザー、スペースなどのプリミティブを通じてセキュリティ境界を実装しました。