Posted inSecurity

OAuth2 Proxyで社内ダッシュボードを保護：15分の設定で不正アクセスを遮断

Security tutorial - IT technology blog
Security tutorial - IT technology blog

なぜダッシュボードを「公開状態」にしてはいけないのか？

DevOpsエンジニアの皆さんは、PrometheusやGrafana、あるいは社内ダッシュボードを頻繁にデプロイしていることでしょう。しかし困ったことに、これらのツールの多くはログイン機能がないか、権限管理（RBAC）が非常に甘いのが現状です。

実を言うと、私もかつて油断して苦い経験をしたことがあります。ポート番号を珍しいもの（8081や9090など）に変えるだけで安全だと思い込んでいたのです。結果はどうだったか？ある朝ログを確認すると、5,000件以上のSSHブルートフォース攻撃と、見知らぬIPからの大量のスキャンが見つかりました。その時の教訓は、「インターネットに公開するものはすべて、適切な認証レイヤーが必要である」ということです。

アプリごとにログインモジュールを実装する手間をかける代わりに、内部アプリを保護するOAuth2 Proxyは非常に迅速な救世主となります。これは、アプリケーションの前に立つ保護レイヤー（リバースプロキシ）として機能します。ユーザーがGrafanaのチャートを見たい場合、会社のGoogleやGitHubアカウントでのログインが必須になります。認証に成功して初めて、OAuth2 Proxyは内部へのアクセスを許可します。

OAuth2 Proxyの実践的な構築

インストール方法はいくつかありますが、Docker Composeを使うのがおすすめです。これにより、設定を一元管理し、異なる環境へのデプロイも容易になります。

1. GoogleでOAuthプロバイダーを登録する

まず、ログイン機能を有効にするために、Google Cloud Consoleから一連のキーを取得する必要があります：

  • Google Cloud Consoleにアクセスし、プロジェクトを作成します。
  • APIs & Services > Credentialsに移動します。
  • Web applicationタイプのOAuth client IDを作成します。
  • Authorized redirect URIsの欄に、正しいアドレスを入力します：https://dashboard.your-domain.com/oauth2/callback。

2. Docker Composeによるクイックデプロイ

以下は私がよく使用するdocker-compose.ymlファイルです。社内アプリがポート8080で動作していると仮定します。

version: '3'
services:
  oauth2-proxy:
    image: quay.io/oauth2-proxy/oauth2-proxy:latest
    ports:
      - "4180:4180"
    environment:
      OAUTH2_PROXY_PROVIDER: "google"
      OAUTH2_PROXY_CLIENT_ID: "your-id.apps.googleusercontent.com"
      OAUTH2_PROXY_CLIENT_SECRET: "your-secret"
      # シークレットの生成コマンド: python3 -c 'import os,base64; print(base64.urlsafe_b64encode(os.urandom(16)).decode())'
      OAUTH2_PROXY_COOKIE_SECRET: "dGhpcy1pcy1hLXNlY3JldC1rZXk=" 
      OAUTH2_PROXY_EMAIL_DOMAINS: "yourcompany.com" 
      OAUTH2_PROXY_UPSTREAMS: "http://your-app:8080"
      OAUTH2_PROXY_HTTP_ADDRESS: "0.0.0.0:4180"
      OAUTH2_PROXY_REDIRECT_URL: "https://dashboard.your-domain.com/oauth2/callback"

プロフェッショナルなNginx統合戦略

実際には、OAuth2 Proxyで直接トラフィックを受けることは稀です。最適な方法は、Nginxをエントリポイントとして使用し、HTTP Security Headersの設定やSSL処理、そしてリクエストの振り分けを行うことです。

auth_requestモジュールの活用

このTipsは非常に価値があります。auth_requestディレクティブを使用します。リクエストが来ると、NginxはOAuth2 Proxyに対してこのユーザーがログイン済みかどうかを問い合わせます。ログイン済みなら通し、そうでなければ即座にGoogleのログインページへリダイレクトさせます。

エンジニア向けのNginx設定サンプルです：

server {
    listen 443 ssl;
    server_name dashboard.yourdomain.com;

    ssl_certificate /etc/letsencrypt/live/yourdomain.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/yourdomain.com/privkey.pem;

    location /oauth2/ {
        proxy_pass       http://127.0.0.1:4180;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Auth-Request-Redirect $request_uri;
    }

    location / {
        auth_request /oauth2/auth;
        error_page 401 = /oauth2/start?rd=$scheme://$host$request_uri;

        # 必要に応じて、バックエンドアプリで処理するためにユーザー情報をヘッダーに渡す
        auth_request_set $email  $upstream_http_x_auth_request_email;
        proxy_set_header X-Email $email;

        proxy_pass http://127.0.0.1:8080;
    }
}

「死活的に重要」な設定項目の注意点

  • Cookie Secret: ブラウザ上のログインセッションを暗号化するための文字列です。セッションの偽装を防ぐため、決してデフォルト値を使用しないでください。
  • Email Domains: 会社用に設定する場合は、特定のドメイン（例：yourcompany.com）を入力してください。*にすると、Gmailアカウントを持っている人なら誰でもアクセスできてしまい、非常に危険です。
  • auth_request: この仕組みにより、ユーザー体験を損なうことなくバックグラウンドでセッションチェックが可能になります。

テストとトラブルシューティング

サービスを再起動した後、ドメインにアクセスしてみてください。ダッシュボードの代わりにGoogleのログイン画面が表示されれば、成功です。

クイックデバッグのコツ

最も一般的なエラーは、Google ConsoleでのURL設定ミスによるInvalid Redirect URIです。コンテナ의 ログを確認して、正確に原因を特定しましょう：

docker logs -f oauth2-proxy-container-id

ログイン成功時の正常なログは、以下のようになります：

[2023/10/27 10:00:01] [auth.go:12] authenticated user: "[email protected]"

3つの追加の実践ノウハウ

  • GitHub Teamによる制限: GitHubを使用する場合、--github-teamフラグを使って、SREやLead-Devチームのみにアクセスを制限できます。
  • トークンの自動リフレッシュ: --cookie-refreshを1時間程度に設定することで、ユーザーに何度もログインを強いることなく、セッションを常に最新の状態に保てます。
  • ヘッダーの強化: 管理画面へのクリックジャッキング攻撃を防ぐため、常にNginxにX-Frame-Options: DENYを追加してください。

OAuth2 Proxyの導入には15〜30分ほどしかかかりませんが、得られるセキュリティ効果は絶大です。バラバラな大量のパスワード管理や、ダッシュボードのポート露出を心配する必要はもうありません。スムーズな設定と、より質の高い睡眠を！

Share:
Tags: