Podman上のゲートウェイ

PodmanへのKeeperゲートウェイのインストール手順

概要

本ページでは、Podman上にKeeperゲートウェイをインストール、設定、更新する手順を説明します。KeeperゲートウェイのコンテナはRocky Linux 9のベースイメージを基にビルドされ、DockerHubで配布されています。

PodmanはOCI互換で、常駐デーモンを使わないコンテナエンジンです。Dockerと同じ keeper/gateway イメージをそのまま利用でき、イメージ側の変更は不要です。Dockerとの主な違いは、docker.io/ のレジストリ接頭辞、SELinux向けのボリュームラベル :Z、バックグラウンドデーモンではなく systemd によるサービス管理です。

要件

PAMの全機能を利用するには、x86 AMDプロセッサーを搭載したLinuxホストが必要
podman がインストールされていること (バージョン4.0以上が必須、5.0以上を推奨)
Compose方式を使う場合のみ podman-compose がインストールされていること

Podmanは、RHEL 9、Fedora 39以降、Rocky 9、Alma 9に標準で同梱されています。Ubuntu 24.04以降およびDebian 12以降では、ディストリビューション付属のパッケージリポジトリからインストールしてください。

Podmanのインストール

RHEL / Alma / Rocky / Fedora

sudo dnf install -y podman

Ubuntu / Debian

sudo apt update && sudo apt install -y podman

インストールできたかは、以下で確認します。

podman --version

ゲートウェイの作成

新しいゲートウェイは、ウェブボルトまたはデスクトップアプリで [新規作成] > [ゲートウェイ] をクリックして作成できます。

コマンダーのCLIからゲートウェイと構成ファイルを作成することもできます。

pam gateway new -n "<Gateway Name>" -a <Application Name or UID> -c b64

アプリケーション名とUIDは secrets-manager app list で確認できます。

インストールのオプション

Podman上にゲートウェイをセットアップする方法は以下の2通りです。

Podman Composeによるインストール
手動インストール

オプション1: Podman Composeによるインストール

Docker Composeに近い手順で進める場合は podman-compose を使います。

手順1. podman-composeのインストール

RHEL / Alma / Rocky / Fedora

sudo dnf install -y podman-compose

Ubuntu / Debian

sudo apt install -y podman-compose

手順2. Composeファイルの作成

作業用ディレクトリを作成し、その中にComposeファイルを置きます。

sudo mkdir -p /opt/keeper-gateway && cd /opt/keeper-gateway

以下の内容で docker-compose.yml という名前のファイルを作成します。

services:
  keeper-gateway:
    platform: linux/amd64
    image: docker.io/keeper/gateway:latest
    container_name: keeper-gateway
    shm_size: 16g
    security_opt:
      - seccomp:docker-seccomp.json
    environment:
      LC_ALL: "C.UTF-8"
      ACCEPT_EULA: Y
      GATEWAY_CONFIG: XXXXXXXXXXXXXXXXX
    volumes:
      - gateway-data:/etc/keeper-gateway:Z

volumes:
  gateway-data:

shm_size は重要なパラメータです。利用可能なサーバーメモリの少なくとも半分まで増やすことを推奨します。本番のゲートウェイには、可能な限り多くのメモリとCPUを割り当ててください。リモートブラウザ分離セッションでは、Chromiumがプロセスごとに多くのメモリを消費します。

必須の環境変数は GATEWAY_CONFIG のみです。ゲートウェイ作成時にKeeperから示されるBase64エンコード済みの構成を指定します。

注 — SELinuxを使用するホスト (RHEL / Fedora / Rocky / Alma): ボリュームマウントの :Z 接尾辞は必須です。適切なSELinuxラベルが付与され、コンテナからマウント先ディレクトリにアクセスできるようになります。SELinuxを使わないシステム (Ubuntu / Debian) では指定しても支障はなく、そのまま残して問題ありません。

