איך להגדיר Authentik לכניסה אחידה ב-Docker

התחברות אחת לכל היישומים שאתם מארחים

Authentik הוא שרת SSO (כניסה יחידה) באירוח עצמי. המשתמשים נכנסים פעם אחת, וכל יישום שמאחוריו מקבל את ההפעלה הזו במקום לבקש סיסמה משלו. ההתקנה משתמשת בקובץ Docker Compose רשמי ובשני סודות שנוצרו. החלק שדורש מחשבה אמיתית מגיע לאחר מכן: להפנות אליו פרוקסי הפוך ולהציב יישום קיים מאחורי אימות קדמי.

Authentik מופץ בשלושה שירותים בקובץ Compose הזה: מסד נתונים PostgreSQL, תהליך server ותהליך worker. הקונטיינר של השרת מפעיל גם את ה-outpost המובנה, שהוא הרכיב שבודק עבור כל יישום מוגן אם הבקשה מגיעה ממשתמש מחובר. גרסה 2026.5 היא המהדורה הנוכחית נכון ליולי 2026, והפרויקט דורש מארח עם לפחות 2 ליבות CPU ו-2 GB של RAM. יש להתייחס לכך כדרישת המינימום. PostgreSQL וה-worker צורכים זיכרון לאחר שהשרת פועל במשך יום.

מה דרוש לפני שמתחילים

נדרש Docker Engine עם התוסף Compose v2. אפשר לאמת זאת באמצעות docker compose version. אם הפקודה מציגה שגיאה במקום מספר גרסה, התקינו את התוסף לפני שתמשיכו; היסודות מוסברים במדריך הפעלת יישומים באמצעות Docker Compose ב-VPS. בנוסף, נדרשת רשומת DNS מסוג A שמפנה אל השרת, auth.example.com בדוגמאות שלהלן, מכיוון ש-Authentik בונה את כתובות ההפניה מחדש לפי שם המארח שבו השתמש הדפדפן.

הפעילו את ה-stack כמשתמש רגיל בקבוצה docker, ולא כ-root. החברות בקבוצה זו שקולה להרשאות root במארח, לכן העניקו אותה לחשבון פריסה אחד בלבד ולאף משתמש אחר, בהתאם לעקרונות המתוארים במדריך חשבונות משתמשים בעלי הרשאות מינימליות ב-VPS.

התקנה באמצעות קובץ Compose הרשמי

sudo install -d -o "$USER" -g "$USER" /opt/authentik
cd /opt/authentik
wget https://docs.goauthentik.io/compose.yml
echo "PG_PASS=$(openssl rand -base64 36 | tr -d '\n')" >> .env
echo "AUTHENTIK_SECRET_KEY=$(openssl rand -base64 60 | tr -d '\n')" >> .env
docker compose pull
docker compose up -d

docker compose ps אמור להציג שלושה קונטיינרים. postgresql אמור לדווח על healthy ועל server, ו-worker אמור לדווח על running. בהפעלה הראשונה מתבצעות הגירות של מסד הנתונים, לכן יש להמתין דקה לפני שממשק האינטרנט מתחיל להשיב.

לשני הערכים שנוצרו יש חשיבות, מסיבות שונות. PG_PASS הוא הסיסמה של PostgreSQL, ומגבלת האורך שלה היא 99 תווים. AUTHENTIK_SECRET_KEY משמש לחתימת סשנים ואסימונים, ולכן שינוי שלו בהמשך ינתק את כל המשתמשים ויבטל כל אסימון API שהונפק. יש להשאיר את .env עם הרשאות 600 ולשמור עותק שלו במקום בטוח, מכיוון שמסד נתונים ששוחזר ללא המפתח הסודי התואם לו הוא מסד נתונים שאיש אינו יכול להתחבר אליו.

קובץ Compose קורא את שני הערכים באמצעות הצורה ${PG_PASS:?database password required}, ולכן Compose מסרב להפעיל את השירות כאשר הקובץ חסר. הפעלת docker compose up -d מהספרייה הלא נכונה מציגה את required variable AUTHENTIK_SECRET_KEY is missing a value: secret key required ומפסיקה. זו בעיית נתיב, ולא בעיית תצורה.

ערכי הסביבה החשובים

כל השאר נכנס לאותו קובץ .env. Authentik ממפה שני קווים תחתונים למפתח תצורה מקונן, לכן AUTHENTIK_EMAIL__HOST מגדיר את email.host. קו תחתון יחיד מתעלמים ממנו ללא אזהרה. זו הסיבה הנפוצה ביותר לכך שנראה שהגדרה אינה משפיעה.

