本リリースでは、以下の機能は テクノロジープレビュー機能 です。

Red Hat Advanced Cluster Management をバージョン 2.2.x から 2.3.1 にアップグレードすると、アップグレードに失敗します。Multiclusterhub ステータスは、コンポーネントエラーメッセージに failed to download chart from helm repo を表示します。no endpoints available for service "ocm-webhook" 問題を参照するエラーも表示される場合があります。

ハブクラスターで、Red Hat Advanced Cluster Management がインストールされている namespace で以下のコマンドを実行し、デプロイメントを再起動してバージョン 2.3.1 にアップグレードします。

oc delete deploy ocm-proxyserver ocm-controller ocm-webhook multiclusterhub-repo

注記: エラーは解決しますが、調整プロセスはすぐに開始されない可能性があります。これは、製品がインストールされているのと同じ namespace で multicluster-operators-standalone-subscription を再起動して高速化できます。

Red Hat Advanced Cluster Management をバージョン 2.3.0 から 2.3.1 にアップグレードする場合、マネージドクラスターの open-cluster-management-agent-addon namespace の klusterlet-addon-operator Pod は ImagePullBackOff エラーを返します。

この問題を解決するには、ハブクラスターで以下の手順を実行し、バージョン 2.3.1 にアップグレードします。

Red Hat Advanced Cluster Management バージョン 2.3.1 を実行しています。

Openshift Container Platform クラスターがアップグレードの段階に入ると、クラスター Pod は再起動され、クラスターのステータスが 1-5 分ほど、upgrade failed のままになることがあります。この動作は想定されており、数分後に解決されます。

Cluster ページに表示されているノード数と Search の結果で差異が生じる場合があります。

LDAP ユーザー名は、大文字と小文字が区別されます。LDAP ディレクトリーで設定したものと全く同じ名前を使用する必要があります。

この製品は、Linux、macOS、および Windows で利用可能な Mozilla Firefox 74.0 または最新バージョンをサポートします。コンソールの互換性を最適化するため、最新版にアップグレードしてください。

コンソールおよび Visual Web ターミナルから、値に空白が含まれている場合には検索できません。

kubeadmin でログインしており、ドロップダウンメニューから Log out オプションをクリックすると、コンソールはログイン画面に戻りますが、/logout URL のブラウザータブが開きます。このページは空白であるため、コンソールに影響を与えずにタブを閉じることができます。

セキュリティー上の理由で、検索時にマネージドクラスターにあるシークレットの内容は表示されません。コンソールからシークレットを検索すると、以下のエラーメッセージが表示される場合があります。

Unable to load resource data - Check to make sure the cluster hosting this resource is online

searchcustomization CR でストレージサイズを更新する場合、PVC 設定は変更されません。ストレージサイズを更新する必要がある場合は、以下のコマンドで PVC (<storageclassname>-search-redisgraph-0) を更新します。

oc edit pvc <storageclassname>-search-redisgraph-0

可観測性エンドポイントオペレーターは、MultiClusterObservability CustomResource (CR) へのデプロイにプルシークレットを作成したにも拘らず、open-cluster-management-observability namespace にプルシークレットがない場合に問題が発生します。新しいクラスターをインポートする場合、または Red Hat Advanced Cluster Management で作成された Hive クラスターをインポートする場合は、マネージドクラスターにプルイメージシークレットを手動で作成する必要があります。

詳細は、「可観測性の有効化」を参照してください。

Red Hat Advanced Cluster Management の可観測性は、組み込みダッシュボードで、ROKS クラスターのデータが表示されないパネルがあります。これは、ROKS が、管理対象サーバーからの API サーバーメトリクスを公開しないためです。以下の Grafana ダッシュボードには、Kubernetes/API server、Kubernetes/Compute Resources/Workload、Kubernetes/Compute Resources/Namespace(Workload) の ROKS クラスターをサポートしないパネルが含まれます。

ROKS クラスターの場合に、Red Hat Advanced Cluster Management の可観測性のダッシュボードの etcd パネルでデータが表示されません。

