Red Hat OpenShift Container Platform での Open RUN 21.0.0.4 リリースノート

Open Liberty 2021

Red Hat OpenShift Container Platform での Open RUN 2021 リリースノート

概要

本リリースノートには、Red Hat OpenShift Container Platform リリースの Open RUN 2021 に含まれる新機能、機能拡張、修正、および問題に関する最新情報が含まれています。

第1章 機能

21.0.0.4 では、Web ベースの GUI が Java Batch ジョブおよび OpenID Connect(OIDC)クライアントおよびトークン管理を表示および操作するためのサポートと共に、Web ベースの GUI を提供しています。MicroProfile Context Propagation はバージョン 1.2 に更新され、MicroProfile Config 2.0 が空の値設定プロパティーを処理する方法の違いに対応します。ビットのセキュリティーを維持するために、LDAP 接続で Kerberos 認証がサポートされ、認証フィルターにシングルサインオン(SSO)LTPA および JWT サポートを追加しました。また、本リリースには、リークした接続の自動クリーンアップ、ハング要求時のスレッドダンプの制御、拡張アプリケーションの場所を指定する機能も複数あります。

Open RUN 21.0.0.4 では、以下の ようになります。

1.1. 21.0.0.4 を使用してアプリケーションを実行します。

Maven を使用している場合は、以下のコーディネートです。

<dependency>
    <groupId>io.openliberty</groupId>
    <artifactId>openliberty-runtime</artifactId>
    <version>21.0.0.4</version>
    <type>zip</type>
</dependency>

または Gradle の場合:

dependencies {
    libertyRuntime group: 'io.openliberty', name: 'openliberty-runtime', version: '[21.0.0.4,)'
}

または、Docker を使用している場合は、以下を実行します。

FROM open-liberty

1.2. Admin Center 1.0

Admin Center 1.0 機能により、Java Batch ジョブおよび OpenID Connect(OIDC)クライアントおよびトークン管理を表示および対話するサポートと共に、実行中のサーバーの設定、管理、監視に役立つ Web ベースの GUI を利用できます。

ui serverConfigTool2

管理センターを有効にするには、adminCenter-1.0 機能および承認されたユーザーを追加する必要があります。また、セキュリティー上の理由から、Admin Center には HTTPS が必要なため、httpsPort および keyStore が設定されていることを確認する 必要 があります。

以下に例を示します。

<server description="Admin Center example">

  <!-- Enable features -->
  <featureManager>
    <feature>adminCenter-1.0</feature>
  </featureManager>

  <!-- To access this server from a remote client add a host attribute to the following element, e.g. host="*" -->
  <httpEndpoint id="defaultHttpEndpoint"
    host="*"
    httpPort="9080"
    httpsPort="9443" />

  <!-- Define a user with Administrator role -->
  <quickStartSecurity userName="admin" userPassword="adminpwd" />

  <keyStore id="defaultKeyStore" password="Liberty"/>

</server>

サーバーが起動すると、https://host_name:port_number/adminCenter/ 経由で Admin Center のログインページにアクセスすることができます。これ により、ループバックアドレスが localhost にマッピングされると、サーバーを実行するマシン https://localhost:9443/adminCenter/ に移動できます。

注記: ブラウザーに、自己署名証明書の使用により受け入れる必要があるセキュリティープロンプトが表示される場合があります。

ui login

提供されているさまざまなツールや機能について、特に管理センターに関するブログように調整しています。

1.3. MicroProfile Context Propagation 1.2

MicroProfile Context Propagation はスタンドアロン MicroProfile 仕様です。MicroProfile Context Propagation を使用すると、スレッドコンテキストに対して決定論的に動作させる補完ステージを作成し、非同期依存ステージの Open RUN グローバルスレッドプールの自動調整を活用できます。

MicroProfile Context Propagation の 1.2 リリースは、特に MicroProfile Config 2.0 が 空の値設定プロパティーを処理する方法の違いに対応します。MicroProfile Config を使用して MicroProfile Context Propagation のスレッドコンテキストタイプが空のリストでデフォルト値として使用する場合は、空の値ではなく None の値を使用します。MicroProfile Config 2.0 の空の値は、小さい設定ソースをオーバーライドし、代わりにプロパティーにビルトインのデフォルト値を使用することを意味します。たとえば、mp.context.ManagedExecutor.cleared=None と mp.context.ManagedExecutor.propagated=Remaining を指定すると、すべてのコンテキストタイプが伝播され ます。

MicroProfile Context Propagation 1.2 機能を有効にするには、サーバー設定に以下を追加します。

<featureManager>
  <feature>mpContextPropagation-1.2</feature>
  <!-- other features used by example code... -->
  <feature>servlet-4.0</feature>
  <feature>jdbc-4.2</feature>
  <feature>jndi-1.0</feature>
</featureManager>

サーブレット内での使用例:

private ManagedExecutor executor;

public void init(ServletConfig config) throws ServletException {
    executor = ManagedExecutor.builder()
                .propagated(ThreadContext.APPLICATION)
                .cleared(ThreadContext.ALL_REMAINING)
                .build();
}

public void destroy() {
    executor.shutdownNow();
}

public void doGet(HttpServletRequest req, HttpServletResponse resp)
    throws ServletException, IOException {
    ...
    executor.copy(unmanagedCompletionStage).thenAcceptAsync(value -> {
        // requires java:comp namespace of the application,
        DataSource ds = InitialContext.doLookup("java:comp/env/jdbc/ds");
        ...
    });
}

詳細は、* MicroProfile Context Propagation 1.2 仕様 * JavaDocを参照してください。

1.4. LDAP 接続は Kerberos 認証をサポートします。

LDAP バインド操作は、ディレクトリーサーバーにクライアント(およびその背後でのアプリケーションやアプリケーション)を認証するために使用されます。これにより、その接続で処理される後続の操作に使用される承認アイデンティティーが確立され、クライアントが使用する LDAP プロトコルバージョンが指定されます。今回の更新以前は、LdapRegistry 要素 は匿名でバインディング、またはユーザー(bindDN)およびパスワード(bindPassword)での簡易認証の使用をサポートしていました。今回の更新で、LDAP: GSSAPI/Kerberos にバインドするオプションが追加されました。Kerberos は、クライアントがキー配布センター(KDC)で認証できるようにする認証メカニズムです。Open RUN 21.0.0.4 では、Kerberos 認証情報キャッシュ(ccache)または Kerberos キータブファイルのいずれかを使用できます。

GSSAPI/Kerberos オプションを使用 するよう に LdapRegistry を更新するには、新しい LdapRegistry 属性 である bindAuthMechanism を使用して、バインド認証メカニズムタイプを設定し ます

bindAuthMechanism="GSSAPI"

Kerberos プリンシパルまたはサービスプリンシパル名も必要です。

krb5Principal="user1@EXAMPLE.COM"

認証情報キャッシュまたは ccache も呼ばれる Kerberos チケットキャッシュを使用している場合は、Kerberos チケットキャッシュファイル名を、新しい属性 krb5TicketCache の LdapRegistry に追加します

krb5TicketCache="${server.config.dir}/security/krb5-user1.cc"

Kerberos 要素を使用して Kerberos 設定ファイル名(krb5.conf、krb5.ini など)を設定します。

<kerberos configFile="${server.config.dir}/security/krb5.conf"/>

Kerberos キータブファイルを使用している場合は、Kerberos 要素を使用して Kerberos キータブファイル名を設定します。

<kerberos keytab="${server.config.dir}/security/krb5.keytab" configFile="${server.config.dir}/security/krb5.conf"/>

Kerberos 設定ファイルが Kerberos 要素に定義されていない場合、Open RUN は JDK のデフォルトの場所を使用して設定ファイルの場所を解決しようとします。

Kerberos 認証情報では、場所はチケットキャッシュ(指定されている場合)、設定済みのキータブファイル、JDK のデフォルトの場所など順にチェックされます。

以下の例は、Kerberos チケットキャッシュおよび Kerberos 設定ファイルを使用して LdapRegistry 要素 を設定する方法を示しています。

<kerberos configFile="${server.config.dir}/security/krb5.conf"/>

<ldapRegistry id="LDAP" realm="SampleLdapADRealm" host="ldap_hostname" port="389" ignoreCase="true" baseDN="DC=example,DC=com" bindAuthMechanism="GSSAPI" krb5Principal="user1@EXAMPLE.COM" krb5TicketCache="${server.config.dir}/security/krb5-user1.cc" ldapType="Custom" />

以下の例は、Kerberos キータブおよび Kerberos 設定ファイルを使用して LDAP レジストリーを設定する方法を示しています。

<kerberos keytab="${server.config.dir}/security/krb5.keytab" configFile="${server.config.dir}/security/krb5.conf" />

<ldapRegistry id="LDAP" realm="SampleLdapADRealm" host="ldap_hostname" port="389" ignoreCase="true" baseDN="DC=example,DC=com" bindAuthMechanism="GSSAPI" krb5Principal="user1@EXAMPLE.COM" ldapType="Custom" />

アプリケーションでこの新機能を有効にするには、LDAP User Registry 3.0 機能を server.xml ファイルに追加します。

<featureManager>
  <feature>ldapRegistry-3.0</feature>
</featureManager>

LdapRegistry の詳細は、LDAP User Registry のドキュメント参照してください

1.5. シングルサインオン(SSO)LTPA および JWT による認証フィルター

この新しい拡張機能ユーザーは認証フィルターを使用して、SSO 認証に LTPA および JWT を使用する必要がある HTTP サーブレットリクエストを選択できるようになりました。

ユーザーは認証フィルターを設定して、保護されたリソースの特定の要求が LTPA で認証されるかどうかを指定します。要求が認証フィルターで指定された基準を満たす場合、要求は LTPA で認証でき、保護されているリソースにアクセスできます。逆に、LTPA 認証フィルターで設定される基準にリクエストが満たされない場合には、ログイン認証情報を指定するよう求められます。

<ltpa keysFileName="yourLTPAKeysFileName.keys" keysPassword="keysPassword" expiration="120" authFilterRef="myAuthFilter"/>

<authFilter id="myAuthFilter">
         <requestUrl id="myRequestUrl" urlPattern="/SimpleServlet" matchType="contains"/>
</authFilter>

上記の例では、要求には、/SimpleServlet パターン を含む LTPA クッキーと URL が LTPA SSO 認証によって認証されます。ただし、リクエストに LTPA クッキーがある場合、URL には /SimpleServlet パターンが含まれないと、 他の認証メカニズムによって認証されます。

または、ユーザーは認証フィルターを設定して、保護されたリソースの特定の要求が JWT SSO で認証されているかどうかを指定できます。要求が認証フィルターで指定された基準を満たす場合、要求は保護されたリソースにアクセスするために JWT で認証できます。逆に、JWT SSO 認証フィルターで設定される基準にリクエストが満たされない場合には、ログインクレデンシャルを指定するよう求められます。

<jwtSso cookieName="myjwt" jwtBuilderRef="myBuilder" authFilterRef="myAuthFilter"/>
<authFilter id="myAuthFilter">
         <requestUrl id="myRequestUrl" urlPattern="/SimpleServlet" matchType="notContain"/>
</authFilter>

上記の例では、LTPA 認証フィルターの例と同じです。/SimpleServlet パターン を含む JWT cookie および URL は JWT SSO 認証によって認証されます。ただし、リクエストに JWT クッキーがあるものの、URL に /SimpleServlet パターンが含まれない場合は、 他の認証メカニズムによって認証されます。

詳細は、以下を参照してください。

1.6. Request Timing 機能でハングした要求のスレッドダンプコレクションの制御

Request Timing 機能(requestTiming-1.0)は、要求の期間が設定されたしきい値を超えた場合に診断情報を提供します。時間の経過と共に要求を監視する手段を提供します。この機能は、処理が遅いリクエストを自動的に検出して、詳細な診断情報(警告メッセージ、スレッドスタック、およびスレッドダンプの作成)を提供します。

Request Timing 機能でハングリクエストが検出されると、警告メッセージがメッセージログファイルに書き込まれ、リクエスト中に発生したイベントのダンプが書き込まれます。それまでは、3 つのスレッドダンプのセットが開始し、1 分は離れます。3 つのスレッドダンプが完了すると、新しい要求がハングしている場合にのみさらに 3 つのスレッドダンプのセットが作成されます。

一部の運用チームでは、長期に認識される要求のパフォーマンスオーバーヘッドにより、多くのスレッドダンプが生成されたくないものもあります。以前の Open RUN リリースでは、スレッドダンプの生成を無効にするオプションがありませんでした。

21.0.0.4 では、Request Timing 機能はスレッドダンプを収集するかどうかを制御します。新しい enableThreadDumps Request Timing server configuration 属性を false に設定すると、スレッドダンプはハングアップ要求時に作成されません。EnableThreadDumps が true に設定されている、または指定されていない場合は、スレッドダンプは引き続き作成されます。

新しい Request Timing server configuration 属性は、以下のように server.xml で設定できます。

<requestTiming includeContextInfo="true" slowRequestThreshold="120s" hungRequestThreshold="10s" sampleRate="1" enableThreadDumps="false"></requestTiming>`

enableThreadDumps サーバー 設定属性は 以下のように組み込みリクエスト Timing サブ要素 <servletTiming/> または <jdbcTiming/> で使用することもできます。

<requestTiming includeContextInfo="true" slowRequestThreshold="120s" hungRequestThreshold="10s" sampleRate="1">
    <servletTiming appName="MyApp" servletName="MyServletApp" slowRequestThreshold="100s" hungRequestThreshold="5s" enableThreadDumps="false"/>
</requestTiming>`
注記

server.xml ファイルの組み込み <servletTiming/> または <jdbcTiming/> 設定 により、<requestTiming/> で定義された遅延およびハング要求しきい値が上書きされ ます

Request Timing 機能の詳細は、以下のドキュメントを参照してください。

1.7. リークした接続の自動クリーンアップ

リクエストの最後にアプリケーションによって開かれる、共有できない接続を自動的に検出し、閉じる機能を使用して、接続管理が強化されます。

アプリケーションコードは、取得する暗号化不可能な接続を閉じることを忘れる可能性があり、これにより、他のリクエストで使用するために接続が接続プールに返されないことがあります。時間が経つと、これらの接続が漏えいされた接続は低下し、最終的に接続プールを消費する可能性があります。接続管理では、このようなリークした接続を検出して自動的に閉じるようになり、これが発生しないようにできるようになりました。

この新機能を活用するには、connectionManager 要素を使用する cairo 機能のいずれかを設定 ます。たとえば、JDBC の場合:

<featureManager>
  <feature>jdbc-4.2</feature>
  <feature>jndi-1.0</feature>
  <!-- more features -->
</featureManager>

新しい機能を自動的に活用するデータソースおよび接続ファクトリーを設定します(無効にするには、<connectionManager> に autoCloseConnections ="false" を設定し ます)。

<dataSource id="DefaultDataSource">
  <connectionManager maxPoolSize="10"/>
  <jdbcDriver libraryRef="PostgreSQL"/>
  <properties.postgresql databaseName="TESTDB" serverName="localhost" portNumber="5432"/>
</dataSource>

<library id="PostgreSQL">
  <file name="/usr/local/postgresql/postgresql-42.2.18.jar"/>
</library>

詳細は、Open RUN Connection Manager ドキュメントを参照してください。

1.7.1. 拡張されたアプリケーションの場所を指定します。

この拡張機能ユーザーは、autoExpand 属性 が "true" に設定されている場合に、applicationManager 設定の展開場所(expandLocation)を指定できるようになりました。現在実装されているように、アプリケーションが自動展開されたファイルのデフォルトの場所は ${server.config.dir}/apps/expanded/ にハードコーディングされます。

今回の機能拡張により、ファイルシステム上の新しい値に場所を設定できるようになりまし 。たとえば、以下の設定スニペットにより、アプリケーションは ${server.config.dir}/myApps/{appname}/ で拡張されました。

  <applicationManager autoExpand="true" expandLocation="${server.config.dir}/myApps/" />

今回の機能拡張により、拡張されたアプリケーションの場所について、ユーザーは柔軟性が向上しました。

詳細は、「 Open RUN Application Manager Documentation」を参照してください。

第2章 解決された問題

リリースで解決した Open RUN 21.0.0.4 の問題を参照して ください。

第3章 修正された CVE

Open RUN 21.0.0.4 で修正された CVE の一覧は、「 セキュリティーの脆弱性 」を参照してください。

第4章 既知の問題

21.0.0.4 の開発中は見つかった問題の一覧を参照してください