KCMから接続をインポート

既存PAMプロジェクトへのKCM接続および接続グループのインポート

変換手順

この手順では、PythonスクリプトでKeeperコネクションマネージャー (KCM) のデータベースへ接続し、接続および接続グループをエクスポートしたうえで、既存のPAMプロジェクト向けの有効なJSONテンプレートへ変換します。

Pythonスクリプトはこちらから入手できます。kcm_export.py と KCM_mappings.json の両方をダウンロードしてください。
kcm_export.py スクリプトは、KCMデータベース (ローカルまたはリモート) に接続し、接続および接続グループのデータを取得します。
取得したデータは、KCM_mappings.json 内のマッピング辞書を用いて、PAMプロジェクトのJSONテンプレートに適合するパラメーターへ変換されます。
接続グループは共有フォルダまたはネストされたフォルダとしてマッピングされます。詳細は接続グループのモデリングをご参照ください。
変換が完了したら、PAM Project Extendコマンドを実行する前に、生成された共有フォルダをKeeperのゲートウェイアプリケーションに追加できます。最終的なJSONファイルには、作成する共有フォルダの一覧に加え、動的トークンを含むと判定された接続名も含まれます。

KCMデータベースへの接続を許可する

PythonスクリプトがKCMデータベースに接続するには、データベース側でポートを開放しておく必要があります。

KeeperコネクションマネージャーのAuto-Dockerインストールの場合

Auto-Dockerインストールでは、docker-compose.yml は /etc/kcm-setup にあります。以下のとおり編集します。

sudo nano /etc/kcm-setup/docker-compose.yml

db:
        image: keeper/guacamole-db-mysql:2
        restart: unless-stopped 
        environment:
            ACCEPT EULA: "Y"
            GUACAMOLE_DATABASE: "guacamole_db"
            GUACAMOLE_USERNAME: "guacamole_user"
            GUACAMOLE_PASSWORD: "XXXXXXXXXXXXXXXXXXXXXXXXX"
            GUACAMOLE_ADMIN_PASSWORD: "XXXXXXXXXXXXXXXXXXXXXXXXX"
            MYSQL_ROOT_PASSWORD: "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXX"
        ports:
            - "3306:3306"

db:
        image: keeper/guacamole-db-postgres:2
        restart: unless-stopped 
        environment:
            ACCEPT EULA: "Y"
            GUACAMOLE_DATABASE: "guacamole_db"
            GUACAMOLE_USERNAME: "guacamole_user"
            GUACAMOLE_PASSWORD: "XXXXXXXXXXXXXXXXXXXXXXXXX"
            GUACAMOLE_ADMIN_PASSWORD: "XXXXXXXXXXXXXXXXXXXXXXXXX"
            POSTGRES_PASSWORD: "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXX"
        ports:
            - "5432:5432"

続いて、変更を反映します。

sudo ./kcm-setup.run apply

任意ですが、root以外のユーザーからPythonスクリプトを実行する場合は、Pythonが docker-compose.yml を読めるよう、ファイルの読み取り権限を変更する必要があります。

sudo chmod 644 /etc/kcm-setup/docker-compose.yml

Docker Composeインストールの場合

Docker Composeで構築した場合も、上記と同じ内容で docker-compose.yml を更新したうえで、Dockerコンテナを再起動します。

docker compose up -d

外部のPostgreSQLデータベースを使用する場合

KCMホストがリモートデータベースに接続されている場合は、すでにポートが開いていることが多いですが、PostgreSQLでは pg_hba.conf で許可された接続元からしかアクセスできません。スクリプトを実行するホストが pg_hba.conf の許可対象に含まれていることを確認してください。

モジュールのインストールとスクリプトの実行

kcm_export.py および KCM_mappings.json と同じディレクトリで、Pythonの仮想環境を作成して有効化します。

sudo apt install python3-venv
python3 -m venv venv
source venv/bin/activate

続いて、スクリプトに必要なPythonモジュールをインストールします。

pip install pyYAML
pip install mysql-connector

pip install rich

pyYAML モジュールは docker-compose.yml を読み取るために使用します。
mysql-connector / psycopg2-binary モジュールはデータベース接続に使用します。
rich モジュールは、コンソール出力の整形と可読性向上にのみ使われます。省略可能ですが、使わない場合は kcm_export.py から該当する import 文を削除してください。

最後に、スクリプトを実行します。

python3 kcm_export.py

スクリプトのCLI手順

スクリプトは、CLI上のプロンプトに従って対話形式で進みます。

最初のプロンプトでは、接続先のデータベース種別を入力します。

2番目のプロンプトでは、docker-compose.yml がローカルに保存されている場合は 1 を選択し、続けてファイルの場所を入力します。データベースがリモートで、docker-compose.yml がローカル端末にない場合は、実行前に kcm_export.py に接続情報を直接記述し、2 を選択します。

PAM KCM Import - Database connection prompt

続いて、接続グループの構造を選択するプロンプトが表示されます。詳細は接続グループのモデリングをご参照ください。

PAM KCM Import - Connection group structure prompt

(任意) 最後に、変換と併せてテンプレートJSONファイルを使用するかどうかを選択するプロンプトが表示されます。すべてのリソース/ユーザーに共通のパラメーターを一括で与えたい場合にのみ、テンプレートJSONが必要になります。

テンプレートファイルには、以下の内容が含まれます。

pamDirectory リソースとそのユーザー。これらはテンプレート内にハードコードされています。
pamMachine リソースとそのユーザー。変換スクリプトのテンプレートとなるリソースおよびユーザーとして使われます。KCMの値で直接上書きされないフィールドは、変換後のオブジェクトへ取り込まれます。

Commanderでのファイルのインポート

最後のプロンプトの後、作業ディレクトリに pam_import.json が作成されます。このファイルは、コマンダーでPAM Project Extendコマンドを使ってインポートできます (手順はガイドをご参照ください)。

pam project extend -c <pam_configuration_uid> -f path/to/pam_import.json

接続グループから生成された共有フォルダを、忘れずに追加してください。

その一覧はCLIに出力され、pam_import.json にも追記されます。

KCMの接続に動的トークンが含まれる場合、ファイル内の logged_records に記録されます。詳細はKCMマッピングとlogged_recordsをご参照ください。

接続グループのモデリング

フォルダパスの生成

接続グループは、JSONテンプレート上のフォルダパスとしてモデル化されます。

KCMでは接続にユーザー認証情報が含まれますが、PAMでは通常、認証情報とリソースは別々の共有フォルダに分かれます。リソースとユーザーは別フォルダパスへ振り分けられ、ルートには KCM Resources - および KCM Users - のプレフィックスが付与されます。

たとえば、KCMで以下のフォルダパスに接続があるとします。

Infra / Site 01 / Windows RDP

リソースレコードとユーザーレコードには、それぞれ以下のフォルダパスが割り当てられます。

KCM Resources - Infra / Site 01 / KCM Resource - Windows RDP
KCM Resources - Infra / Site 01 / KCM User - Windows RDP

ルートフォルダおよびリソースとユーザーのタイトルにはプレフィックスが付きますが、ネストされたフォルダ名はそのまま保持されます。

フォルダ構造

前述の選択式プロンプトで示したとおり、KCMの接続グループをフォルダパスへ読み替える方法が3つ用意されています。

KSM構成ベース

フォルダパスは、概ねKCMの接続グループ構造に沿います。ルートフォルダは共有フォルダ、ネストされたフォルダは個人用フォルダとして扱われます。ただし、接続グループにKSMサービス構成が含まれる場合は、ルートフォルダとして設定されます。

KSMサービス構成を含む接続グループは切り分け、細かい単位で共有できるようルート共有フォルダとして扱う、という前提に立っています。

ネストをそのまま保持

フォルダパスは、KCMの接続グループ構造に完全に一致します。

フラット

ネストは解消され、KCMの各接続グループはルート共有フォルダとしてモデル化されます。

KCMマッピングとlogged_records

スクリプトが出力するJSONファイルには、logged_records のリストが含まれる場合があります。動的トークンを含む接続はこのリストに載りますが、特定のパラメーターに応じて他のレコードをログへ残すこともできます。

スクリプトは KCM_mappings.json と併せて動作します。このファイルは、KCMのパラメーターとPAMプロジェクトのパラメーターの対応を定義する辞書です。非対応のパラメーターは null に、PAMに適用されないパラメーターは ignore にマッピングします。パラメーターを log にマッピングすると、該当する値を持つ接続が logged_records の出力に追加されます。

インポート後にパラメーターを洗い出したいときの手がかりになります。

SFTPの扱い

KCMでは、SFTPのパラメーターにホストと認証情報が含まれます。PAMでは扱いが異なり、pamMachine / pamUser レコードを参照できます。

接続にSFTPパラメーターが含まれる場合、ポート22の新しい pamMachine および pamUser が自動作成され、当該接続のフォルダから1階層下の SFTP というラベルのフォルダに格納されます。

デバッグ

kcm_export.py の先頭にある DEBUG 定数を True に変更すると、デバッグを有効にできます。

前へ既存のモデルへのPAMリソースの追加次へCLIによるローテーション管理

最終更新 1 か月前