クラスターを 1000 台管理するハブクラスターで検索が無効になっている場合に、search-collector Pod の CPU 使用率のレベルが通常よりも高くなります。4 日間の CPU 使用率は約 2.148Mi です。search-collector のレプリカ数を 0 に減して、メモリー使用量を減らすことができます。

まれに、検索 Pod は証明書の変更後に自動的に再デプロイされない場合があります。これにより、サービス Pod 全体で証明書が一致しなくなるため、転送レイヤーセキュリティー (TLS) ハンドシェイクが失敗します。この問題を修正するには、検索 Pod を再起動して証明書をリセットします。

可観測性が有効化されている 2.3.2 にアップグレードする場合は、可観測性アドオンが準備状態にないため、一部のクラスターのパフォーマンスが低下します。multicluster-observability-operator Pod を再起動するには、以下のコマンドを実行します。

oc delete po multicluster-observability-operator -n open-cluster-management

可観測性 Pod が再作成されます。

まれに、非接続環境では、Pod がイメージをプルできないため、可観測性 StatefulSet の一部の Pod が次のステータス ErrPullImage でスタックします。これらの Pod で定義されたイメージは、関連する StatefulSets で定義されるイメージとは異なります。この問題を修正するには、誤ったイメージを使用する Pod を削除する必要があります。Pod は自動的に再起動し、正しいイメージを使用する必要があります。

Observability receive Pod では、以下のエラーをレポートします。

Error on ingesting out-of-order samples

このエラーメッセージは、マネージドクラスターがメトリック収集間隔中に送信した時系列データが、以前の収集間隔中に送信した時系列データよりも古いことを意味します。この問題が発生した場合には、データは Thanos レシーバーによって破棄され、Grafana ダッシュボードに表示されるデータにギャップが生じる場合があります。エラーが頻繁に発生する場合は、メトリクスコレクションの間隔をより大きい値に増やすことが推奨されます。たとえば、間隔を 60 秒に増やすことができます。

この問題は、時系列の間隔が 30 秒などの低い値に設定されている場合にのみ見られます。メトリクス収集の間隔がデフォルト値の 300 秒に設定されている場合には、この問題は発生しません。

マネージドクラスターを削除すると、その マニフェスト 作業リソースが削除されないため、マネージドクラスターの namespace が終了状態のままになる可能性があります。以下のコマンドを実行して残りの manifestworks リソースを削除し、namespace を削除します。

kubectl -n <managed-cluster-namespace> get manifestworks | grep -v NAME | awk '{print $1}' | xargs kubectl -n <managed-cluster-namespace> patch manifestworks -p '{"metadata":{"finalizers": []}}' --type=merge

クラスターのデプロイ時に無効な情報が提供されると、起動できなくても 作成 ステータスが uncreatable クラスターステータスに表示されます。install-config ファイルで指定されたリージョンに一致しないデプロイメントに指定されたリージョンなどの無効な情報により、以下のエラーが Hive プロビジョニング Pod に追加されます。

provision failed, requirements not met

Red Hat Advanced Cluster Management バージョン 2.3 では、クラスター 作成 のステータスを引き続き報告しますが、無効な情報によりクラスターの作成が妨げられます。

Infrastructure Operator を使用して OpenShift Container Platform クラスターを作成する場合、ISO イメージのファイル名は長すぎる可能性があります。長いイメージ名により、イメージのプロビジョニングとクラスターのプロビジョニングが失敗します。この問題が生じるかどうかを確認するには、以下の手順を実行します。

この問題が発生する場合、これは通常 OpenShift Container Platform の以下のバージョンで発生します。インフラストラクチャー Operator がイメージサービスを使用していないためです。

このエラーを回避するには、OpenShift Container Platform をバージョン 4.8.18 以降にアップグレードしてください。

Google Cloud Platform(GCP)でのクラスターのプロビジョニングを試みると、以下のエラーを出して失敗する可能性があります。

Cluster initialization failed because one or more operators are not functioning properly.
The cluster should be accessible for troubleshooting as detailed in the documentation linked below,
https://docs.openshift.com/container-platform/latest/support/troubleshooting/troubleshooting-installations.html
The 'wait-for install-complete' subcommand can then be used to continue the installation

