第1章 セキュリティーのベストプラクティス
より回復力のある開発環境を促進するのに役立つ Red Hat OpenShift Dev Spaces の主なベストプラクティスを概説します。
Red Hat OpenShift Dev Spaces は OpenShift 上で実行され、プラットフォームおよび、そのプラットフォーム上で機能する製品の基盤を提供します。OpenShift のドキュメントは、セキュリティ強化の第一歩となります。
OpenShift でのプロジェクト分離
OpenShift では、プロジェクトの分離は Kubernetes の namespace の分離に似ていますが、プロジェクトの概念を通じて実現されます。OpenShift のプロジェクトは、クラスター内のさまざまなアプリケーション、チーム、またはワークロード間の分離と連携を提供する最上位の組織単位です。
デフォルトでは、OpenShift Dev Spaces は各ユーザーに対して一意の <username>-devspaces
プロジェクトをプロビジョニングします。または、クラスター管理者は、OpenShift レベルでプロジェクトのセルフプロビジョニングを無効にし、CheCluster カスタムリソースで namespace の自動プロビジョニングをオフにすることもできます。
devEnvironments: defaultNamespace: autoProvision: false
この設定では、OpenShift Dev Spaces に対して適切なアクセスを柔軟に選び提供できます。クラスター管理者は、各ユーザーのプロビジョニングを制御し、リソース制限やクォータを含むさまざまな設定を明示的に設定できます。プロジェクトプロビジョニングの詳細は、「プロジェクトの事前プロビジョニング」 を参照してください。
ロールベースアクセス制御 (RBAC)
デフォルトでは、OpenShift Dev Spaces Operator は以下の ClusterRole を作成します。
-
<namespace>-cheworkspaces-clusterrole
-
<namespace>-cheworkspaces-devworkspace-clusterrole
<namespace>
接頭辞は、Red Hat OpenShift Dev Spaces CheCluster CR が配置されているプロジェクト名に対応します。
ユーザーが初めて Red Hat OpenShift Dev Spaces にアクセスすると、対応する RoleBinding が <username>-devspaces
プロジェクトに作成されます。
ユーザーに namespace で使用する権限を付与できるすべてのリソースとアクションが以下にリストされています。
リソース | アクション |
---|---|
pods | "get", "list", "watch", "create", "delete", "update", "patch" |
pods/exec | "get", "create" |
pods/log | "get", "list", "watch" |
pods/portforward | "get", "list", "create" |
configmaps | "get", "list", "create", "update", "patch", "delete" |
events | "list", "watch" |
secrets | "get", "list", "create", "update", "patch", "delete" |
services | "get", "list", "create", "delete", "update", "patch" |
routes | "get", "list", "create", "delete" |
persistentvolumeclaims | "get", "list", "watch", "create", "delete", "update", "patch" |
apps/deployments | "get", "list", "watch", "create", "patch", "delete" |
apps/replicasets | "get", "list", "patch", "delete" |
namespace | "get", "list" |
projects | "get" |
devworkspace | "get", "create", "delete", "list", "update", "patch", "watch" |
devworkspacetemplates | "get", "create", "delete", "list", "update", "patch", "watch" |
各ユーザーには自分の namespace への権限のみが付与され、他のユーザーのリソースにアクセスできません。クラスター管理者は、ユーザーに追加の権限を追加できます。デフォルトで付与された権限を削除しないでください。
Red Hat OpenShift Dev Spaces ユーザー向けのクラスターロールの設定については 製品ドキュメント を参照してください。
ロールベースのアクセス制御の詳細は、OpenShift のドキュメント を参照してください。
開発環境の分離
開発環境の分離は、OpenShift プロジェクトを使用して実装されます。すべての開発者は、プロジェクトを 1 つ所有し、そのプロジェクトで以下の某ジェクトが作成および管理されます。
- IDE サーバーを含む Cloud Development Environment (CDE) Pod。
- Git トークン、SSH キー、Kubernetes トークンなどの開発者認証情報を含むシークレット。
- Git 名やメールなど、開発者固有の設定を持つ ConfigMap。
- CDE Pod が停止している場合でも、ソースコードなどのデータを保持するボリューム。
namespace 内のリソースへのアクセスは、その namespace を所有する開発者に制限する必要があります。別の開発者に読み取りアクセス権を付与することは、開発者の認証情報を共有することと同じなので、避けるべきです。
強化された認可
巨大なモノリス OpenShift クラスターを持つ代わりに、インフラストラクチャーを複数の「目的に合った」クラスターに分割することが現在の傾向として挙げられます。ただし、管理者はきめ細かいアクセスを提供して、特定の機能を特定のユーザーに制限する場合があります。
目的に適合した OpenShift クラスターとは、特定のユースケースまたはワークロードの要件と「目的に合った」特別に設計および設定されたクラスターを指します。管理するワークロードの特性に基づいて、パフォーマンス、リソース使用率、その他の要素を最適化するように調整されます。Red Hat OpenShift Dev Spaces の場合、このタイプのクラスターをプロビジョニングすることを推奨します。
この目的のために、さまざまなグループやユーザーに対するきめ細かなアクセス設定に使用できるオプションのプロパティーが、CheCluster カスタムリソースで利用できます。
-
allowUsers
-
allowGroups
-
denyUsers
-
denyGroups
以下は、アクセス設定の例です。
networking: auth: advancedAuthorization: allowUsers: - user-a - user-b denyUsers: - user-c allowGroups: - openshift-group-a - openshift-group-b denyGroups: - openshift-group-c
denyUsers
および denyGroup
カテゴリーのユーザーは Red Hat OpenShift Dev Spaces を使用できず、ユーザーダッシュボードにアクセスしようとすると警告が表示されます。
認証
認証された OpenShift ユーザーのみが Red Hat OpenShift Dev Spaces にアクセスできます。ゲートウェイ Pod は、ロールベースのアクセス制御 (RBAC) サブシステムを使用して、開発者がクラウド開発環境 (CDE) にアクセスする権限があるかどうかを判断します。
CDE Gateway コンテナーは、開発者の Kubernetes ロールをチェックします。ロールによって CDE Pod へのアクセスが許可されている場合は、開発環境への接続が許可されます。デフォルトでは、namespace の所有者だけが CDE Pod にアクセスできます。
namespace 内のリソースへのアクセスは、その namespace を所有する開発者に制限する必要があります。別の開発者に 読み取り
アクセス権を付与することは、開発者の認証情報を共有することと同じなので、避けるべきです。
セキュリティーコンテキストとセキュリティーコンテキストの制約
Red Hat OpenShift Dev Spaces は、CDE Pod コンテナーのセキュリティーコンテキストの仕様に SETGID
および SETUID
機能を追加します。
"spec": { "containers": [ "securityContext": { "allowPrivilegeEscalation": true, "capabilities": { "add": ["SETGID", "SETUID"], "drop": ["ALL","KILL","MKNOD"] }, "readOnlyRootFilesystem": false, "runAsNonRoot": true, "runAsUser": 1001110000 } ] }
これにより、ユーザーは CDE 内からコンテナーイメージを構築することができます。
デフォルトでは、Red Hat OpenShift Dev Spaces は、ユーザーに特定の SecurityContextConstraint
(SCC) を割り当て、ユーザーがそのような機能を持つ Pod を起動できるようにします。この SCC は、デフォルトの restricted
SCC と比較してユーザーに多くの機能を付与しますが、anyuid
SCC と比較すると機能は少なくなります。このデフォルトの SCC は、OpenShift Dev Spaces namespace に事前に作成され、container-build
という名前が付けられています。
CheCluster カスタムリソースで次のプロパティーを設定すると、ユーザーに追加の機能と SCC が割り当てられなくなります。
spec: devEnvironments: disableContainerBuildCapabilities: true
リソースの割り当てと制限範囲
リソースクォータと制限範囲は、クラスター内での不正なアクターやリソースの乱用を防ぐために使用できる Kubernetes の機能です。具体的には、Pod とコンテナーのリソース消費制約を設定できます。リソースクォータと制限範囲を組み合わせて、プロジェクト固有のポリシーを適用し、不正なアクターが過剰なリソースを消費するのを防ぐことができます。
これらのメカニズムは、OpenShift クラスター内のリソース管理、安定性、公平性の向上に貢献します。リソースクォータ と 制限範囲 の詳細は、OpenShift のドキュメントを参照してください。
非接続環境
エアギャップされた、OpenShift の非接続クラスターとは、インターネットや外部ネットワークから分離された OpenShift クラスターを指します。この分離は、機密性の高いシステムや重要なシステムを潜在的なサイバー脅威から保護するというセキュリティー上の理由で行われることが多いです。エアギャップ環境では、クラスターは外部リポジトリーまたはレジストリーにアクセスしてコンテナーイメージ、更新、または依存関係をダウンロードできません。
Red Hat OpenShift Dev Spaces がサポートされており、制限された環境にインストールできます。インストール手順は 公式ドキュメント に記載されています。
拡張機能の管理
デフォルトでは、Red Hat OpenShift Dev Spaces には、Microsoft Visual Studio Code - Open Source エディターの限定された拡張機能セットなど、組み込みの Open VSX レジストリーが含まれています。または、クラスター管理者は、カスタムリソースで別のプラグインレジストリー (例: 数千の拡張機能を含む https://open-vsx.org) を指定することもできます。また、カスタム Open VSX レジストリーをビルドすることもできます。IDE 拡張機能の管理の詳細は、公式ドキュメント を参照してください。
追加の拡張機能をインストールすると、潜在的なリスクが増大します。これらのリスクを最小限に抑えるには、信頼できるソースからの拡張機能のみをインストールし、定期的に更新するようにしてください。
シークレット
ユーザーの namespace に Kubernetes シークレットとして保存されている機密データ (Personal Access Token (PAT)、SSH 鍵など) を保持します。
Git リポジトリー
使い慣れていて信頼できる Git リポジトリー内で操作することが重要です。新しい依存関係をリポジトリーに組み込む前に、それらが適切に保守されていることを確認し、コード内で特定されたセキュリティー上の脆弱性に対処するために定期的に更新をリリースします。