Cloudflare Access chroni teraz bezpośrednio Workery

14 sierpnia 2026 roku Cloudflare ogłosił istotną zmianę modelu bezpieczeństwa Workers: Cloudflare Access można teraz przypisać bezpośrednio do Workera, a nie tylko do każdego hostname stojącego przed nim.

Brzmi to jak niewielkie usprawnienie dashboardu, ale usuwa częstą lukę konfiguracyjną. Worker może być dostępny przez Custom Domain, route, adres workers.dev oraz URL-e preview. Wcześniej zabezpieczenie jednego hostname nie chroniło automatycznie pozostałych. Dodanie domeny bez odpowiedniej aplikacji Access mogło nieświadomie utworzyć publiczną drogę do usługi wewnętrznej.

Przy polityce na poziomie Workera Cloudflare sprawdza tożsamość, zanim request dotrze do kodu, niezależnie od używanego obsługiwanego adresu.

Co się zmieniło

Access może teraz chronić:

1. deploymenty preview jednego Workera;
2. ruch produkcyjny i preview jednego Workera;
3. preview wszystkich Workerów na koncie;
4. ruch produkcyjny i preview wszystkich obecnych oraz przyszłych Workerów na koncie.

Opcja dla całego konta jest szczególnie ważna w organizacjach, w których aplikacje wdraża wiele zespołów lub narzędzi AI. Zamiast wymagać od każdego developera pamiętania o dodatkowym kroku bezpieczeństwa, zespół odpowiedzialny za infrastrukturę może ustawić prywatność jako domyślną. Worker, który świadomie ma być publiczny, może otrzymać jawny wyjątek.

Dotychczasowe aplikacje Access oparte na hostname i ścieżkach pozostają dostępne. Nadal są właściwym rozwiązaniem, gdy uwierzytelniania wymaga wyłącznie admin.example.com, konkretna route albo fragment publicznej aplikacji.

Kolejność polityk ma znaczenie

Cloudflare ocenia pasujące konfiguracje Access od najbardziej szczegółowej do najszerszej:

1. polityka hostname lub ścieżki;
2. polityka Workera;
3. polityka Workerów całego konta.

Reguła dla konta stanowi więc zabezpieczenie domyślne, ale nie zawsze ostateczną decyzję. Bardziej szczegółowa polityka może zmienić wynik dla jednego Workera lub hostname. Usunięcie szczegółowej reguły może odsłonić szerszą regułę pod spodem, zamiast upublicznić aplikację.

Celowe wyjątki warto zapisywać w Infrastructure as Code lub rejestrze dostępów. Inaczej bypass utworzony na czas testu może pozostać na stałe.

Włączenie Access dla jednego Workera

Najkrótsza ścieżka w dashboardzie:

1. Włącz Cloudflare Zero Trust dla konta.
2. Otwórz Workers & Pages i wybierz Workera.
3. Otwórz zakładkę Access.
4. Wybierz Protect this Worker behind Access.
5. Wybierz Previews only albo All traffic.
6. Określ, kto może się logować, i zastosuj politykę.

Podstawowa polityka może wpuszczać członków konta Cloudflare albo użytkowników ze zweryfikowanej domeny e-mail. Zaawansowane reguły, w tym dostawców tożsamości, grupy, device posture i service tokens, konfiguruje się w Zero Trust.

Cloudflare udostępnia nowe typy destination również przez Access Applications API. Aplikacja z destination worker chroni produkcję i preview danego Workera:

{
  "type": "self_hosted",
  "name": "Access for internal-dashboard",
  "destinations": [
    {
      "type": "worker",
      "worker_id": "<WORKER_ID>"
    }
  ]
}

Użyj preview_worker, aby chronić tylko preview jednego Workera, all_preview_workers dla wszystkich preview na koncie albo all_workers dla całego ruchu Workerów. Pełny request API wymaga także polityki Access. Nie należy przenosić częściowego przykładu na produkcję bez określenia, kto ma dostęp.

Tożsamość jest dostępna w kodzie Workera

Dla requestu uwierzytelnionego bezpośrednio przez Access Worker może odczytać tożsamość użytkownika z ctx.access. Nie trzeba samodzielnie parsować i weryfikować JWT Access tylko po to, aby pobrać podstawowe dane:

