1
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

Day 25

slack Advent Calendar 2025

@Chisho

Slack 上でユーザー申請をそのまま承認できる！KeeperPAM × Slack 連携（Commander Service Mode + Slack App）構築手順

1
Last updated at Posted at 2025-12-26

この記事は slack Advent Calendar 2025 向けのエントリです。

本記事の内容は筆者個人の見解であり、所属組織・企業の公式見解ではありません。また、本記事の原案は AI を用いて作成していますが、ここで整理した概念や考え方については筆者自身が確認しています。

本記事は、Keeper Commander Service と Slack App を、既存の Keeper Connection Manager(KCM)/ Guacamole が稼働している EC2 Linux 上で共存させながら連携する手順をまとめたものです。

なお KCM についての詳細は前回の記事までにご参照してください。

目的：Slack から承認フロー（レコードの共有、エンドポイントアクセス許可、デバイス承認）を扱えるようにする。

参考リンク：

テストした環境の前提条件

  • EC2 Linux（例：Amazon Linux 2023）上で KCM/Guacamole が既に稼働している (ほかのサービスが)
  • Slack 連携用に Keeper Slack App を利用（Socket Mode）
  • サーバは ALB 配下でも可（Socket Mode は Slack への アウトバウンド接続 が主）
  • サーバから外部 HTTPS へ到達できる（例：curl -I https://api.slack.com が成功）

結論

  • 既存サービス（例：Guacamole）が 8080 を使用しているケースが多い → Commander の公開ポートが衝突しやすい
  • docker-compose.yaml は YAML のインデント（services: 配下の階層）が崩れるとパースエラーになりやすい
  • slack-app が 401 を返す場合、原因はほぼ KEEPER_API_KEY の不一致（1 と l の見間違い含む）
  • Commander コンテナを完全に作り直すと API Key が変わることがある → ログから取り直して .env 更新が必要

構成の考え方（既存のサービスに影響を与えない）

  • Slack 連携用の Compose は 別ディレクトリ（例：/opt/keeper-slack）に分離
  • Compose のプロジェクト名を 固定（例：-p keeper-slack）して既存コンテナ群と分離
  • Commander はコンテナ内 8080 のまま、ホスト側は 127.0.0.1:8081 にバインドしてポート衝突回避

手順 1：作業ディレクトリ作成

sudo mkdir -p /opt/keeper-slack
sudo chown -R admin2:admin2 /opt/keeper-slack  # 必要なら（権限設計により sudo 運用でもOK）
cd /opt/keeper-slack

手順 2：docker-compose.yaml を配置

ここでは /opt/keeper-slack 配下に docker-compose.yaml を用意している前提で進めます。

Compose（例）

重要：commander と slack-app は services: 配下で同じインデントにする

services:
  commander:
    image: keeper/commander:latest
    env_file:
      - .env
    ports:
      - "127.0.0.1:8081:8080"  # host 8081 -> container 8080（Guacamole の 8080 と衝突回避）
    command: >
      service-create -p 8080
      -c 'search,share-record,share-folder,record-add,one-time-share,pedm,device-approve'
      -f json
      --ksm-config ${KSM_CONFIG_BASE64}
      --record ${COMMANDER_RECORD_UID}
    healthcheck:
      test:
        - CMD-SHELL
        - |
          python - <<'PY'
          import sys
          import urllib.request
          url = "http://localhost:8080/health"
          try:
              r = urllib.request.urlopen(url, timeout=2)
              sys.exit(0 if r.status == 200 else 1)
          except Exception:
              sys.exit(1)
          PY
      interval: 5s
      timeout: 3s
      start_period: 10s
      retries: 30

  slack-app:
    image: keeper/slack-app:latest
    env_file:
      - .env
    depends_on:
      commander:
        condition: service_healthy

手順 3：.env を作成（Slack + Keeper）

cd /opt/keeper-slack
nano .env

例：

# SLACK CONFIGURATION (Required)
SLACK_APP_TOKEN=xxxx
SLACK_BOT_TOKEN=xxxx
SLACK_SIGNING_SECRET=xxxx
APPROVALS_CHANNEL_ID=C0xxxx