Ubuntu/Debianでは、security_opt に - apparmor:gateway-apparmor-profile を追加し、以下の手順4に従ってAppArmorプロファイルをダウンロードして有効化してください。

手順3. Seccompファイルのダウンロード

docker-seccomp.json ファイルをダウンロードし、Composeファイルと同じフォルダに配置します。

ファイルをダウンロードするか、以下を実行します。

curl -O https://raw.githubusercontent.com/Keeper-Security/KeeperPAM/refs/heads/main/gateway/docker-seccomp.json

手順4. AppArmorプロファイル (Ubuntu/Debian系ディストリビューションで必須)

この手順は、UbuntuおよびDebian系ディストリビューションで必須です。その他のLinuxディストリビューション (RHEL、CentOS、Fedora、Amazon Linuxなど) では、手順5へ進んでください。

gateway-apparmor-profile ファイルをComposeファイルと同じフォルダに配置します。

ファイルをダウンロードするか、以下を実行します。

curl -O https://raw.githubusercontent.com/Keeper-Security/KeeperPAM/refs/heads/main/gateway/gateway-apparmor-profile

以下のコマンドでプロファイルを読み込み、/etc/apparmor.d/ に配置します。

sudo apparmor_parser -r gateway-apparmor-profile
sudo cp gateway-apparmor-profile /etc/apparmor.d/

手順5. サービスの起動

docker-compose.yml と docker-seccomp.json を保存したフォルダにいることを確認してください。以下のコマンドでKeeperゲートウェイをバックグラウンドで起動します。

cd /opt/keeper-gateway
sudo podman-compose up -d

Dockerとは異なり、podman-compose はComposeファイル内の restart: ディレクティブを解釈しません。ホスト再起動後もゲートウェイを上げるには、後述の「再起動時にゲートウェイを自動起動する」の手順をご参照ください。

オプション2: Podmanの手動インストール

Composeファイルを使わずコンテナを直接実行する場合は、以下の手順に従います。

手順1. ゲートウェイのイメージ取得

sudo podman pull docker.io/keeper/gateway:latest

Podmanでは、Docker Hubからイメージを取得するときに docker.io/ のレジストリ接頭辞を明示する必要があります。省略すると、/etc/containers/registries.conf の設定により、Docker Hub以外のレジストリが先に検索対象になることがあります。

手順2. Seccompファイルのダウンロード

curl -O https://raw.githubusercontent.com/Keeper-Security/KeeperPAM/refs/heads/main/gateway/docker-seccomp.json

手順3. AppArmorプロファイル (Ubuntu/Debianのみ)

この手順は、UbuntuおよびDebian系ディストリビューションで必須です。その他のLinuxディストリビューションでは、手順4へ進んでください。

curl -O https://raw.githubusercontent.com/Keeper-Security/KeeperPAM/refs/heads/main/gateway/gateway-apparmor-profile
sudo apparmor_parser -r gateway-apparmor-profile
sudo cp gateway-apparmor-profile /etc/apparmor.d/

手順4. コンテナの起動

Keeperゲートウェイのコンテナを実行します。

sudo podman run -d \
    --name keeper-gateway \
    --shm-size=16g \
    --security-opt seccomp=docker-seccomp.json \
    -e LC_ALL="C.UTF-8" \
    -e ACCEPT_EULA=Y \
    -e GATEWAY_CONFIG="XXXXXXXXXXXXXXXXX" \
    -v gateway-data:/etc/keeper-gateway:Z \
    docker.io/keeper/gateway:latest

--shm-size は重要なパラメータです。利用可能なサーバーメモリの少なくとも半分まで増やすことを推奨します。

XXXXXXXXXXXXXXXXX は、ゲートウェイ作成時にKeeperから示されるBase64エンコード済みの構成に置き換えてください。

Ubuntu/Debianでは、AppArmor用のセキュリティオプションを付与したコマンドを使います。

