KCM Version 2.12.0

2023年1月27日リリース

新機能と改善事項

KCM-83: kcm-setup.runスクリプトから、インストール後にdocker-compose.ymlを手動で編集することなく、シークレットの取得にKSMを使用するように直接デプロイを構成できるようになりました。セットアップ中に、KSMのワンタイムトークンまたはbase64エンコードされたKSM構成を入力するための追加のプロンプトが表示されます。

KCM-226: keeper/guacamole-ssl-nginxイメージで、環境変数CLIENT_CERTIFICATE_FILEを指定することで、SSL/TLSクライアント認証を必須にできるようになりました。ブラウザがこの証明書によって署名された秘密鍵にアクセスできる場合にのみ、そのブラウザからNGINXへ接続できます。

この変数は、コンテナ内のファイルを指定する点で環境変数CERTIFICATE_FILEと似ていますが、こちらはクライアントの秘密鍵を認証するために使用する証明書を制御します。

SSL/TLS認証の動作をさらに調整するための追加の環境変数も用意されています。

変数	説明	デフォルト値
ADDITIONAL_PROXY_CONFIG	NGINXがGuacamoleへのプロキシを構成するlocationブロック内に追加で含められる、任意のNGINX設定ステートメントです。
SSL_VERIFY_CLIENT	NGINXのssl_verify_clientディレクティブが提供する設定に基づき、クライアント (ブラウザ) が提示する証明書をNGINXが要求・検証するかどうか、およびその方法を制御します。	on
SSL_VERIFY_DEPTH	NGINXのssl_verify_depthディレクティブが提供する設定に基づき、クライアントの証明書を検証する際に、NGINXがクライアントの証明書チェーンをどこまで遡って確認するかを制御します。	1

KCM-227: SSL終端における複数ホスト名/構成への対応

keeper/guacamole-ssl-nginxイメージは、KeeperがKCM向けに提供するGuacamoleイメージのSSL終端を行うためのイメージです。これまでは、1つのホスト名と構成のみに対応していました。

ssl:
        image: keeper/guacamole-ssl-nginx:2
        restart: unless-stopped
        ports:
            - "80:80"
            - "443:443"
        environment:
            SELF_SIGNED: "Y"
            ACCEPT_EULA: "Y"
            CONTENT_TYPE_OPTIONS: "Y"
            CONTENT_SECURITY_POLICY: "Y"
            GUACAMOLE_HOSTNAME: "guacamole"
            SSL_HOSTNAME: "example.net"

KCM 2.12.0からは、YAML (またはJSON) を受け付ける専用の環境変数SERVERSを使用することで、keeper/guacamole-ssl-nginxイメージを複数のホスト名・構成で使用できるようになりました。

SERVERS変数には、それぞれの追加構成に適用する環境変数の名前と値のペアを含むオブジェクトの、YAML (またはJSON) 配列を指定する必要があります。**指定されていない変数は、トップレベルの環境から継承されます。**以下はその例です。

    ssl:
        image: keeper/guacamole-ssl-nginx:2
        restart: unless-stopped
        ports:
            - "80:80"
            - "443:443"
        environment:
            SELF_SIGNED: "Y"
            ACCEPT_EULA: "Y"
            CONTENT_TYPE_OPTIONS: "Y"
            CONTENT_SECURITY_POLICY: "Y"
            GUACAMOLE_HOSTNAME: "guacamole"
            
            SERVERS: |
               - SSL_HOSTNAME: "example.net"
               - SSL_HOSTNAME: "*.example.net"

上記の構成では、example.netと*.example.netの両方のホスト名を同等に処理するNGINXインスタンスになります。SELF_SIGNEDがYに設定されているため、どちらにもそれぞれ自己署名証明書が発行されます。

より複雑な例です。

    ssl:
        image: keeper/guacamole-ssl-nginx:2
        restart: unless-stopped
        ports:
            - "80:80"
            - "443:443"
        environment:
            ACCEPT_EULA: "Y"
            CONTENT_TYPE_OPTIONS: "Y"
            CONTENT_SECURITY_POLICY: "Y"
            GUACAMOLE_HOSTNAME: "guacamole"
            
            SERVERS: |
               - SSL_HOSTNAME: "example.net"
                 LETSENCRYPT_ACCEPT_TOS: "Y"
                 LETSENCRYPT_EMAIL=[e-mail]

               - SSL_HOSTNAME: "*.example.net"
                 SELF_SIGNED: "Y"

上記の構成では、*.example.netには自己署名証明書を生成して使用し、example.netにはLet's Encryptから取得した証明書を使用するNGINXインスタンスになります。

SERVERSの値は文字列である必要があるため、上記の例では|記号を使用しています。この記号を省略すると、それに続くYAMLはオブジェクトとして解析されてしまい、Dockerの環境変数はすべて文字列である必要があるため、docker-compose.ymlの検証に失敗します。

設定済みのホスト名に一致しないリクエストに対しては、NGINXは最初のサーバーをデフォルトとして使用します。SERVERSで宣言したいずれかのサーバーをこの動作にする場合は、そのサーバーを最初に記載する必要があります。

バグ修正

• KCM-223: 共有接続に参加する際、参加したクライアントが (現在の画面表示のコピーを受信できず) ハングしたように見え、セッション内で画面表示に何らかの変化が起きるまでこの状態が続く不具合。
• KCM-213: 「User Time Zone」の設定を特定のタイムゾーンに変更した後、そのタイムゾーンをクリアしようとしても、実際にはクリアされずに、以前設定されていたタイムゾーンに戻ってしまう不具合。