Hacktoberfest 2026：メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

Feature request: opt-out for the mandatory token when binding non-loopback (Kubernetes / trusted-network deployments)

オープン
  • 何か問題がありますか？
#2,023 コメント 2 件 リアクション 1 件 担当者 0 名 GitHub で見る

メンテナーはふだん 1 日以内に返信

まだ誰も着手していません。

評価

難易度
4/5
見積もり時間
3〜5日
初心者へのやさしさ
48/100
issue の種類
機能追加
明瞭さ
おおむね明確
活発さ
静か
技術スタック
python
領域
backend, security

調査の方向性

Start at the _resolve_auth check mentioned in the issue and trace how non-loopback binding, CRAWL4AI_API_TOKEN, and jwt_enabled are resolved. Determine the supported configuration path for an explicit opt-out, then verify that non-loopback binding without a token works only when opted in and remains protected by default.

索引モデルが issue の本文から書いたものです。

説明

First off, thanks for the security work in 0.9.0. The secure-by-default direction
is the right call for anyone exposing the server straight to the internet. But the
guard leaves Kubernetes deployments in a genuinely awkward spot, and I wanted to
lay out the situation and ask for a small escape hatch.

After upgrading, the container refuses to boot:

CRITICAL:server:Refusing to start: binding 0.0.0.0 with no CRAWL4AI_API_TOKEN
and jwt_enabled=false would expose an unauthenticated API. Set
CRAWL4AI_API_TOKEN=$(openssl rand -hex 32), enable jwt, or bind loopback.

The suggested "bind to loopback" fallback is a non-starter on Kubernetes. A process
listening on 127.0.0.1 is only reachable inside its own pod's network namespace, so
no other pod and no Service can route to it. Binding to 0.0.0.0 / the pod IP is the
only way to be reachable inside a cluster at all. And the loopback path still mints
an ephemeral token and keeps the auth gate in front of every route, so it doesn't
even yield an unauthenticated service.

That leaves setting a token. I can do that, and I can thread it through my callers.
But in this kind of deployment it buys nothing: the server already lives in a
namespace with default-deny network policies, only a handful of explicitly allowed
workloads can reach it, and nothing outside the cluster can route to it at all. The
trust boundary is enforced at the network layer, which is exactly the model the
platform is built around. Forcing an in-app bearer token on top of that is pure
friction for zero additional security in this topology, and it has to be wired
through every caller and proxy by hand.

What I'd love is a simple, explicit opt-out, something like
security.allow_insecure_bind: true in config.yml or a CRAWL4AI_ALLOW_INSECURE=1
env var, that says "yes, I know what I'm doing, I'm running behind my own trust
boundary" and lets the server bind non-loopback without a token. Keep it off by
default so the secure-by-default promise still holds; it would just be opt-in for
those of us running inside a controlled network.

For now I've had to pin back to the last pre-0.9.0 image to keep things working,
which isn't where I want to stay. A flag like this would let me move onto current
releases cleanly.

Is there an officially supported way to do this that I've missed? If not, would you
be open to adding an opt-out? Happy to send a PR; looks like the check sits right
in _resolve_auth.

主要言語
Python
スター
85.4k
フォーク
8.9k
平均マージ
5日 7時間
マージ済み PR（30日）
23

環境構築

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

unclecode/crawl4ai のほかの issue

unclecode/crawl4ai の issue をすべて見る

似ている issue

Python の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。