Openshift-security

提供:Dev Guides
移動先:案内検索

OpenShift-セキュリティ

OpenShiftセキュリティは、主にセキュリティ制約を処理する2つのコンポーネントの組み合わせです。

  • セキュリティコンテキストの制約(SCC)
  • サービスアカウント

セキュリティコンテキストの制約(SCC)

基本的にポッドの制限に使用されます。つまり、実行できるアクションやクラスター内でアクセスできるすべてのものなど、ポッドの制限を定義します。

OpenShiftは、管理者が使用、変更、および拡張できる事前定義されたSCCのセットを提供します。

$ oc get scc
NAME              PRIV   CAPS  HOSTDIR  SELINUX    RUNASUSER         FSGROUP   SUPGROUP  PRIORITY
anyuid            false   []   false    MustRunAs  RunAsAny          RunAsAny  RunAsAny  10
hostaccess        false   []   true     MustRunAs  MustRunAsRange    RunAsAny  RunAsAny  <none>
hostmount-anyuid  false   []   true     MustRunAs  RunAsAny          RunAsAny  RunAsAny  <none>
nonroot           false   []   false    MustRunAs  MustRunAsNonRoot  RunAsAny  RunAsAny  <none>
privileged        true    []   true     RunAsAny   RunAsAny          RunAsAny  RunAsAny  <none>
restricted        false   []   false    MustRunAs  MustRunAsRange    RunAsAny  RunAsAny  <none>

事前定義されたsccを使用する場合は、sccグループにユーザーまたはグループを追加するだけで実行できます。

$ oadm policy add-user-to-scc <scc_name> <user_name>
$ oadm policy add-group-to-scc <scc_name> <group_name>

サービスアカウント

サービスアカウントは、基本的にOpenShiftマスターAPIへのアクセスを制御するために使用され、マスターまたはノードマシンのいずれかからコマンドまたはリクエストが起動されると呼び出されます。

アプリケーションまたはプロセスが、制限されたSCCによって許可されていない機能を必要とするときはいつでも、特定のサービスアカウントを作成し、そのアカウントをそれぞれのSCCに追加する必要があります。 ただし、SCCが要件に合わない場合は、最適なものを使用するよりも、要件に固有の新しいSCCを作成することをお勧めします。 最後に、展開構成用に設定します。

$ oc create serviceaccount Cadmin
$ oc adm policy add-scc-to-user vipin -z Cadmin

コンテナセキュリティ

OpenShiftでは、コンテナーのセキュリティは、コンテナープラットフォームの安全性とコンテナーの実行場所の概念に基づいています。 コンテナのセキュリティと何に注意する必要があるかについて話すとき、いくつかのことが明らかになります。

画像の出所-生産環境で実行されているコンテナの出所を正確かつ議論の余地なく特定する安全なラベリングシステムが設置されています。

セキュリティスキャン-イメージスキャナーは、既知の脆弱性についてすべてのイメージを自動的にチェックします。

監査-実稼働環境は定期的に監査され、すべてのコンテナが最新のコンテナに基づいており、ホストとコンテナの両方が安全に構成されていることを確認します。

分離と最小特権-コンテナは、効果的に機能するために必要な最小限のリソースと特権で実行されます。 ホストや他のコンテナに過度に干渉することはできません。

実行時脅威検出-実行時にコンテナ化されたアプリケーションに対するアクティブな脅威を検出し、それに自動的に応答する機能。

アクセス制御-AppArmorやSELinuxなどのLinuxセキュリティモジュールは、アクセス制御を実施するために使用されます。

コンテナのセキュリティをアーカイブする主要な方法はほとんどありません。

  • oAuthを介したアクセスの制御
  • セルフサービスWebコンソール経由
  • プラットフォームの証明書による

OAuthを介したアクセスの制御

この方法では、API制御アクセスへの認証はアーカイブされ、OpenShiftマスターマシンに組み込まれたOAuthサーバーを介した認証用の安全なトークンを取得します。 管理者は、OAuthサーバー構成の構成を変更することができます。

OAuthサーバー設定の詳細については、このチュートリアルの第5章を参照してください。

セルフサービスWebコンソール経由