sudo podman run -d \
    --name keeper-gateway \
    --shm-size=16g \
    --security-opt seccomp=docker-seccomp.json \
    --security-opt apparmor=gateway-apparmor-profile \
    -e LC_ALL="C.UTF-8" \
    -e ACCEPT_EULA=Y \
    -e GATEWAY_CONFIG="XXXXXXXXXXXXXXXXX" \
    -v gateway-data:/etc/keeper-gateway:Z \
    docker.io/keeper/gateway:latest

ログ

Keeperゲートウェイのログを確認するには、以下を実行します。

sudo podman logs keeper-gateway

ボルト内の [シークレットマネージャー] 画面から [アプリケーション] > [ゲートウェイ] へ移動すると、ゲートウェイが [オンライン] と表示されます。

ゲートウェイサービスの管理

サービスの起動

sudo podman start keeper-gateway

サービスの停止

sudo podman stop keeper-gateway

サービスの再起動

sudo podman restart keeper-gateway

ゲートウェイコンテナへの接続

sudo podman exec -it keeper-gateway bash

再起動時にゲートウェイを自動起動する

Podmanはバックグラウンドデーモンを使いません。Composeファイルの restart: ディレクティブや podman run の --restart フラグは、ホストの再起動をまたいでは適用されません。ゲートウェイをOS起動時に確実に立ち上げるには、systemdのサービスユニットを生成します。

root権限あり (推奨)

sudo podman generate systemd --name keeper-gateway --new --files
sudo mv container-keeper-gateway.service /etc/systemd/system/
sudo systemctl daemon-reload
sudo systemctl enable container-keeper-gateway.service
sudo systemctl start container-keeper-gateway.service

--new フラグは、停止済みコンテナを再利用するのではなく、起動のたびにイメージから新しいコンテナを作るよう systemd に指示します。再起動後にイメージを更新した内容が反映されやすくなります。

root権限なし (代替)

Podmanをroot権限なしで実行する場合は、ユーザーの systemd にユニットを置きます。

podman generate systemd --name keeper-gateway --new --files
mkdir -p ~/.config/systemd/user/
mv container-keeper-gateway.service ~/.config/systemd/user/
systemctl --user daemon-reload
systemctl --user enable container-keeper-gateway.service
systemctl --user start container-keeper-gateway.service
loginctl enable-linger $(whoami)

loginctl enable-linger により、ユーザーセッションがなくてもユーザーサービスをブート時に起動できるようになります。

Ubuntu/Debianでは、再起動後もAppArmorプロファイルが読み込まれた状態になっているか確認してください。

sudo apparmor_parser -r gateway-apparmor-profile
sudo cp gateway-apparmor-profile /etc/apparmor.d/

再起動後、サービスが動いているかは以下で確認します。

sudo systemctl status container-keeper-gateway.service

デバッグ

ゲートウェイで詳細なデバッグログを有効にする場合は、コンテナ起動時に以下の環境変数を追加します。

sudo podman run -d \
    --name keeper-gateway \
    --shm-size=16g \
    --security-opt seccomp=docker-seccomp.json \
    -e LC_ALL="C.UTF-8" \
    -e ACCEPT_EULA=Y \
    -e GATEWAY_CONFIG="XXXXXXXXXXXXXXXXX" \
    -e KEEPER_GATEWAY_LOG_LEVEL="debug" \
    -e LOG_LEVEL="debug" \
    -v gateway-data:/etc/keeper-gateway:Z \
    docker.io/keeper/gateway:latest

または、podman-compose を使用している場合は、docker-compose.yml の environment セクションに変数を追加します。

services:
  keeper-gateway:
    .....
    environment:
      LC_ALL: "C.UTF-8"
      KEEPER_GATEWAY_LOG_LEVEL: "debug"
      LOG_LEVEL: "debug"

ログレベルを変更したら、コンテナを再起動します。

sudo podman restart keeper-gateway

以下のコマンドでKeeperゲートウェイのログを追跡表示できます。

sudo podman logs -f keeper-gateway

アップデート

まず、最新のイメージを取得します。

sudo podman pull docker.io/keeper/gateway:latest

続けて、運用方法に応じてサービスまたはコンテナを再起動します。

systemdを使っている場合 (推奨)

sudo systemctl restart container-keeper-gateway.service

コンテナのみ手動管理している場合

sudo podman stop keeper-gateway
sudo podman rm keeper-gateway
sudo podman run -d \
    --name keeper-gateway \
    --shm-size=16g \
    --security-opt seccomp=docker-seccomp.json \
    -e LC_ALL="C.UTF-8" \
    -e ACCEPT_EULA=Y \
    -v gateway-data:/etc/keeper-gateway:Z \
    docker.io/keeper/gateway:latest

初回の初期化後、ゲートウェイは永続ボリュームにデバイス鍵を保存します。ボリュームを維持する限り、以降の実行で GATEWAY_CONFIG を再度指定する必要はありません。

ヘルスチェック

ゲートウェイの稼働状況を外部から確認できるよう、ヘルスチェックを構成できます。コンテナのオーケストレーションやロードバランシング、自動監視と組み合わせやすくなります。設定手順と例はヘルスチェックをご参照ください。

ホストインスタンスへの接続

Keeperゲートウェイでは、ホストマシンへ接続したりトンネルを張ったりできます。--add-host に host.docker.internal:host-gateway を指定すると、コンテナからホスト宛てのセッションを張りやすくなります。

手動で podman run する例

sudo podman run -d \
    --name keeper-gateway \
    --shm-size=16g \
    --add-host host.docker.internal:host-gateway \
    --security-opt seccomp=docker-seccomp.json \
    -e LC_ALL="C.UTF-8" \
    -e ACCEPT_EULA=Y \
    -e GATEWAY_CONFIG="XXXXXXXXXXXXXXXXX" \
    -v gateway-data:/etc/keeper-gateway:Z \
    docker.io/keeper/gateway:latest

または、docker-compose.yml に以下を追加します。

services:
  keeper-gateway:
    platform: linux/amd64
    image: docker.io/keeper/gateway:latest
    shm_size: 16g
    extra_hosts:
      - "host.docker.internal:host-gateway"
    security_opt:
      - seccomp:docker-seccomp.json
    environment:
      LC_ALL: "C.UTF-8"
      ACCEPT_EULA: Y
      GATEWAY_CONFIG: xxxxxxxx
    volumes:
      - gateway-data:/etc/keeper-gateway:Z

この設定を有効にすると、ホスト上のサービスへ接続しやすくなります。SSHで接続する場合の設定例です。

SSH秘密鍵を格納したPAMユーザーレコードを作成する
ホスト名を host.docker.internal 、ポートを 22 としたPAMマシンレコードを作成する
PAM設定で上記のPAMユーザーを参照し、SSH接続を有効にする

ホスト経由でのKeeperゲートウェイサービスのアップグレード

KeeperPAMからホストにSSHできる環境では、ゲートウェイのコンテナ更新をバックグラウンドで走らせてアップグレードできます。

sudo podman pull docker.io/keeper/gateway:latest
nohup sudo podman-compose up -d keeper-gateway &

Keeperゲートウェイは外向き接続のみを確立し、インバウンドのファイアウォール規則は不要です。以下の外向き接続を許可する必要があります。

送信先エンドポイント

必要なポート

補足

Keeperクラウド keepersecurity.[x] エンドポイント: US: .com EU: .eu AU: .com.au JP: .jp CA: .ca US_GOV: .us

TLS ポート443

ネイティブプロトコル (SSH、RDPなど) 経由で対象インフラにアクセスするため、Keeperクラウドと通信します

Keeperルーター connect.keepersecurity.[x] エンドポイント: US: .com EU: .eu AU: .com.au JP: .jp CA: .ca US_GOV: .us

TLS ポート443

セキュアなリアルタイムのWebSocket接続を確立するため、Keeperルーターと通信します

