Oracleは、絶対に必要な場合を除き、管理チャネル、RMIチャネルまたはT3チャネルをKubernetesクラスタの外部に公開「しない」ことをお薦めします。
ロード・バランサ、ポート転送、NodePortsなどを使用して管理、RMI、EJB、JMSまたはT3対応チャネルを公開する場合は、構成したカスタム専用WebLogic Serverポートを使用してアクセスを制限します。トラフィックをデフォルト・ポートにリレーするかわりに、T3または管理プロトコル(ネットワーク・アクセス・ポイント)を使用して、双方向SSLを利用するか、セキュリティ・リストなどのコントロールを使用するか、アクセスを提供するために要塞を設定します。 デフォルト・ポートでは複数のプロトコルがサポートされるため、カスタム・チャネルはデフォルト・チャネルよりも優先されます。
WLSTの実行など、管理目的でT3またはRMIベースのチャネルにアクセスする場合は、kubectl execをKubernetesポッドにしてからwlst.shを実行するか、Bastionアクセスを設定し、Bastionホストからjava weblogic.WLSTまたは$ORACLE_HOME/oracle_common/common/bin/wlst.shを実行してKubernetesクラスタに接続します(一部のクラウド環境では、BastionではなくJump HostまたはJump Serverという用語を使用します)。
また、クラウド、データ・センターなどの間でドメイン間T3アクセスを使用する必要がある場合は、プライベートVPNを検討してください。
ロード・バランサ、ポート転送、NodePortsなどを使用してHTTPへのリモート・アクセスを提供する場合、Oracleでは、トラフィックをデフォルト・ポートにリレーするのではなく、カスタムHTTPチャネル(ネットワーク・アクセス・ポイント)を使用して構成した専用のWebLogic Serverポートにトラフィックをリレーすることをお薦めします。 これにより、外部トラフィックがHTTPプロトコルに制限されるようになります。 デフォルト・ポートでは複数のプロトコルがサポートされるため、カスタムHTTPチャネルはデフォルト・ポートよりも優先されます。
T3トラフィックの処理を明示的に許可する場合(トンネリングでは、T3がHTTPを使用してチャネルをトンネリングする場合)を除き、リモート・アクセス用に公開されるHTTPチャネルでトンネリングを有効にしないでください。また、「WebLogic T3および管理チャネル」の説明に従って、アクセスをさらに保護するために必要な追加のステップを実行します。
Kubernetes NodePortsはデモおよびスタート・ガイドでの使用に適していますが、通常は次のような複数の理由で本番システムには適していません:
NodePortがポートをパブリック・インターネットに暗黙的に公開する場合があります。NodePortsを公開できません。管理ポートの設定: WebLogicまたは管理チャネルに管理ポートを構成して、他のすべてのチャネルが管理権限付きトラフィックを受け入れないようにします(これには、HTTPを介したWebLogicコンソールからの管理権限付きトラフィックの防止が含まれます)。
匿名のデフォルトに注意してください : 外部で使用可能なポートで、WebLogic JNDI、EJB/RMIまたはJMSクライアントに適したプロトコルがサポートされている場合は、「デフォルトで」そうなります:
SSLの構成: 不要なアプリケーションによる外部アクセスを防ぐために双方向SSLを構成できます(通常は、コール元とロード・バランサの間にSSLが設定され、プレーン・テキスト・トラフィックはロード・バランサからWebLogicに内部的に流れます)。