第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」: コアオブジェクトをそれぞれ公開します。
- これらの API を読み取るコントローラーは変更を別のオブジェクトに適用し、ステータスを報告し、オブジェクトに再び書き込みます。
ユーザーは 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 ベアラートークンを使用します。インフラストラクチャーコンポーネント (ノードなど) は、それらの ID が含まれる、システム生成のクライアント証明書を使用します。コンテナーで実行されるインフラストラクチャーコンポーネントは、「サービスアカウント」に関連付けられるトークンを使用して 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 は Golang の標準ライブラリーの実装である crypto/tls を使用し、外部の crypto および 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 はサーバー設定で有効にできます。サーバーおよびクライアントは共に認証される暗号化アルゴリズムと完全な前方秘匿性を持つ最新の暗号スイートを優先的に使用します。暗号スイートと RC4、3DES、および MD5 などの非推奨で、セキュアでないアルゴリズムは無効化されています。また、内部クライアント (LDAP 認証など) によっては、TLS 1.0 から 1.2 設定の制限が少なく、より多くの暗号スイートが有効化されています。
| TLS バージョン | OpenShift Container Platform Server | 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