Keeper Stun/Turnサービス krelay.keepersecurity.[x] エンドポイント: US: .com EU: .eu AU: .com.au JP: .jp CA: .ca US_GOV: .us

TCPおよびUDPのポート3478。TCPおよびUDPのポート49152～65535への外向きアクセス

エンドユーザーのボルトと対象システムの間で、ゲートウェイ経由の安全な暗号化WebRTC接続を実現します

暗号化と復号はすべてゲートウェイ上で行われ、ゼロ知識の前提が保たれます。Keeperクラウドとの通信にはKeeperシークレットマネージャーAPIが用いられます。

ディスク容量の管理

ゲートウェイを何度も更新すると、使われなくなったコンテナイメージがホストに残りやすくなります。ディスクを圧迫しやすいので、空き容量の確認と未使用イメージの整理を定期的に行うことを推奨します。

ディスク使用量の確認

Keeperゲートウェイのサーバーで、現在のディスク使用量を確認するには以下のコマンドを実行します。

df -h

このコマンドは、マウントされているすべてのファイルシステムの空き容量を読みやすい形式で表示します。特にPodmanがデータを保存するパーティション (通常、root権限ありでは /var/lib/containers 、root権限なしでは ~/.local/share/containers ) に注目してください。

Podman固有のストレージ使用量は以下でも確認できます。

sudo podman system df

ディスクの空きが少なくなってきた場合 (たとえば使用率が80～90%を超えるなど)、古いイメージのクリーンアップを検討してください。

古いイメージの削除

Keeperゲートウェイを更新すると、Podmanは古いイメージをシステムに残します。未使用のイメージをすべて削除するには、以下のコマンドを使用します。

sudo podman image prune -a

-a フラグにより、コンテナから参照されていないイメージだけでなくすべての未使用イメージが削除されます。
確認プロンプトが表示された場合は、y と入力します。

出力例:

WARNING! This will remove all images without at least one container associated to them.
Are you sure you want to continue? [y/N] y
Deleted Images:
...
Total reclaimed space: 4.8GB

この操作は、実行中のいずれのコンテナからも使用されていない古いイメージを安全に削除します。

トラブルシューティング

現象

想定される原因

すぐできる対処

podman pull が "manifest unknown" で失敗

docker.io/ のレジストリ接頭辞がない

イメージ参照を docker.io/keeper/gateway:latest のように完全な形で指定する

Fedora/RHELでPermission denied

ボリュームにSELinuxラベル (:Z) がない

各ボリュームマウントに :Z を追加し、コンテナを再起動する

コンテナがすぐ終了する

GATEWAY_CONFIG が無効または期限切れ

sudo podman logs keeper-gateway を実行して出力を確認し、トークン期限切れなら構成を再生成する

ボルトでゲートウェイがオンラインにならない

DNSまたはファイアウォールが外向きHTTPSを遮断している

ホストから keepersecurity.com および connect.keepersecurity.com のポート443に到達できるか確認する

再起動後にサービスが停止する

Podmanは再起動をまたいで restart: を適用しない

systemdの手順に従いサービスユニットを生成する

rootレス: 127.0.0.1へのポートバインド

rootレスコンテナは既定でlocalhostにバインドする

root付きで実行する (sudo podman) か、手前にリバースプロキシ (nginx/HAProxy) を置く

"Error: name already in use"

同名の停止済みコンテナが残っている

新しいコンテナを作成する前に sudo podman rm -f keeper-gateway を実行する

原因が分からないときは sudo podman logs keeper-gateway で末尾の数行を確認してください。エラーの手がかりが出力されていることが多いです。

参考文献

DockerHubの一覧: https://hub.docker.com/r/keeper/gateway
Dockerでのゲートウェイ（クイックリファレンス）
LinuxへのDockerおよびDocker Composeのインストール（クイックリファレンス）
Keeperコネクションマネージャー向けのPodmanインストール

前へDocker上でのゲートウェイ次へLinuxネイティブ環境でのゲートウェイ

最終更新 1 か月前