このWebコンソールセキュリティ機能は、OpenShift Webコンソールに組み込まれています。 このコンソールは、一緒に働くすべてのチームが認証なしで他の環境にアクセスできないようにします。 OpenShiftのマルチtelnetマスターには、次のセキュリティ機能があります-

  • TCLレイヤーが有効になっています
  • 認証にx.509証明書を使用します
  • マスターマシンのetcd構成を保護します

プラットフォームの証明書による

この方法では、各ホストの証明書は、インストール中にAnsible経由で構成されます。 REST APIを介してHTTPS通信プロトコルを使用するため、さまざまなコンポーネントおよびオブジェクトへのTCLセキュア接続が必要です。 これらは事前定義された証明書ですが、アクセスのためにマスターのクラスターにカスタム証明書をインストールすることもできます。 マスターの初期セットアップ中に、 openshift_master_overwrite_named_certificates パラメーターを使用して既存の証明書をオーバーライドすることにより、カスタム証明書を構成できます。

openshift_master_named_certificates = [{"certfile": "/path/on/host/to/master.crt",
"keyfile": "/path/on/host/to/master.key",
"cafile": "/path/on/host/to/mastercert.crt"}]

カスタム証明書を生成する方法の詳細については、次のリンクにアクセスしてください-

https://www.linux.com/learn/creating-self-signed-ssl-certificates-apache-linux

ネットワークセキュリティー

OpenShiftでは、通信にソフトウェア定義ネットワーク(SDN)が使用されます。 ネットワーク名前空間は、クラスター内の各ポッドに使用されます。各ポッドは、独自のIPとポートの範囲を取得して、ネットワークトラフィックを取得します。 この方法では、他のプロジェクトのポッドと通信できないため、ポッドを分離できます。

プロジェクトの分離

これは、CLIから次の* oadmコマンド*を使用してクラスター管理者が実行できます。

$ oadm pod-network isolate-projects <project name 1> <project name 2>

これは、上記で定義したプロジェクトがクラスター内の他のプロジェクトと通信できないことを意味します。

ボリュームセキュリティ

ボリュームセキュリティとは、明らかにOpenShiftクラスター内のプロジェクトのPVおよびPVCを保護することを意味します。 OpenShiftのボリュームへのアクセスを制御するには、主に4つのセクションがあります。

  • 補足グループ
  • fsGroup
  • runAsUser *seLinuxOptions

補足グループ-補足グループは通常のLinuxグループです。 システムでプロセスが実行されると、ユーザーIDとグループIDで実行されます。 これらのグループは、共有ストレージへのアクセスを制御するために使用されます。

次のコマンドを使用して、NFSマウントを確認します。

# showmount -e <nfs-server-ip-or-hostname>
Export list for f21-nfs.vm:
/opt/nfs*

次のコマンドを使用して、マウントサーバー上のNFSの詳細を確認します。

# cat/etc/exports
/opt/nfs *(rw,sync,no_root_squash)
...
# ls -lZ/opt/nfs -d
drwxrws---. nfsnobody 2325 unconfined_u:object_r:usr_t:s0/opt/nfs
# id nfsnobody
uid = 65534(nfsnobody) gid = 454265(nfsnobody) groups = 454265(nfsnobody)

_/opt/nfs/_エクスポートには、UID 454265 およびグループ 2325 でアクセスできます。

apiVersion: v1
kind: Pod
...
spec:
   containers:
   - name: ...
      volumeMounts:
      - name: nfs
         mountPath:/usr/share/...
   securityContext:
      supplementalGroups: [2325]
   volumes:
   - name: nfs
      nfs:
      server: <nfs_server_ip_or_host>
      path:/opt/nfs
*fsGroup*

fsGroupは、コンテナ補助グループの追加に使用されるファイルシステムグループを表します。 補足グループIDは共有ストレージに使用され、fsGroupはブロックストレージに使用されます。

kind: Pod
spec:
   containers:
   - name: ...
   securityContext:
      fsGroup: 2325
*runAsUser*

runAsUserは、通信にユーザーIDを使用します。 これは、ポッド定義でコンテナーイメージを定義する際に使用されます。 必要に応じて、すべてのコンテナで単一のIDユーザーを使用できます。

コンテナの実行中、定義されたIDはエクスポートの所有者IDと一致します。 指定されたIDが外部で定義されている場合、ポッド内のすべてのコンテナーに対してグローバルになります。 特定のポッドで定義されている場合、単一のコンテナーに固有になります。

spec:
   containers:
   - name: ...
      securityContext:
         runAsUser: 454265