2.12. ユーザーおよびプロファイルの管理
2.12.1. Red Hat OpenShift Service Mesh メンバーの作成
ServiceMeshMember
リソースは、各ユーザーが Service Mesh プロジェクトまたはメンバーロールに直接アクセスできない場合でも、Red Hat OpenShift Service Mesh の管理者がプロジェクトを Service Mesh に追加するパーミッションを委譲する方法を提供します。プロジェクト管理者にはプロジェクトで ServiceMeshMember
リソースを作成するためのパーミッションが自動的に付与されますが、Service Mesh 管理者が Service Mesh へのアクセスを明示的に付与するまで、これらのプロジェクト管理者はこれを ServiceMeshControlPlane
にポイントすることはできません。管理者は、ユーザーに mesh-user
ユーザーロールを付与してメッシュにアクセスするパーミッションをユーザーに付与できます。この例では、istio-system
が Service Mesh コントロールプレーンプロジェクトの名前となります。
$ oc policy add-role-to-user -n istio-system --role-namespace istio-system mesh-user <user_name>
管理者は Service Mesh コントロールプレーンプロジェクトで mesh user
ロールバインディングを変更し、アクセスが付与されたユーザーおよびグループを指定できます。ServiceMeshMember
は、プロジェクトを、参照する Service Mesh コントロールプレーンプロジェクト内の ServiceMeshMemberRoll
に追加します。
apiVersion: maistra.io/v1 kind: ServiceMeshMember metadata: name: default spec: controlPlaneRef: namespace: istio-system name: basic
mesh-users
ロールバインディングは、管理者が ServiceMeshControlPlane
リソースを作成した後に自動的に作成されます。管理者は以下のコマンドを使用してロールをユーザーに追加できます。
$ oc policy add-role-to-user
管理者は、ServiceMeshControlPlane
リソースを作成する前に、mesh-user
ロールバインディングを作成することもできます。たとえば、管理者は ServiceMeshControlPlane
リソースと同じ oc apply
操作でこれを作成できます。
この例では、alice
のロールバインディングを追加します。
apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: namespace: istio-system name: mesh-users roleRef: apiGroup: rbac.authorization.k8s.io kind: Role name: mesh-user subjects: - apiGroup: rbac.authorization.k8s.io kind: User name: alice
2.12.2. Service Mesh コントロールプレーンプロファイルの作成
ServiceMeshControlPlane
プロファイルを使用すると、再利用可能な設定を作成ができます。各ユーザーは、作成するプロファイルを独自の設定で拡張できます。プロファイルは、他のプロファイルから設定情報を継承することもできます。たとえば、会計チーム用の会計コントロールプレーンとマーケティングチーム用のマーケティングコントロールプレーンを作成できます。開発プロファイルと実稼働テンプレートを作成する場合、マーケティングチームおよび会計チームのメンバーは、チーム固有のカスタマイズで開発および実稼働プロファイルを拡張できます。
ServiceMeshControlPlane
と同じ構文に従う Service Mesh コントロールプレーンのプロファイルを設定する場合、ユーザーは階層的に設定を継承します。Operator は、Red Hat OpenShift Service Mesh のデフォルト設定を使用する default
プロファイルと共に提供されます。
2.12.2.1. ConfigMap の作成
カスタムプロファイルを追加するには、openshift-operators
プロジェクトで smcp-templates
という名前の ConfigMap
を作成する必要があります。Operator コンテナーは ConfigMap
を自動的にマウントします。
前提条件
- Service Mesh Operator がインストールされ、検証されていること。
-
cluster-admin
ロールを持つアカウントがある。(Red Hat OpenShift Dedicated を使用する場合)dedicated-admin
ロールがあるアカウント。 - Operator デプロイメントの場所。
-
OpenShift CLI (
oc
) へのアクセスがある。
手順
-
cluster-admin
として OpenShift Container Platform CLI にログインします。(Red Hat OpenShift Dedicated を使用する場合)dedicated-admin
ロールがあるアカウント。 CLI で以下のコマンドを実行し、
openshift-operators
プロジェクトにsmcp-templates
という名前の ConfigMap を作成し、<profiles-directory>
をローカルディスクのServiceMeshControlPlane
ファイルの場所に置き換えます。$ oc create configmap --from-file=<profiles-directory> smcp-templates -n openshift-operators
ServiceMeshControlPlane
でtemplate
パラメーターを使用して 1 つ以上のテンプレートを指定できます。apiVersion: maistra.io/v2 kind: ServiceMeshControlPlane metadata: name: basic spec: profiles: - default
2.12.2.2. 適切なネットワークポリシーの設定
Service Mesh は Service Mesh コントロールプレーンおよびメンバー namespace にネットワークポリシーを作成し、それらの間のトラフィックを許可します。デプロイする前に、以下の条件を考慮し、OpenShift Container Platform ルートで以前に公開されたサービスメッシュのサービスを確認します。
- Istio が適切に機能するには、サービスメッシュへのトラフィックが常に ingress-gateway を経由する必要があります。
- サービスメッシュ外のサービスは、サービスメッシュにない個別の namespace にデプロイします。
-
サービスメッシュでリストされた namespace 内にデプロイする必要のあるメッシュ以外のサービスでは、それらのデプロイメント
maistra.io/expose-route: "true"
にラベルを付けます。これにより、これらのサービスへの OpenShift Container Platform ルートは依然として機能します。