Red Hat Summit Red Hat Summitサポートコンソール開発者トライアルの開始お問い合わせ

13.5. セキュリティー

13.5.1. セキュリティーの基礎
リンクのコピー

特にクラウドネイティブアプリケーションを実行する場合、セキュリティーは OpenShift Container Platform デプロイメントの重要なコンポーネントです。

主要なセキュリティー上の考慮事項に従うことで、高帯域幅ネットワークデプロイメントのセキュリティーを強化できます。これらの標準とベストプラクティスを実装することで、ほとんどのユースケースでセキュリティーを強化できます。

13.5.1.1. RBAC の概要
リンクのコピー

ロールベースアクセス制御 (RBAC) オブジェクトは、ユーザーがプロジェクト内で所定のアクションを実行することが許可されるかどうかを決定します。

これにより、プラットフォーム管理者はクラスターロールおよびバインディングを使用して、OpenShift Container Platform プラットフォーム自体およびすべてのプロジェクトへの各種のアクセスレベルを持つユーザーを制御できます。

開発者はローカルロールとバインディングを使用して、プロジェクトにアクセスできるユーザーを制御できます。認可は認証とは異なる手順であり、認証はアクションを実行するユーザーのアイデンティティーの判別により密接に関連しています。

認可は、次の認可オブジェクトを使用して管理されます。

ルール
特定のオブジェクトに対して許可されるアクションのセットです。たとえば、ルールによって、ユーザーまたはサービスアカウントが Pod を作成できるかどうかを決定できます。各ルールで、API リソース、その API 内のリソース、および許可されるアクションを指定します。
ロール

ユーザーまたはグループが実行できるアクションを定義するルールの集まりです。ルールを複数のユーザーまたはグループに関連付けたり、バインドしたりできます。ロールファイルに、そのロールに許可されるアクションおよびリソースを指定するルールを 1 つ以上含めることができます。

ロールは次のタイプに分類されます。

  • クラスターロールはクラスターレベルで定義できます。クラスターロールは 1 つの namespace に結び付けられません。ユーザー、グループ、またはサービスアカウントにクラスターロールをバインドすると、すべての namespace または特定の namespace に適用できます。
  • プロジェクトロールは特定の namespace 内に作成でき、その namespace にのみ適用されます。特定のユーザーに権限を割り当てて、ロールとロールバインディングをそのロールの namespace 内に作成することで、他の namespace に影響を与えないようにすることができます。
バインディング

ロールを使用したユーザーとグループ間の関連付けです。ロールバインディングを作成すると、ロール内のルールを特定のユーザー ID またはグループと結び付けることができます。これにより、ロールとユーザーまたはグループが組み合わせられ、ユーザーまたはグループが実行できるアクションが定義されます。

注記

ユーザーまたはグループには複数のロールをバインドできます。

RBAC の詳細は、「RBAC を使用した権限の定義および適用」を参照してください。

RBAC の運用上の考慮事項

運用上のオーバーヘッドを削減するには、複数のクラスターにわたって個々のユーザー ID を処理するのではなく、グループを通じてアクセスを管理します。組織レベルでグループを管理することで、アクセス制御を合理化し、組織全体の管理を簡素化できます。

13.5.1.2. セキュリティーアカウントの概要
リンクのコピー

サービスアカウントは、コンポーネントが API に直接アクセスできるようにする OpenShift Container Platform アカウントです。サービスアカウントは各プロジェクトに存在する API オブジェクトです。サービスアカウントは、一般ユーザーの認証情報を共有せずに API アクセスをより柔軟に制御する方法を提供します。

サービスアカウントを使用すると、Pod にロールベースのアクセス制御 (RBAC) を適用できます。Pod やデプロイメントなどのワークロードにサービスアカウントを割り当てることで、さまざまなレジストリーからのプルなど、追加の権限を付与できます。これにより、より低い権限をサービスアカウントに割り当てて、そのアカウント配下で実行される Pod のセキュリティー関連のフットプリントを削減することもできます。

サービスアカウントの詳細は、「サービスアカウントの概要および作成」を参照してください。

13.5.1.3. アイデンティティープロバイダーの設定
リンクのコピー

アイデンティティープロバイダーの設定は、クラスターでユーザーを設定する際の最初のステップです。アイデンティティープロバイダーを使用すると、組織レベルでグループを管理できます。

アイデンティティープロバイダーは、クラスターレベルではなく組織レベルで管理される特定のユーザーグループを取得できます。これにより、組織の確立されたプラクティスに準拠したグループにユーザーを追加したり、グループからユーザーを削除したりできます。

注記

変更をクラスターに取り込むには、頻繁に実行される cron ジョブを設定する必要があります。

アイデンティティープロバイダーを使用すると、組織内の特定グループのアクセスレベルを管理できます。たとえば、アクセスレベルを管理するために、次の操作を実行できます。

  • クラスターレベルの権限を必要とするチームに cluster-admin ロールを割り当てる。
  • アプリケーション管理者に、それぞれのプロジェクトのみを管理するための特定の権限を付与する。
  • 運用チームに、クラスター全体の view アクセス権を提供し、変更を許可することなく、監視できるようにする。

アイデンティティープロバイダーの設定の詳細は、「アイデンティティープロバイダー設定について」を参照してください。

13.5.1.4. kubeadmin ユーザーを cluster-admin ユーザーに置き換える
リンクのコピー