GCP プロジェクトで ネットワークセキュリティー API を有効にして、このエラーを回避することができます。これにより、クラスターのインストールを継続できます。

local-cluster という名前のクラスターを別の名前でクラスターとして再インポートしようとすると、local-cluster のステータスが「offline」を表示します。

このケースから回復するには、以下の手順を行います。

クラスターの作成の試行中に無効な Ansible ジョブテンプレート名を指定しても、クラスターはコンソールの複数の異なる画面に異なるステータスを表示します。Infrastructure > Clusters > Managed clusters を選択してステータスを表示すると、Failed ステータスが表示されます。Infrastructure > Clusters > Cluster sets > <your_cluster_set_name> > Managed clusters を選択すると、ステータスは Creating で停止します。今回の場合は、正しいステータスが Failed となっています。クラスターを再度作成して、正しい Ansible テンプレート名を入力できます。

local-cluster をデタッチした後に、local-cluster が自動的に再インポートされないことがあります。これが発生すると、ローカルクラスターは Red Hat Advanced Cluster Management コンソールに Pending Import の一定のステータスを表示します。

local-cluster を再インポートするには、以下の手順を実行します。

Red Hat Advanced Cluster Management コンソールで作成したマネージドクラスターを削除すると、マネージドクラスターの clusterdeployment は終了状態のままになる可能性があります。この問題を回避するには、この clusterdeployment を削除するには、クラスターの agentclusterinstall リソースを編集して agentclusterinstall.agent-install.openshift.io/ai-deprovision ファイナライザーを手動で削除します。

マネージドクラスターの namespace を手動で削除できません。マネージドクラスター namespace は、マネージドクラスターの割り当てを解除した後に自動的に削除されます。マネージドクラスターの割り当てを解除する前に手動でマネージドクラスター namespace を削除する場合は、マネージドクラスターの削除後にマネージドクラスターに継続的な終了ステータスが表示されます。この終了マネージドクラスターを削除するには、割り当てを解除したマネージドクラスターからファイナライザーを手動で削除します。

ハブクラスターのアーキテクチャーとは異なるアーキテクチャーでマネージドクラスターを作成するには、両方のアーキテクチャーのファイルが含まれるリリースイメージ (ClusterImageSet) を作成する必要があります。たとえば、ppc64le ハブクラスターから x86_64 クラスターを作成することはできません。OpenShift Container Platform リリースレジストリーは、マルチアーキテクチャーイメージマニフェストを提供しないため、クラスターの作成に失敗します。

この問題を回避するには、以下の手順を実行します。

作成プロセスでは、マージされたリリースイメージを使用してクラスターを作成します。

クラスターのラベルを更新して新規クラスターセットに適用し、クラスターまたはクラスターセットを別のクラスターセットに再割当てできません。クラスターまたはクラスターセットを移動するには、Red Hat Advanced Cluster Management コンソールを使用して、クラスターセットからクラスター/クラスターセットを削除します。クラスターセットから削除した後に、コンソールを使用して新規クラスターセットに追加します。

Ansible Automation Platform Resource Operator では ppc64le イメージが提供されないので、IBM Power で Red Hat Advanced Cluster Management for Kubernetes ハブクラスターが実行されている場合には、Ansible Tower 統合を使用できません。

Red Hat Advanced Cluster Management をバージョン 2.3 にアップグレードすると、アップグレード前に Red Hat Advanced Cluster Management で作成して管理されていたマネージドクラスターの認証情報シークレットが変更できなくなります。

ハブクラスターが OpenShift Container Platform バージョン 4.8 でホストされる場合は、Red Hat Advanced Cluster Management ハブクラスターを使用してベアメタルマネージドクラスターを作成することはできません。

マネージドクラスターをデタッチすると、Create resources ページが一時的に破損し、以下のエラーが表示される可能性があります。

Error occurred while retrieving clusters info. Not found.

namespace が自動的に削除されるまで待ちます。待機時間は、クラスターのデタッチ後、5-10 分ほどです。または、namespace が終了状態のままの場合、namespace を手動で削除する必要があります。ページに戻り、エラーが解決されたかどうかを確認します。

