« ^ »
[WIP]

oauth2-proxyで特定のアクセス方法の場合に認証をバイパスする

2022/10/24 更新
約 4分 で読める

oauth2-proxyで特定のアクセス方法を使用した場合の認証のバイパスの設定方法について調べた。

特定のドメインをホワイトリストとして指定してバイパスする

特定のドメインからのリクエストの認証をバイパスするには --white-list-domain を指定する。

IPアドレスを指定してバイパスする

ドメインではなくIPアドレスをバイパスしたいときもある。その場合は --trusted-ip オプションにIPアドレスを指定する。

oauth2_proxyをリバースプロキシの背後に配置している構成では --reverse-proxy を指定する。

--real-client-ip-header によりどのHTTPヘッダに設定されている値をIPアドレスとして用いるかを変更できる。この機能はリバースプロキシにより送信元アドレスが変更されているケースでを想定している。次のどれかを指定できる。

  • X-Forwarded-For
  • X-Real-IP (default)
  • X-ProxyUser-IP

URLパスを指定してバイパスする

特定のURLでは認証をバイパスさせたい時もある。例えば外部サービスからのWebhookを受け取るエンドポイントの前段にoauth2_proxyがいるような構成の時だ。外部サービスのWebhookというのは、そのリクエストの送信元や形式などは自由に設定できないことが多い。例えばWebhookのリクエストにヘッダを追加しようとしても、それを設定できないこともある。そのような場合に、バイパスさせたいURLパスを固定できるのであれば、この方法が使える。

--skip-auth-route /aaa のように指定すると /aaa 配下のURLでは認証をバイパスするようになる。

環境変数で指定する

oauth2_proxyの起動時のオプション引数は OAUTH2_PROXY_ をプレフィックスとして付け、すべての -_ に置き換えると環境変数として指定できる。またオプション引数が複数の指定が可能な値はサフィックスにSを追加する。ホワイトリストのオプション引数は --whitelist-domain であり、これは複数指定可能な値であるので、環境変数として指定する場合は OAUTH2_PROXY_WHITELIST_DOMAINS となる。

オプションの指定順序により挙動が変わる

oauth2_proxyはオプションの指定順序によって挙動が変わることがある。バグとも考えられるが調査してみないと判断が付かなかった。注意すべきポイントであることは間違いない。

WIP Kubernetes Ingress用のエンドポイントの挙動

KubernetesのNGINX Ingress Controllerとoauth2-proxyを用いて認証プロキシを構成することもできるが、特定のパスをスキップさせる場合にやっかいなことになる。 正規表現が特殊すぎて正しく動作しているかどうか、全く判断できない。この状態では困るため、手元に小さな構成を作成し動作を確認する。

検証のため以下の構成のシステムを作成する。通常であれば、oauth2-proxyはKubernetesクラスタ内のPodとして稼動させることが多いと思うが、今回はoauth2-proxyの挙動と、Ingressのアノテーションの挙動ができればよいため、このような若干不自然な構成となっている。


+------------+
|            |
| Client     |
|            |
+------+-----+
       |
       |
       |
+------|-------------------------------------+
|      |    Kubernetes                       |
|      v                                     |
| +----+-------+   +------------+            |
| |            |   |            |            |
| | Ingress    +---+ Ingress    |            |
| |            |   | Controller |            |
| +---------+--+   +------------+            |
|           |                                |
|           |                                |
|           |                                |
+-----------|--------------------------------+
            |
            v
    +-------+------+
    |              |
    | mitmproxy    |
    |              |
    +-------+------+
            |
            v
    +-------+------+
    |              |
    | oauth2-proxy |
    |              |
    +--------------+

(1)の箇所はNginx Ingress controllerのアノテーションを用いて

oauth2-proxyをgo runで起動する

動作確認をする時には、いちいちgo buildコマンドでビルドしたのち、バイナリを実行するのは手間に感じる。そのためよりフィードバックループが短縮可能なgo runコマンドを使用し、oauth2-proxyを起動する。

go run version.go oauthproxy.go validator.go main.go

missing setting: cookie-secret provider missing setting: client-id missing setting: client-secret or client-secret-file missing setting for email validation: email-domain or authenticated-emails-file required.

通信の内部を傍受したり書き換えたりしたいため、更にmitmproxyを起動しておく。中継したリクエストはoauth2-proxyに流す。


しむどん三度無視 により 2021/11/12 に投稿、2022/10/24 に最終更新
« ^ »