# KEEPER COMMANDER SERVICE MODE (Required)
KEEPER_SERVICE_URL=http://commander:8080/api/v2/
KEEPER_API_KEY=your_commander_api_key

# PEDM (Optional)
PEDM_ENABLED=true
PEDM_POLLING_INTERVAL_IN_SEC=120

# DEVICE APPROVALS (Optional)
DEVICE_APPROVAL_ENABLED=true
DEVICE_APPROVAL_POLLING_INTERVAL_IN_SEC=120

# Commander 用
KSM_CONFIG_BASE64=xxxx
COMMANDER_RECORD_UID=xxxx

KEEPER_SERVICE_URL は コンテナ間通信なので基本 http://commander:8080/api/v2/ のままでOK。
ホスト側の 8081:8080 は ホスト→コンテナ用（デバッグ）です。

手順 4：Compose の検証

cd /opt/keeper-slack
sudo docker compose -p keeper-slack -f docker-compose.yaml config
  • ここでエラーが出る場合は インデント（slack-app: の位置など）を再確認

手順 5：イメージ取得と起動

cd /opt/keeper-slack
sudo docker compose -p keeper-slack -f docker-compose.yaml pull
sudo docker compose -p keeper-slack -f docker-compose.yaml up -d

状態確認：

sudo docker compose -p keeper-slack ps

手順 6：ログで動作確認

Slack App のログ

sudo docker compose -p keeper-slack logs -f --tail=200 slack-app

期待ログ例：

  • Socket Mode enabled
  • Listening for Slack commands and interactions...

もし 401 が出る場合

Failed to submit ... : 401 が出続ける場合、ほぼ KEEPER_API_KEY 不一致です。

Commander から正しい API Key を取得

sudo docker compose -p keeper-slack logs commander | grep -i "Generated API key" | tail -n 1

その値を .env の KEEPER_API_KEY に 完全一致で入れて、Slack App を再作成：

sudo docker compose -p keeper-slack up -d --force-recreate slack-app

Slack 側の操作イメージ（ユーザー申請 → 管理者承認）

このセクションは、記事公開前にスクリーンショットを貼り付けて完成させる想定です。

1) ユーザー：申請（Request）

  • ユーザーが Slack から申請を実行

レコードアクセス/フォルダアクセス/ワンタイム共有申請

送信後の確認メッセージ

2) 管理者：承認チャンネルで受領

承認チャンネルに届く申請メッセージ (権限と共有時間調整可能)

申請詳細の展開（必要なら）

3) 管理者：Approve / Deny

管理者が Slack 上のボタンから承認または拒否

承認結果がスレッド/チャンネルに反映され、申請者にも通知される

4) バックエンド側（参考）：ログで追跡

Slack 上の操作と同時に、サーバ側では以下で挙動を追えます。

sudo docker compose -p keeper-slack logs -f --tail=200 slack-app
sudo docker compose -p keeper-slack logs --tail=200 commander

運用：アップデート時の注意

基本は以下でOK：

sudo docker compose -p keeper-slack -f docker-compose.yaml pull
sudo docker compose -p keeper-slack -f docker-compose.yaml up -d

ただし、Commander コンテナを完全に再作成すると API Key が変わる可能性があります。
その場合は：

  1. docker compose logs commander | grep Generated API key
  2. .env の KEEPER_API_KEY を更新
  3. slack-app を再起動（または --force-recreate）
# Commander API key 再取得
sudo docker compose -p keeper-slack logs commander | grep -i "Generated API key" | tail -n 1

まとめ

  • 既存サービス（例：Guacamole の 8080）と競合しないように、Commander のホスト公開ポートは 8081 などに退避する
  • Compose は 別ディレクトリ + 固定プロジェクト名（-p keeper-slack） で分離すると安全
  • YAML は インデントが崩れるとパースエラーになりやすい（services: 配下の階層に注意）
  • 401 はほぼ Commander API Key の不一致（Commander ログから現行キーを取り直して .env を更新）
1
1
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
1
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?