• AUTHENTIK_BOOTSTRAP_PASSWORD מגדיר בהפעלה הראשונה את הסיסמה של משתמש akadmin המובנה, כך שלא תצטרכו להקליד אותה בטופס אינטרנט ציבורי. AUTHENTIK_BOOTSTRAP_EMAIL ו-AUTHENTIK_BOOTSTRAP_TOKEN מגדירים באותו אופן את כתובת המשתמש ואת אסימון ה-API שלו.
• COMPOSE_PORT_HTTP ו-COMPOSE_PORT_HTTPS מעבירים את היציאות המפורסמות מברירות המחדל 9000 ו-9443.
• AUTHENTIK_EMAIL__HOST, AUTHENTIK_EMAIL__PORT, AUTHENTIK_EMAIL__USERNAME, AUTHENTIK_EMAIL__PASSWORD, AUTHENTIK_EMAIL__USE_TLS ו-AUTHENTIK_EMAIL__FROM מגדירים דואר יוצא. בלעדיהם Authentik מנסה את localhost ביציאה 25, ולכן הודעות לאיפוס סיסמה מסתיימות בשגיאת חיבור ביומן ה-worker.
• AUTHENTIK_LOG_LEVEL=debug מפעיל את רמת הפירוט הדרושה כאשר תהליך התחברות אינו פועל כראוי. החזירו אותו ל-info לאחר מכן.
• AUTHENTIK_ERROR_REPORTING__ENABLED הוא false כברירת מחדל. הגדירו אותו ל-true רק אם אתם מוכנים לשלוח דוחות קריסה לספק.

אלה סודות בקובץ גלוי, לכן התייחסו לספרייה כפי שהייתם מתייחסים לכל מאגר פרטי התחברות אחר. מנהל סיסמאות כגון מופע Vaultwarden באירוח עצמי הוא מקום מתאים יותר לשמירת עותק השחזור מאשר פתק במחשב הנייד.

ההתחברות הראשונה וחשבון הניהול

פתח את http://SERVER_IP:9000 בדפדפן. Authentik מציג את תהליך ההגדרה הראשוני ומבקש להגדיר סיסמה למשתמש akadmin המוגדר כברירת מחדל. אם כבר הגדרת את AUTHENTIK_BOOTSTRAP_PASSWORD, שלב זה הושלם ואתה עובר ישירות לדף ההתחברות.

צור לעצמך משתמש ניהול רגיל תחת Directory ולאחר מכן Users, הוסף אותו לקבוצה authentik Admins והתחבר באמצעות חשבון זה. השאר את akadmin כחשבון חירום, עם סיסמה ארוכה המאוחסנת במצב לא מקוון. עבודה יומיומית באמצעות חשבון מובנה משותף משבשת את יומן הביקורת, משום שכל אירוע מציין את akadmin, ואינו מציין מי ביצע אותו.

הצבת Authentik מאחורי שרת ה-proxy ההפוך

פרסום יציאה 9000 לאינטרנט פועל, אך נדרשים TLS (אבטחת שכבת התעבורה) ושם מארח אמיתי. אם כבר הפעלתם את התצורה מתוך Traefik כשרת proxy הפוך עבור כמה יישומי Compose, חברו את Authentik לאותה רשת חיצונית proxy באמצעות קובץ override. צרו את docker-compose.override.yml לצד compose.yml:

services:
  server:
    networks:
      - default
      - proxy
    labels:
      traefik.enable: "true"
      traefik.docker.network: proxy
      traefik.http.routers.authentik.rule: Host(`auth.example.com`)
      traefik.http.routers.authentik.entrypoints: websecure
      traefik.http.routers.authentik.tls.certresolver: le
      traefik.http.services.authentik.loadbalancer.server.port: "9000"

networks:
  proxy:
    external: true

החילו את התצורה באמצעות docker compose up -d. ‏Compose ממזג את קובץ ה-override באופן אוטומטי, ולכן השירות server שומר על כל ההגדרות מהקובץ הרשמי ומקבל גם את התוויות. בדקו באמצעות curl -I https://auth.example.com/if/user/; הפקודה אמורה להשיב את HTTP/2 200. שגיאת 404 page not found מ-‏Traefik מציינת שהמכולה אינה מחוברת לרשת proxy, ולכן Traefik אינו יכול לנתב למכולה שאין לו גישה אליה.

לאחר ששם המארח פועל, קשרו את היציאות שפורסמו ל-127.0.0.1 בקובץ ה-override, כך שהגישה היחידה פנימה תהיה דרך ה-proxy.

הגנה על יישום אחד באמצעות אימות קדמי