ハブクラスターおよびマネージドクラスターの時間が同期されず、コンソールで unknown と表示され、最数的に、数分以内に available と表示されます。Red Hat OpenShift Container Platform ハブクラスターの時間が正しく設定されていることを確認します。「ノードのカスタマイズ」を参照してください。

IBM OpenShift Container Platform Kubernetes Service バージョン 3.11 のクラスターをインポートすることはできません。IBM OpenShift Kubernetes Service の 3.11 よりも後のバージョンはサポート対象です。

クラウドプロバイダーのアクセスキーを変更しても、プロビジョニングされたクラスターのアクセスキーは、namespace で更新されません。これは、マネージドクラスターがホストされ、マネージドクラスターの削除を試みるクラウドプロバイダーで認証情報の有効期限が切れる場合に必要です。このような場合は、以下のコマンドを実行して、クラウドプロバイダーでアクセスキーを更新します。

management-ingress サービスを実行するには、root でログインする必要があります。

検索で、ハブクラスターのリソース用の RBAC がマッピングされます。Red Hat Advanced Cluster Management のユーザー RBAC 設定によっては、マネージドクラスターからのノードデータが表示されない場合があります。また検索の結果は、クラスターの Nodes ページに表示される内容と異なる場合があります。

マネージドクラスターを破棄してから 1 時間経過してもステータスが Destroying のままで、クラスターが破棄されません。この問題を解決するには、以下の手順を実行します。

Red Hat Advanced Cluster Management コンソールを使用して、OpenShift Container Platform Dedicated 環境にある OpenShift Container Platform マネージドクラスターをアップグレードすることはできません。

特定のマネージドクラスターにある特定のリソースの検索詳細ページで問題が発生する可能性があります。マネージドクラスターの work-manager アドオンが Available ステータスであることを確認してから検索する必要があります。

Red Hat Advanced Cluster Management との Argo CD の統合は、利用可能な ppc64le イメージがないため、IBM Power で実行されている Red Hat Advanced Cluster Management ハブクラスターでは機能しません。

Red Hat OpenShift Container Platform および OpenShift Container Platform 以外のクラスターの両方は Pod ログ機能をサポートしますが、OpenShift Container Platform 以外のクラスターでは、この機能を使用できるように LoadBalancer が有効にされている必要があります。LoadBalancer を有効にするには、以下の手順を実行します。

LoadBalancer のタイプについての詳細は、Kubernetes のドキュメント のService ページを参照してください。

アプリケーション テーブル の Search application by row アクションボタンをクリックすると、Search ページに移動します。これは、Application details ページから Search リソースから受け取ることができるものと同じ事前設定フィルターとは異なる結果になります。

リンクをクリックすると、Argo CD アプリケーションの アプリケーションの詳細ページからすべての関連アプリケーションを検索 すると、検索ページは無効な事前設定フィルターを返します。

検索コンソールでディレクトリーフィルターを削除して、この問題を解決することができます。

Create application エディターを使用して Red Hat Advanced Cluster Management アプリケーションを作成すると、ハブクラスターがプロキシーの背後にあるときに、Git リポジトリーに以下のエラーが発生する可能性があります。

The connection to the Git repository failed.Cannot get branches.

代わりに Git リポジトリーの URL に移動して、ブランチ情報を取得できます。ブランチの入力時に、アプリケーションは正しくデプロイされます。

Argo アプリケーションのクラスターノード検索リンクは name:undefined を返す可能性があります。

Argo アプリケーションのクラスターノードの詳細から、検索リンクの Launch resource in search をクリックすると、検索フィルターに name:undefined が含まれる場合があります。

このエラーを解決するには、undefined 値をクラスターノードの詳細のクラスター名に置き換えます。

クラスターが複数のサブスクリプションを使用している場合は、クラスターが アプリケーショントポロジー で適切にグループされない可能性があります。

複数のサブスクリプションでアプリケーションをデプロイする場合、すべてのサブスクリプションビュー がクラスターノードを適切にグループ化していない可能性があります。

たとえば、Helm リポジトリーと Git リポジトリーの組み合わせを含む複数のサブスクリプションでアプリケーションをデプロイする場合、すべてのサブスクリプション ビューは Helm サブスクリプション内のリソースに対するステータスを適切に表示しません。

