第1章 概要
OpenShift v3 は、基礎となる Docker 形式のコンテナーイメージおよび Kubernetes 概念を可能な限り正確に表示することを目的としてレイヤー化されたシステムであり、開発者がアプリケーションを簡単に構成できるようにすることに重点が置かれています。たとえば、Ruby のインストール、コードのプッシュ、および MySQL の追加などを簡単に実行できます。
OpenShift v2 とは異なり、作成後の設定ではモデルのすべての側面においてより大きな柔軟性が確保されます。アプリケーションを別個のオブジェクトとみなす概念は、「サービス」を構成するという柔軟な概念に置き換えられ、2 つの Web コンテナーでデータベースを再利用したり、データベースをネットワークエッジに直接公開したりできるようになりました。
1.1. 各種の層について
Docker サービスは、Linux ベースの軽量なコンテナーイメージのパッケージ化および作成のために抽象化を提供します。Kubernetes はクラスター管理を行い、複数のホストでコンテナーをオーケストレーションします。
OpenShift Container Platform は以下の機能を追加します。
図1.1 OpenShift Container Platform アーキテクチャーの概要
1.2. OpenShift Container Platform アーキテクチャーについて
OpenShift Container Platform のアーキテクチャーはマイクロサービスをベースとしており、分割された小規模なユニットが相互に連携します。これは Kubernetes クラスターの上部で実行され、オブジェクトについてのデータは信頼できるクラスター化されたキー値ストアの etcd に保存されます。これらのサービスは機能別に分類されます。
ユーザーは REST API を呼び出して、システムの状態を変更します。コントローラーは REST API を使用してユーザーの必要な状態を読み取ってから、システムの他の部分の同期を試行します。たとえば、ユーザーがビルドを要求する場合、「ビルド」オブジェクトを作成します。ビルドコントローラーは新規ビルドが作成されていることを確認し、そのビルドを実行するためにクラスターでプロセスを実行します。ビルドが完了すると、コントローラーは REST API でビルドオブジェクトを更新し、ユーザーはそれらのビルドが完了したことを確認できます。
コントローラーのパターンは、OpenShift Container Platform の多くの機能に拡張性があることを意味します。ビルドを実行し、起動する方法については、イメージの管理方法やデプロイメントが実行される方法とは切り離してカスタマイズできます。コントローラーはシステムの「ビジネスロジック」を実行し、ユーザーのアクションを実行します。これらのコントローラーをカスタマイズするか、または独自のロジックに置き換えることにより、複数の異なる動作を実装できます。システム管理の視点では、これは API を使用し、繰り返されるスケジュールにおける共通の管理アクションをスクリプト化できることも意味しています。これらのスクリプトは変更の有無を監視し、アクションを実行するコントローラーとしても機能します。OpenShift Container Platform では、このようにクラスターをカスタマイズする機能をファーストクラスの動作として使用できます。
この機能を有効にするため、コントローラーはシステムに対する変更の安定したストリームを利用し、システムのビューをユーザーの実行内容と同期します。このイベントストリームは、変更が発生するとすぐにそれらの変更を etcd から REST API にプッシュし、次にコントローラーにプッシュして、変更がシステム全体で非常に迅速かつ効率的に適用されるようにします。ただし、障害は常に発生する可能性があるため、コントローラーは起動時にシステムの最新の状態を取得でき、すべてが適切な状態にあることを確認できなければなりません。この再同期は、障害の発生時にオペレーターが影響を受けるコンポーネントを再起動でき、システムでダブルチェックしてから次に進むことができるので重要になります。コントローラーは常にシステムを同期するため、システムは最終的にはユーザーの意図に収束していきます。
1.3. OpenShift Container Platform のセキュリティーを保護する方法
OpenShift Container Platform および Kubernetes API は、認証情報を提示するユーザーの認証を行ってから、それらのロールに基づいてユーザーの承認を行います。開発者および管理者はどちらも数多くの方法で認証されますが、主に OAuth トークンおよび X.509 クライアント証明書が使用されます。OAuth トークンは JSON Web Algorithm RS256 を使用して署名されます。これは SHA-256 を使用した RSA 署名アルゴリズムです。
開発者 (システムのクライアント) は通常、クライアントプログラム(oc など) を使用するか、またはブラウザーを使用して Web コンソールに対して REST API 呼び出しを実行し、ほとんどの通信に OAuth ベアラートークンを使用します。インフラストラクチャーコンポーネント (ノードなど) は、システムで生成されるアイデンティティーが含まれるクライアント証明書を使用します。コンテナーで実行されるインフラストラクチャーコンポーネントはそれらのサービスアカウントに関連付けられるトークンを使用して API に接続します。
承認は、「Pod の作成」または「サービスの一覧表示」などのアクションを定義し、それらをポリシードキュメントの各種ロールに分類する OpenShift Container Platform ポリシーエンジンで処理されます。ロールは、ユーザーまたはグループ ID によってユーザーまたはグループにバインドされます。ユーザーまたはサービスアカウントがアクションを試行すると、ポリシーエンジンはユーザーに割り当てられた 1 つ以上のロール (例: クラスター管理者または現行プロジェクトの管理者) をチェックし、その継続を許可します。
クラスターで実行されるすべてのコンテナーはサービスアカウントに関連付けられるため、シークレットをそれらのサービスアカウントに関連付け、コンテナーに自動的に配信することもできます。これにより、インフラストラクチャーでイメージ、ビルドおよびデプロイメントコンポーネントのプルおよびプッシュを行うためのシークレットを管理でき、アプリケーションコードでそれらのシークレットを簡単に利用することも可能になります。
1.3.1. TLS サポート
REST API とのすべての通信チャネル、および etcd および API サーバーなどのマスターコンポーネント間の通信のセキュリティーは TLS で保護されます。TLS は、X.509 サーバー証明書およびパブリックキーインフラストラクチャーを使用して強力な暗号化、データの整合性、およびサーバーの認証を提供します。デフォルトで、新規の内部 PKI は OpenShift Container Platform のそれぞれのデプロイメントについて作成されます。内部 PKI は 2048 ビット RSA キーおよび SHA-256 署名を使用します。パブリックホストのカスタム証明書もサポートされます。
OpenShift Container Platform は crypto/tls の Golang 標準ライブラリーの実装を使用し、外部の暗号および TLS ライブラリーには依存しません。さらに、クライアントは GSSAPI 認証および OpenPGP 署名の外部ライブラリーに依存します。GSSAPI は通常 OpenSSL の libcrypto を使用する MIT Kerberos または Heimdal Kerberos のいずれかによって提供されます。OpenPGP 署名の検証は libgpgme および GnuPG によって処理されます。
非セキュアなバージョンである SSL 2.0 および SSL 3.0 はサポート対象外であり、これを利用することはできません。OpenShift Container Platform サーバーおよび oc クライアントはデフォルトで TLS 1.2 のみを提供します。TLS 1.0 および TLS 1.1 はサーバー設定で有効にできます。サーバーおよびクライアントはどちらも、認証される暗号化アルゴリズムと Perfect Forward Secrecy を使用する最新の暗号スイートを優先的に使用します。RC4、3DES、および MD5 などの非推奨かつ非セキュアなアルゴリズムを使用する暗号スイートは無効にされます。一部の内部クライアント (LDAP 認証など) には TLS 1.0 から 1.2 への設定についての制限が少なく、より多くの暗号スイートが有効にされます。
表1.1 サポートされる TLS バージョン
| TLS バージョン | OpenShift Container Platform サーバー | oc クライアント | 他のクライアント |
|---|---|---|---|
|
SSL 2.0 |
非対応 |
非対応 |
非対応 |
|
SSL 3.0 |
非対応 |
非対応 |
非対応 |
|
TLS 1.0 |
No [a] |
No [a] |
Maybe (可能性あり) [b] |
|
TLS 1.1 |
No [a] |
No [a] |
Maybe (可能性あり)[b] |
|
TLS 1.2 |
Yes |
Yes |
Yes |
|
TLS 1.3 |
N/A [c] |
N/A [c] |
N/A [c] |
[a]
デフォルトで無効にされますが、サーバー設定で有効にできます。
[b]
LDAP クライアントなどの一部の内部クライアントです。
[c]
TLS 1.3 は開発中です。
| |||
以下は OpenShift Container Platform のサーバーの有効にされた暗号スイートの一覧であり、oc クライアントは優先される順序で並べ替えられます。
-
TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305 -
TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305 -
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 -
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 -
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 -
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 -
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 -
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 -
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA -
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA -
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA -
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA -
TLS_RSA_WITH_AES_128_GCM_SHA256 -
TLS_RSA_WITH_AES_256_GCM_SHA384 -
TLS_RSA_WITH_AES_128_CBC_SHA -
TLS_RSA_WITH_AES_256_CBC_SHA
Where did the comment section go?
Red Hat's documentation publication system recently went through an upgrade to enable speedier, more mobile-friendly content. We decided to re-evaluate our commenting platform to ensure that it meets your expectations and serves as an optimal feedback mechanism. During this redesign, we invite your input on providing feedback on Red Hat documentation via the discussion platform.