ל-Authentik יש שלושה מצבים עבור ספק ה-proxy, ובחירה שגויה עלולה לבזבז שעה. Proxy פירושו שה-outpost עצמו מעביר את התעבורה ליישום upstream. Forward auth (single application) פירושו ששרת ה-reverse proxy שלכם עדיין מעביר את התעבורה, ורק שואל את Authentik אם המשתמש מחובר. Forward auth (domain level) מגן על כל היישומים תחת דומיין אב אחד באמצעות ספק יחיד, אך דורש כללי הרשאה נפרדים לכל יישום. כאשר Traefik נמצא בחזית, יש לבחור ב-forward auth (single application).

בממשק האינטרנט, פתחו את Applications ולאחר מכן את Providers. צרו Proxy Provider, בחרו במצב forward auth single application, והגדירו את המארח החיצוני ל-https://app.example.com. צרו Application שמצביע אל הספק הזה. לאחר מכן פתחו את Outposts, ערכו את authentik Embedded Outpost, והעבירו את היישום החדש לרשימת היישומים שנבחרו. ה-outpost משיב רק עבור יישומים שהוקצו לו, ולכן דילוג על השלב האחרון הוא הסיבה לכך שספק שהוגדר כראוי עדיין אינו מחזיר דבר.

הגדירו את ה-middleware פעם אחת, על מכל ה-Authentik, והפנו אליו מכל יישום מוגן:

      traefik.http.middlewares.authentik.forwardauth.address: http://server:9000/outpost.goauthentik.io/auth/traefik
      traefik.http.middlewares.authentik.forwardauth.trustForwardHeader: "true"
      traefik.http.middlewares.authentik.forwardauth.authResponseHeaders: X-authentik-username,X-authentik-groups,X-authentik-email,X-authentik-name,X-authentik-uid,X-authentik-jwt,X-authentik-meta-jwks,X-authentik-meta-outpost,X-authentik-meta-provider,X-authentik-meta-app,X-authentik-meta-version

authResponseHeaders היא רשימת הכותרות ש-Traefik מעתיק מתשובת Authentik אל הבקשה שהוא שולח ל-upstream. אם תשמיטו אותה, היישום עדיין יהיה מוגן, אך הוא לא ילמד מי המשתמש. לכן כל רכיב שקורא את X-authentik-username לצורך התחברות אוטומטית יישאר מנותק.

היישום המוגן עצמו זקוק לשני נתבים, ולא לאחד:

    labels:
      traefik.enable: "true"
      traefik.http.routers.myapp.rule: Host(`app.example.com`)
      traefik.http.routers.myapp.entrypoints: websecure
      traefik.http.routers.myapp.tls.certresolver: le
      traefik.http.routers.myapp.middlewares: authentik@docker
      traefik.http.routers.myapp-auth.rule: Host(`app.example.com`) && PathPrefix(`/outpost.goauthentik.io/`)
      traefik.http.routers.myapp-auth.entrypoints: websecure
      traefik.http.routers.myapp-auth.tls.certresolver: le
      traefik.http.routers.myapp-auth.priority: "15"
      traefik.http.routers.myapp-auth.service: authentik

הנתב השני הוא החלק שרוב המשתמשים משמיטים. לאחר ההתחברות, Authentik שולח את הדפדפן בחזרה לנתיב תחת /outpost.goauthentik.io/ בשם המארח של היישום, ולא תחת auth.example.com. ללא נתב ששולח את קידומת הנתיב הזו לשירות Authentik, הבקשה מגיעה ליישום שלכם, שמחזיר 404, וההתחברות אינה מסתיימת. הערך הגבוה יותר של priority הוא שגורם לכלל הנתיב הספציפי לגבור על כלל Host() הרגיל באותו דומיין.

בדקו זאת בחלון גלישה פרטי. אתם אמורים להיות מועברים אל auth.example.com, להתחבר ולחזור אל היישום. docker compose logs -f server בצד של Authentik מדפיס אירוע הרשאה עבור כל ניסיון, וכך ניתן לראות אם הבקשה הגיעה בכלל אל Authentik.

התקלות שתיתקלו בהן בפועל

לולאת הפניות אינסופית בין היישום לדף ההתחברות. המארח החיצוני אצל הספק אינו תואם למארח שבו הדפדפן משתמש, בדרך כלל http:// אצל הספק לעומת https:// בשורת הכתובת. קובץ ה-cookie של ההפעלה מוגדר לאחר מכן עבור מקור שונה, ולכן כל חזרה נראית כמו בקשה אנונימית חדשה. תקנו את המארח החיצוני ומחקו את קובצי ה-cookie עבור שני התחומים לפני בדיקה חוזרת.

שגיאת 404 בכתובת /outpost.goauthentik.io/start. הנתב של outpost חסר, או שהעדיפות שלו נמוכה מזו של הנתב הכוללני עבור אותו מארח.