デフォルトでは、すべてのクラスターに cluster-admin 権限を持つ kubeadmin ユーザーが作成されます。クラスターのセキュリティーを強化するには、`kubeadmin` ユーザーを cluster-admin ユーザーに置き換えてから、kubeadmin ユーザーを無効にするか削除します。

前提条件

  • cluster-admin 権限を持つユーザーを作成した。
  • OpenShift CLI (oc) がインストールされている。
  • セキュアに保存するための仮想 vault への管理アクセス権がある。

手順

  1. htpasswd アイデンティティープロバイダーを使用して、緊急用の cluster-admin ユーザーを作成します。詳細は、「htpasswd 認証について」を参照してください。

  2. 次のコマンドを実行して、新しいユーザーに cluster-admin 権限を割り当てます。 

    $ oc adm policy add-cluster-role-to-user cluster-admin <emergency_user>

  3. 緊急用ユーザーのアクセス権を検証します。

    1. 新しい緊急用ユーザーを使用してクラスターにログインします。

    2. 次のコマンドを実行して、ユーザーに cluster-admin 権限があることを確認します。 

      $ oc whoami

      出力に緊急用ユーザーの ID が表示されることを確認します。

  4. 緊急用ユーザーのパスワードまたは認証キーを仮想 vault にセキュアに保存します。

    注記

    機密性の高い認証情報の保護に関する組織のベストプラクティスに従ってください。

  5. 次のコマンドを実行して、kubeadmin ユーザーを無効にするか削除し、セキュリティーリスクを軽減します。 

    $ oc delete secrets kubeadmin -n kube-system

13.5.1.5. セキュリティーに関する考慮事項
リンクのコピー

ワークロードでは機密データを処理する場合があり、高い信頼性が求められます。1 つのセキュリティー脆弱性が、クラスター全体に及ぶ広範な侵害につながる可能性があります。OpenShift Container Platform クラスターでは多数のコンポーネントが実行されているため、侵害の拡大を防ぐために各コンポーネントを保護する必要があります。ネットワークの信頼性を維持し、脆弱性を回避するには、すべてのコンポーネントを含むインフラストラクチャー全体のセキュリティーを確保することが不可欠です。

次の主要なセキュリティー機能は、機密データを扱うすべての業界において不可欠です。

  • Security Context Constraints (SCC): OpenShift Container Platform クラスター内の Pod セキュリティーをきめ細かく制御します。
  • Pod Security Admission (PSA): Kubernetes ネイティブの Pod セキュリティーコントロール。
  • 暗号化: 高スループットのネットワーク環境でデータの機密性を確保します。

13.5.1.6. Kubernetes と OpenShift Container Platform における Pod セキュリティーの発展
リンクのコピー

Kubernetes では当初、Pod のセキュリティーが制限されていました。OpenShift Container Platform を Kubernetes と統合したときに、Red Hat は Security Context Constraints (SCC) によって Pod のセキュリティーを強化しました。同様の機能として、Kubernetes バージョン 1.3 で PodSecurityPolicy (PSP) が導入されました。しかし、Kubernetes バージョン 1.21 で Pod Security Admission (PSA) が導入されたことにより、Kubernetes バージョン 1.25 で PSP は非推奨になりました。

PSA は、OpenShift Container Platform でも、バージョン 4.11 で利用可能になりました。PSA は、Pod のセキュリティーを強化しますが、特定のユースケースに現在も必要な、SCC によって提供される機能が欠けています。したがって、OpenShift Container Platform は引き続き PSA と SCC の両方をサポートしています。

13.5.1.7. ベアメタルインフラストラクチャー
リンクのコピー

ハードウェア要件
通信や金融などのいくつかの業界では、クラスターは主にベアメタルハードウェア上に構築されます。これは、仮想マシンを使用せずに、オペレーティングシステム (op-system-first) が物理マシンに直接インストールされることを意味します。これにより、ネットワーク接続の複雑さが軽減され、レイテンシーが最小限に抑えられ、アプリケーションの CPU 使用率が最適化されます。
ネットワーク要件
これらの業界のネットワークでは、標準的な IT ネットワークに比べてはるかに大きな帯域幅が必要になる場合があります。たとえば、通信事業者のネットワークでは、大量のデータスループットを処理するために、通常、デュアルポート 25 GB 接続または 100 GB ネットワークインターフェイスカード (NIC) が使用されます。セキュリティーは極めて重要であり、機密性の高い個人データを保護するには、暗号化された接続とセキュアなエンドポイントが必要です。

13.5.1.8. ライフサイクル管理
リンクのコピー

セキュリティーを確保するには、アップグレードが重要です。脆弱性が発見された場合、その脆弱性は最新の z-stream リリースで修正されます。その後、この修正は下位の各 y-stream リリースに遡って導入され、サポート対象のすべてのバージョンにパッチが適用されます。パッチはサポート対象外になったリリースには適用されません。したがって、OpenShift Container Platform クラスターを定期的にアップグレードして、サポート対象のリリースを維持し、脆弱性から保護された状態を維持することが重要です。

ライフサイクル管理とアップグレードの詳細は、「OpenShift Container Platform クラスターのアップグレード」を参照してください。

Red Hat logoGithubredditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

Red Hat ドキュメントについて

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。 最新の更新を見る.

Legal Notice

Theme

© 2026 Red Hatトップに戻る