Kubernetes上のゲートウェイ
Helmを使用してKubernetes上にKeeperゲートウェイをインストールする手順
概要
Keeper Securityがメンテナンスする公式Helmチャートを使用すると、任意のKubernetesクラスタ上にKeeperゲートウェイを展開できます。チャートはゲートウェイをKubernetes Deployment として実行し、リモートアクセス (RDP、SSH、VNC)、リモートブラウザ分離、シークレットローテーション、検出など、ゲートウェイの全機能を利用できます。セッション録画用の永続ストレージ、Horizontal Pod Autoscaling、評価用の使い捨てデモターゲットも任意で追加できます。
接続はKeeperインフラストラクチャへアウトバウンドのみとなります。Ingress、LoadBalancer、インバウンドのファイアウォールルールは不要です。
チャートはKeeper HelmリポジトリとDocker Hub (OCIアーティファクト) の両方に公開されています。
Helmリポジトリ:
https://keeper-security.github.io/helm-chartsOCIレジストリ:
oci://registry-1.docker.io/keeper/keeper-gatewayArtifactHub: keeper-security/keeper-gateway
チャートのソースコードは GitHub で公開されています。
要件
Kubernetesクラスタ (バージョン 1.25以降)
特権アクセスマネージャー アドオン付きのKeeperエンタープライズアカウント
Keeperボルトから取得したゲートウェイ構成 (Base64) (下記のゲートウェイの作成をご参照ください)
ゲートウェイの作成
ウェブボルトまたはデスクトップアプリから [新規作成] > [ゲートウェイ] をクリックして、新しいゲートウェイの展開を作成できます。プロビジョニング時に Docker 方式を選択し、Base64構成 をコピーします。これがチャートで必要となる値です。
KeeperコマンダーCLIからゲートウェイとその構成を作成することもできます。
アプリケーション名とUIDは secrets-manager app list で確認できます。Base64構成トークンを保存し、以下の手順でチャートに指定します。
プロビジョニングの詳細については、Keeperゲートウェイの作成をご参照ください。
プロビジョニング時に [サンプルレコードを作成] を選択すると、チャートの任意デモ/プレイグラウンドサービスに対応するサンプルPAMレコードを生成できます。
インストール
HelmリポジトリまたはOCIレジストリからチャートをインストールします。gateway.acceptEula=Y を設定し、前の手順で取得したBase64構成を指定します。
--set gateway.config を指定すると、構成がシェル履歴および helm get values の出力に残ります。本番環境では、Kubernetes Secretに構成を保存してください (ゲートウェイ構成の指定をご参照ください)。
ゲートウェイ構成の指定
ゲートウェイ構成は3つの方法で指定できます。いずれの場合もEULAへの同意 (gateway.acceptEula=Y) が必要です。
Base64構成を直接指定します。評価および非本番用途に適しています。
構成を別途管理するKubernetes Secretに保存します。シェル履歴やHelmリリースの値から構成を除外できます。
Secret内のキーはデフォルトで gateway-config です。gateway.existingSecretKey で上書きできます。
起動時にAWS Secrets Managerから構成を読み込む設定です。IRSA を介してIAMロールをバインドし、Podにアクセス権を付与します。
AWS Secrets Managerへの構成の保存方法および必要なIAMポリシーについては、AWS KMSを使用したゲートウェイ構成をご参照ください。
確認
Podが稼働し、Keeperに接続されていることを確認します。
ゲートウェイのステータスは、Keeperボルトのゲートウェイ画面でもオンラインと表示されます。
ロギング
logging 値でログレベルとフォーマットを設定します。レベルは個別に上書きしない限り、ゲートウェイサービスと guacd の両方に適用されます。
レベル:
error、warning、info、debug(guacdはtraceも対応)フォーマット:
text、json、logfmt、cef、leef、rfc5424、rfc3164、gelf
logging.gatewayLevel と logging.guacdLevel でレベルを個別に設定できます。syslogサーバーへログを転送する場合は、syslog.enabled=true および syslog.host / syslog.port / syslog.proto の値を設定します。
構造化ログフォーマット (json、logfmt、cef など) には、比較的新しいゲートウェイイメージ (1.8.0以降) が必要です。チャートが古い appVersion を固定している場合は、イメージを上書きしてください: --set image.tag=1.8.0。
イベント監視およびSIEM転送については、アラートとSIEM連携をご参照ください。
ヘルスチェック
チャートには、コンテナ内でゲートウェイ組み込みの keeper-gateway health-check コマンドを実行するKubernetesの起動、生存、準備完了プローブが含まれます。ヘルスチェックHTTPサーバーはポート 8099 の 127.0.0.1 (localhostのみ) にバインドされます。
ヘルスチェックはデフォルトで有効です。外部監視ツールへ /health エンドポイントを公開する場合は、healthCheck.authToken (または healthCheck.existingAuthTokenSecret) で認証トークンを設定し、service を調整します。
エンドポイントの応答形式およびCLIオプションについては、ヘルスチェックをご参照ください。
更新
最新のチャートを取得し、リリースをアップグレードします。
デフォルトの Recreate 戦略では、新しいPodが起動する前に既存のPodが終了するため、アップグレード中にアクティブなセッションは切断されます。ダウンタイムゼロでアップグレードする場合は、RollingUpdate 戦略で複数レプリカを実行してください (スケーリングと高可用性をご参照ください)。
コマンドラインで gateway.config を指定して構成を渡した場合は、アップグレード時に再度指定するか、gateway.existingSecret への切り替えを検討してください。指定しないと構成が失われることがあります。
スケーリングと高可用性
複数レプリカを実行するには、事前にKeeper側でゲートウェイをマルチインスタンス運用向けに構成する必要があります。Keeperコマンダーで pam gateway list を実行してゲートウェイUIDを確認し、最大インスタンス数を設定します。
マルチインスタンスのスケーリングは現在、Keeperコマンダーでのみ管理できます。ウェブボルトおよびデスクトップアプリでの管理は近日対応予定です。
マルチインスタンスを有効化したら、固定レプリカ数またはHorizontal Pod Autoscalerでデプロイメントをスケールし、RollingUpdate 戦略に切り替えます。
スケールされたデプロイメントでは、クライアントのトラフィックを同じPodに維持するために sessionAffinity=ClientIP を設定し、Pod Disruption Budget (podDisruptionBudget.enabled=true) の有効化も検討してください。すべてのレプリカは同じゲートウェイ構成を使用します。
ゲートウェイプールがセッションを分散およびフェイルオーバーする仕組みについては、スケーリングと高可用性をご参照ください。
セッション録画ストレージ
セッション録画は暗号化 (AES-256-GCM) され、セッション中にリアルタイムでKeeperへストリーミングされるため、Podが再起動しても録画は失われません。ストリーミングバッファには一時的なローカルディレクトリが使用されます。ディスク容量が限られるノードや多数の同時セッションがある場合は、このバッファ用に永続ボリュームをアタッチしてください。
リモートブラウザ分離 (Chromium) セッションに必要な /dev/shm 共有メモリボリュームはデフォルトで有効です (sharedMemory.enabled=true、sharedMemory.sizeLimit=2Gi)。RBIやRDPを多用する場合はサイズ制限を増やしてください。
KeeperAI脅威検出 (任意)
大規模言語モデルを使用して特権セッションを監視し、疑わしいコマンドをリアルタイムでフラグ付けできます。APIキーはKubernetes Secretに保存されます。
対応プロバイダには、OpenAI、Anthropic、Azure OpenAI、Google AI、Vertex AI、AWS Bedrock、および任意のOpenAI互換エンドポイント (openai-generic 経由) が含まれます。クラウドネイティブ認証 (IRSAを使用したAWS Bedrock、Workload Identityを使用したVertex AI) には、ai.apiKey の代わりに serviceAccount.annotations と ai.existingSecret または extraEnv を使用してください。詳細についてはKeeperAIをご参照ください。
コーポレートプロキシ / カスタムCA証明書
ネットワークでSSLインスペクション (Zscalerなど) が使用されている場合、ゲートウェイがアウトバウンド接続を確立するには、組織のCA証明書が必要です。
または caCertificates.existingConfigMap で既存のConfigMapを参照します。起動時にこれらの証明書が信頼ストアへインストールされます。
セキュリティコンテキスト
ゲートウェイには、以下の2つの理由により昇格された権限が必要です。
起動時: エントリポイントはrootとして実行され、CA証明書とPythonパッケージをインストールした後、サービス起動前に
keeper-gwユーザーへ権限を降格します。RBIセッション: CEF/ChromiumにはLinux名前空間の分離 (
unshare、mount、clone) が必要であり、CAP_SYS_ADMINと制限のないseccompプロファイルが必要です。
チャートのデフォルトは、ケーパビリティ SYS_ADMIN、SYS_CHROOT、SETUID、SETGID、seccompProfile: Unconfined、appArmorProfile: unconfined です。
runAsNonRoot: true または runAsUser は設定しないでください。クラスタでPod Security Standardsが適用されている場合、ゲートウェイの名前空間には免除が必要になることがあります。
強化されたデプロイメント向けに、チャートのREADMEにカスタムAppArmorプロファイル (Debian/Ubuntuノード) およびCEFに必要なシステムコールのみを許可するカスタムseccompプロファイルのインストール手順が記載されています。
デモ / プレイグラウンドサービス (任意)
ゲートウェイと併せて、評価用の使い捨てSSH、RDP、VNC、MySQLコンテナを展開できます。独自のインフラを用意せずに、リモートアクセス、ローテーション、検出を試せます。ゲートウェイを [サンプルレコードを作成] でプロビジョニングしたうえで、デモサービスを有効化します。
個別のサービスは切り替え可能です (例: --set demo.rdp.enabled=false)。
demo.mysql
3306
有効
demo.sshPassword
2222
有効
demo.sshKey
2222
有効
demo.vnc
5901
有効
demo.rdp
3389
有効
すべてのデモパスワードはローカルテスト用のプレースホルダーです。Keeperボルトウィザードの出力値に置き換えてください。デモサービスは本番用途を想定していません。
ネットワーク構成
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
ポート3478でTCPおよびUDPを開放 TCPおよびUDPポート49152～65535へのアウトバウンドアクセス
エンドユーザーのボルトとゲートウェイ経由のターゲットシステム間で、安全かつ暗号化されたWebRTC接続を実現
アンインストール
録画ストレージを有効にしていた場合、永続ボリュームは自動的に削除されません。
構成リファレンス
よく使用する値を以下に示します。完全な一覧は、チャートの values.yaml または ArtifactHubの掲載ページ をご参照ください。
ゲートウェイ構成
gateway.acceptEula
EULAへの同意 (必須、Y であること)
""
gateway.config
Keeperから取得したBase64エンコードのゲートウェイ構成
""
gateway.existingSecret
gateway.config の代わりに事前作成したKubernetes Secretを使用
""
gateway.existingSecretKey
既存Secret内のキー
"gateway-config"
gateway.awsKmsSecretName
AWS Secrets Managerから構成を読み込み
""
イメージ
image.repository
ゲートウェイイメージリポジトリ
keeper/gateway
image.tag
イメージタグ (デフォルトはチャートの appVersion)
""
image.pullPolicy
イメージプルポリシー
IfNotPresent
スケーリングと可用性
replicaCount
ゲートウェイPodの数
1
strategy.type
Recreate (単一インスタンス) または RollingUpdate (マルチインスタンス)
Recreate
autoscaling.enabled
Horizontal Pod Autoscalerを有効化
false
autoscaling.minReplicas / maxReplicas
HPAの上下限
1 / 5
sessionAffinity
スケールされたデプロイメントでは ClientIP に設定
""
podDisruptionBudget.enabled
障害時にも最小Pod数を維持
false
ストレージ、ロギング、ヘルスチェック、AI
recordings.enabled / recordings.size
セッション録画用の永続バッファ
false / 10Gi
sharedMemory.sizeLimit
/dev/shm のサイズ (RBI/Chromium)
2Gi
logging.level / logging.format
ログレベルとフォーマット
info / text
healthCheck.enabled / healthCheck.port
ヘルスチェックサーバー (localhost)
true / 8099
ai.enabled / ai.provider / ai.model
KeeperAI脅威検出
false
resources.limits
CPU / メモリ制限 (多数のRBIセッション向けに増加)
4 / 4Gi
最終更新