export default {
  async fetch(request, env, ctx) {
    if (!ctx.access) {
      return new Response("Access required", { status: 403 });
    }

    const identity = await ctx.access.getIdentity();
    const email = identity?.email ?? "unknown";

    return Response.json({ email });
  }
};

Przydaje się to do personalizacji, zdarzeń audytowych i autoryzacji na poziomie aplikacji. Access uwierzytelnia wywołującego, ale kod nadal musi zdecydować, czy dana osoba może odczytać konkretnego klienta, dokument lub wykonać operację administracyjną.

Wrangler potrafi symulować tożsamość podczas lokalnego developmentu:

{
  "access": {
    "dev": {
      "aud": "internal-dashboard",
      "identity": {
        "email": "developer@example.com",
        "groups": ["engineering"]
      }
    }
  }
}

Zmiana symulowanego użytkownika przyspiesza testy ról, ale nie testuje produkcyjnego dostawcy tożsamości ani wdrożonej polityki Access. Po deploymencie nadal potrzebny jest test integracyjny.

Ważne ograniczenia

Access na poziomie Workera nie zastępuje w każdym przypadku polityk hostname.

Polityki Workera nie obsługują WebSocketów. Request z upgrade otrzyma 403. Workery używające WebSocketów, w tym aplikacje czasu rzeczywistego oparte na Durable Objects, powinny nadal korzystać z aplikacji Access przypisanej do hostname.

ctx.access nie przechodzi przez Service Bindings ani RPC. Kolejny Worker nie otrzyma automatycznie kontekstu Access wywołującego. Należy przekazać tylko dane autoryzacyjne potrzebne dalszej usłudze, w sposób uniemożliwiający ich podrobienie przez niezaufanego klienta, albo wykonać ponownie uwierzytelniony request do hostname chronionego przez Access.

Static Assets mają ograniczenie dotyczące tożsamości. Access chroni aplikację i jej pliki, ale wewnętrzny router Workers Static Assets nie przekazuje ctx.access do Workera użytkownika. Trzeba też sprawdzić frameworki, które generują konfigurację assets mimo jej braku w pliku źródłowym.

URL-e preview mają osobne limity platformy. Obecnie nie są generowane dla Workerów implementujących Durable Objects, w tym Containers i Sandbox Workers. Access nie ochroni URL-a preview, którego platforma nie tworzy.

Dostęp maszyna-maszyna

Wewnętrzne API i zadania CI nie powinny udawać logowania. Service tokens Cloudflare Access udostępniają Client ID i Client Secret, które automatyczny klient wysyła w nagłówkach:

curl \
  -H "CF-Access-Client-Id: $CF_ACCESS_CLIENT_ID" \
  -H "CF-Access-Client-Secret: $CF_ACCESS_CLIENT_SECRET" \
  https://internal-api.example.com/health

Polityka Access powinna używać akcji Service Auth. Sekret należy przechowywać w secret managerze, skonfigurować alert wygaśnięcia i regularnie rotować. Unieważnienie sesji Access nie jest tym samym co unieważnienie service tokenu; gdy dostęp ma zostać odebrany, trzeba wyłączyć lub usunąć credential.

Praktyczny plan wdrożenia

Dla konta, które już uruchamia kilka Workerów, rekomendujemy:

1. Zinwentaryzuj Custom Domains, routes, workers.dev i włączone URL-e preview.
2. Rozdziel aplikacje publiczne, wewnętrzne oraz ze ścieżkami o mieszanym dostępie.
3. Zacznij od ochrony preview na poziomie całego konta.
4. Włącz ochronę Workera dla wewnętrznych aplikacji HTTP.
5. Pozostaw polityki hostname dla WebSocketów i aplikacji z mieszanym dostępem.
6. Dodawaj jawne i zatwierdzone bypassy tylko dla celowo publicznych Workerów.
7. Przetestuj logowanie człowieka, odmowę dostępu, service tokens, preview i każdy hostname produkcyjny.
8. Sprawdź logi oraz dostępność danych o tożsamości za granicami usług.

Najważniejszym usprawnieniem nie jest nowy ekran logowania, lecz bezpieczniejsza jednostka polityki. Powiązanie egzekwowania tożsamości z workloadem zamyka lukę między wdrożeniem Workera a pamiętaniem o każdym adresie, przez który można się do niego dostać.

Źródła

• Ogłoszenie Cloudflare: Secure all your internal applications
• Dokumentacja Cloudflare Access dla Workers
• URL-e preview Workers
• Service tokens Cloudflare Access