代わりに、個別のサブスクリプションビューからトポロジーを表示して、正しいクラスターノードをグループ化する情報を表示します。

サブスクリプションドロップダウンメニューを使用してアプリケーションサブスクリプションを切り替えると、アプリケーショントポロジーが失敗する可能性があります。

この問題を解決するか、別のサブスクリプションへの切り替えを試みます。もしくは、ブラウザーを更新してトポロジー表示の更新を確認します。

Ansible フックのスタンドアロンモードはサポートされていません。サブスクリプションを使用してハブクラスターに Ansible フックをデプロイするには、次のサブスクリプション YAML を使用できます。

apiVersion: apps.open-cluster-management.io/v1
kind: Subscription
metadata:
  name: sub-rhacm-gitops-demo
  namespace: hello-openshift
annotations:
  apps.open-cluster-management.io/github-path: myapp
  apps.open-cluster-management.io/github-branch: master
spec:
  hooksecretref:
      name: toweraccess
  channel: rhacm-gitops-demo/ch-rhacm-gitops-demo
  placement:
     local: true

ただし、この設定では spec.placement.local:true ではサブスクリプションが standalone モードで実行されているので、Ansible インストールが作成されない可能性があります。ハブモードでサブスクリプションを作成する必要があります。

両方を適用すると、Ansible インスタンスがハブクラスターに作成されているのが表示されるはずです。

アプリケーションの作成または編集時に Deploy on local cluster を選択すると、アプリケーショントポロジーが正しく表示されません。Deploy on local cluster は、ハブクラスターにリソースをデプロイして local cluster として管理できるようにするオプションですが、今回のリリースではベストプラクティスではありません。

この問題を解決するには、以下の手順を参照してください。

namespace チャネルにサブスクライブして、チャネル、シークレット、ConfigMap、または配置ルールなどの他の関連リソースを修正した後にサブスクリプションの状態が FAILED のままになると、namespace サブスクリプションの調整が継続的に行われなくなります。

サブスクリプションの調整を強制的に行い、FAILED の状態から抜けるには、以下の手順を完了してください。

oc label subscriptions.apps.open-cluster-management.io the_subscription_name reconcile=true

Editor ロールで実行するユーザーは、アプリケーションで read または update の権限のみが割り当てられているはずにも拘らず、誤ってアプリケーションの create および delete の操作ができてしまいます。OpenShift Container Platform Operator Lifecycle Manager のデフォルト設定により、当製品の設定が変更されてしまいます。この問題を回避するには、以下の手順を参照してください。

Editor ロールで実行するユーザーは、配置ルールで read または update の権限のみが割り当てられているはずにも拘らず、誤って create および delete の操作もできてしまいます。OpenShift Container Platform Operator Lifecycle Manager のデフォルト設定により、当製品の設定が変更されてしまいます。この問題を回避するには、以下の手順を参照してください。

配置ルールの更新後にアプリケーションがデプロイされない場合には、klusterlet-addon-appmgr Pod が実行されていることを確認します。サブスクリプションコンテナーである klusterlet-addon-appmgr は、エンドポイントクラスターで実行する必要があります。

oc get pods -n open-cluster-management-agent-addon を実行して確認します。

また、コンソールで kind:pod cluster:yourcluster を検索し、klusterlet-addon-appmgr が実行中であることを確認できます。

検証できない場合は、もう一度、クラスターのインポートを試行して検証を行います。

Red Hat OpenShift Container Platform SCC に関する説明は、「Security Context Constraints (SCC) の管理」を参照してください。これは、マネージドクラスターで必要な追加の設定です。

デプロイメントごとにセキュリティーコンテキストとサービスアカウントが異なります。サブスクリプション Operator は SCC を自動的に作成できず、管理者が Pod のパーミッションを制御します。Security Context Constraints (SCC) CR は、関連のあるサービスアカウントに適切なパーミッションを有効化して、デフォルトではない namespace で Pod を作成する必要があります。

お使いの namespace で SCC CR を手動で作成するには、以下を実行します。