היישום נטען בלי לבקש התחברות. התווית middlewares מציינת תוכנת middleware שאינה קיימת. Traefik אינו מציג אזהרה על כך, ולכן שגיאת כתיב ב-authentik@docker פשוט גורמת לכך שאף תוכנת middleware אינה מופעלת. פתחו את לוח המחוונים של Traefik ואשרו שהנתב מציג את תוכנת ה-middleware.

שגיאת 403 מ-Authentik לאחר התחברות מוצלחת. המשתמש אומת, אך אינו מורשה: ליישום משויכת מדיניות, או דרישה לחברות בקבוצה, שהמשתמש אינו עומד בה. יומן Events בממשק הניהול מציין את המדיניות שחסמה את הבקשה.

מתי Keycloak מתאים יותר

Keycloak הוא הפרויקט הוותיק יותר, הזוכה לתמיכת Red Hat, והוא הבחירה החזקה יותר לצורכי זהויות ארגוניים קלאסיים: איחוד SAML בהיקף גדול, תיווך התחברויות ממספר ספקי זהויות חיצוניים במקביל, וייצוא וייבוא של realm כנתיב הגירה מתועד. עבור ארגונים מסוימים, התמיכה המסחרית מאחוריו היא שיקול חשוב. החיסרון הוא של-Keycloak אין proxy משלו. לכן, כדי להגן על יישום שאינו משתמש ב-OIDC (OpenID Connect), יש להפעיל לצדו רכיב כגון oauth2-proxy. ספק ה-proxy המובנה של Authentik מספק את הרכיב הזה ומשולב כבר במערכת. לכן רוב המשתמשים שמארחים בעצמם אוסף מגוון של יישומים בוחרים ב-Authentik.

גיבויים ושדרוגים

שלושה דברים מאפשרים לבצע שחזור: מסד הנתונים של PostgreSQL, הספרייה ./data והקובץ .env.

cd /opt/authentik
docker compose exec -T postgresql pg_dump -U authentik authentik | gzip > authentik-$(date +%F).sql.gz

שמרו את קובץ ה-dump ואת .env יחד. קובץ ה-dump לבדו אינו מספיק, משום שהמפתח הסודי שמגן על נתוני ההפעלות והאסימונים נמצא ב-.env.

שדרוגים מתבצעים באמצעות שינוי תגית. הגדירו את AUTHENTIK_TAG בתוך .env למהדורה הרצויה, ולאחר מכן הריצו את docker compose pull ואחריו את docker compose up -d. קראו תחילה את הערות המהדורה, משום ש-Authentik משתמשת בגרסאות המבוססות על תאריכים, ובחלק מהמהדורות כלולות הגירות שמצפות שתגיעו מהמהדורה הקודמת. צרו את קובץ ה-dump של מסד הנתונים לפני פעולת ה-pull, ולא אחריה.

FAQ

האם Authentik חינמי לאירוח עצמי?

המהדורה בקוד פתוח חינמית וכוללת את כל הרכיבים שתוארו לעיל: ספק ה-proxy, אימות קדמי, OIDC (OpenID Connect), ‏SAML ומנוע הזרימות. שכבת Enterprise בתשלום מוסיפה תמיכה ותכונות ארגוניות, אך אין צורך ברישיון עבור שום דבר שמתואר כאן.

האם נדרש Traefik כדי להשתמש ב-Auth entik?

לא. אימות קדמי פועל עם nginx באמצעות auth_request ועם Caddy באמצעות forward_auth. התבנית זהה בכל המקרים: ה-proxy ההפוך שואל את Authentik לגבי כל בקשה, והקידומת /outpost.goauthentik.io/ ב-hostname המוגן חייבת לנותב אל Authentik במקום אל היישום.

מדוע היישום המוגן שלי עובר שוב ושוב בין מסך הכניסה לשגיאה?

ה-host החיצוני שהוגדר בספק ה-proxy אינו תואם לכתובת ה-URL שבה משתמש הדפדפן, לרוב http מול https. קובץ ה-cookie של ההפעלה מונפק עבור מקור אחד ונקרא ממקור אחר, ולכן Authentik מזהה בקשה אנונימית בכל פעם. תקנו את ה-host החיצוני, ולאחר מכן מחקו את קובצי ה-cookie עבור שני שמות ה-host לפני הבדיקה החוזרת.

כמה RAM נדרש ל-Authentik?

המינימום המתועד הוא 2 ליבות CPU ו-2 GB של RAM, נכון ל-July 2026, והוא כולל יחד את PostgreSQL, את השרת ואת ה-worker. בשרת עם 2 GB, ה-worker הוא התהליך הראשון שהקרנל מסיים תחת לחץ זיכרון. התסמין הוא שמשימות רקע ודואר יוצא מפסיקים לפעול, בעוד שדף הכניסה עדיין פועל. הקצו 4 GB אם אותו שרת מפעיל גם את היישומים שעליהם אתם מגינים.