同じ namespace に複数のチャネルを作成すると、ハブクラスターでエラーが発生する可能性があります。

たとえば、namespace charts-v1 は、Helm タイプのチャネルとしてインストーラーで使用するので、charts-v1 に追加のチャネルを作成します。一意の namespace でチャネルを作成するようにしてください。すべてのチャネルには個別の namespace が必要ですが、GitHub チャネルは例外で、別 GitHub のチャネルと namespace を共有できます。

Ansible Automation Platform（早期アクセス）2.0.0 をインストールすると、AnsibleJobs の実行に失敗します。Red Hat Advanced Cluster Management で prehook および posthook AnsibleJobs を送信するには、Ansible Automation Platform Resource Operator 0.1.1 を使用します。

アプリケーション名は 37 文字を超えることができません。この数を超えた場合、アプリケーションのデプロイメント時に以下のエラーが表示されます。

status:
  phase: PropagationFailed
  reason: 'Deployable.apps.open-cluster-management.io "_long_lengthy_name_" is invalid: metadata.labels: Invalid value: "_long_lengthy_name_": must be no more than 63 characters/n'

コンソールのさまざまな アプリケーション の表に対する以下の制限を確認してください。

OpenShift Container Platform 4.8 では、終了したリソースの TTL コントローラーはデフォルトで有効になります。つまり、ジョブが毎時削除されます。このジョブクリーンアップにより、Ansible Automation Platform Resource Operator は関連付けられた自動化を再実行します。この自動化は、ポリシーフレームワークで作成された AnsibleJob リソースの既存の詳細を使用して再度実行されます。提供された詳細には、以前特定した違反が含まれる可能性があります。これは、繰り返している違反として誤って表示される可能性があります。ジョブをクリーンアップするコントローラーを無効にして、重複した違反を防ぐことができます。ジョブをクリーンアップするコントローラーを無効にするには、以下の手順を行います。

ポリシー PlacementRule を matchExpressions から matchLabels に更新する場合、古い matchExpression は削除されません。

以下の例は、最初のサンプルの matchExpressions が 2 つ目のサンプルで matchLabels に変更されていますが、matchExpressions は削除されません。

apiVersion: apps.open-cluster-management.io/v1
kind: PlacementRule
metadata:
  name: placement-policy-etcdencryption
spec:
  clusterConditions:
  - status: "True"
    type: ManagedClusterConditionAvailable
  clusterSelector:
    matchExpressions:
      - {key: environment, operator: In, values: ["test"]}

spec:
  clusterConditions:
  - status: "True"
    type: ManagedClusterConditionAvailable
  clusterSelector:
    matchExpressions: []
    matchLabel: {}

指定の ClusterRole に対するパーミッションがあるユーザー数を決定すると、IAM ポリシーコントローラーは Kubernetes User リソースのみをチェックし、Kubernetes Group リソースのユーザーを考慮しません。

外部アイデンティティープロバイダーを使用して Red Hat Advanced Cluster Management にログインする場合は、Red Hat Advanced Cluster Management からログアウトできない可能性があります。これは、Red Hat Advanced Cluster Management に IBM Cloud および Keycloak をアイデンティティープロバイダーとしてインストールして使用する場合に発生します。

Red Hat Advanced Cluster Management からログアウトするには、外部アイデンティティープロバイダーからログアウトしておく必要があります。

open-cluster-management:cluster-manager-admin へのクラスター全体のロールバインディングを持つユーザーは自動化ポリシーを作成できません。この問題を修正するには、ロールを自動化ポリシーに手動で追加する必要があります。

クラスターロール(ClusterRole)を作成または更新して、Ansible リソースの cluster-manager-admin ロールにルールを追加します。YAML は以下のファイルのようになります。

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: add-ansible-rules
  labels:
    rbac.authorization.k8s.io/aggregate-to-ocm-cluster-manager-admin: "true"
rules:
- apiGroups: ["tower.ansible.com"]
  resources: ["ansiblejobs"]
  verbs: ["create","get", "list", "watch", "update", "delete", "deletecollection", "patch"]

Red Hat OpenShift Container Platform バージョン 4.9 に gatekeeper Operator をインストールする場合、インストールに失敗します。OpenShift Container Platform をバージョン 4.9.0. にアップグレードする前に、gatekeeper Operator をバージョン 0.2.0 にアップグレードする必要があります。詳細は、「Upgrading gatekeeper and the gatekeeper operator」を参照してください。

設定ポリシーで complianceType のパラメーターに mustnothave、remediationAction のパラメーターに enforce が設定されている場合に、ポリシーは Kubernetes API に削除要求が送信されてから、準拠と表示されます。そのため、ポリシーが準拠と表示されているにも関わらず、Kubernetes オブジェクトは、Terminating の状態のままになってしまう可能性があります。

GDPR は、各自の個人データを処理するにあたり、強力なデータ保護規制フレームワークを確立します。GDPR は以下を提供します。

Red Hat Advanced Cluster Management for Kubernetes はプラットフォームとして、複数の技術データを扱いますが、その内、管理者ユーザー ID とパスワード、サービスユーザー ID とパスワード、Kubernetes ノード名など、個人データとみなされる可能性があるものも含まれます。また、Red Hat Advanced Cluster Management for Kubernetes プラットフォームは、プラットフォームの管理ユーザーに関する情報も扱います。プラットフォームで実行されるアプリケーションにより、プラットフォームではまだ知られていない、他のカテゴリーの個人データが取り込まれる可能性があります。

このような技術データの収集/作成、保存、アクセス、セキュリティー設定、ロギング、削除の方法に関する情報は、本書で後述します。

お客様は、以下のような情報をさまざまな方法でオンラインからコメント/フィードバック/依頼を送信できます。

通常は、連絡先フォームの件名への個人返信を有効にすると、お客様名とメールアドレスのみが使用され、個人データの使用は、Red Hat オンラインプライバシーステートメント に準拠します。

The Red Hat Advanced Cluster Management for Kubernetes プラットフォームの認証マネージャーは、コンソールからのユーザーの認証情報を受け入れ、バックエンドの OIDC プロバイダーに認証情報を転送し、OIDC プロバイダーはエンタープライズディレクトリーに対してユーザーの認証情報を検証します。次に OIDC プロバイダーは認証クッキー (auth-cookie) を、JSON Web Token (JWT) のコンテンツと合わせて、認証マネージャーに返します。JWT トークンは、認証要求時にグループのメンバーシップに加え、ユーザー ID やメールアドレスなどの情報を永続化します。この認証クッキーはその後コンソールに返されます。クッキーはセッション時に更新されます。クッキーは、コンソールをサインアウトしてから、または Web ブラウザーを閉じてから 12 時間有効です。

コンソールから次回認証要求を送信すると、フロントエンドの NGIX サーバーが、要求で利用可能な認証クッキーをデコードし、認証マネージャーを呼び出して要求を検証します。

Red Hat Advanced Cluster Management for Kubernetes プラットフォーム CLI では、ユーザーはログインに認証情報が必要です。

kubectl と oc CLI でも、クラスターへのアクセスに認証情報が必要です。このような認証情報は、管理コンソールから取得でき、12 時間後に有効期限が切れます。サービスアカウント経由のアクセスは、サポートされています。

Red Hat Advanced Cluster Management for Kubernetes プラットフォームは、ロールベースのアクセス制御 (RBAC) をサポートします。ロールマッピングのステージでは、認証ステージで提示されたユーザー名がユーザーまたはグループロールにマッピングされます。認可時にロールを使用して、認証ユーザーがどのような管理者アクティビティーを実行できるか判断します。

Red Hat Advanced Cluster Management for Kubernetes プラットフォームのロールを使用して、クラスター設定アクション、カタログや Helm リソース、Kubernetes リソースへのアクセスを制御します。クラスター管理者、管理者ー、オペレーター、エディター、ビューワーなど、IAM (Identity and Access Management) ロールが複数含まれています。ロールは、チームへの追加時に、ユーザーまたはユーザーグループに割り当てられます。リソースへのチームアクセスは、namespace で制御できます。

Pod のセキュリティーポリシーを使用して、Pod での操作またはアクセス権をクラスターレベルで制御できるように設定します。