התקנת Authentik עם Docker Compose: מדריך SSO מלא

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

Authentik הוא שרת SSO (Single Sign-On) לאירוח עצמי: המשתמשים שלכם מתחברים פעם אחת, וכל יישום שנמצא מאחוריו מקבל את הסשן הזה במקום לבקש סיסמה משלו. ההתקנה מתבצעת באמצעות קובץ Docker Compose רשמי ושני secrets שנוצרים. החלק שדורש מחשבה מעמיקה מגיע לאחר מכן: הפניית reverse proxy אליו, והצבת יישום קיים אחד מאחורי forward auth.

Authentik מגיע כשלושה שירותים בקובץ ה-Compose הזה: מסד נתונים PostgreSQL, תהליך server, ותהליך worker. המכולה של השרת מריצה גם את ה-outpost המוטמע, שהוא הרכיב שעונה על השאלה "האם הבקשה הזו מחוברת?" עבור כל יישום מוגן. גרסה 2026.8.5 היא הגרסה הנוכחית נכון ל-25 באוקטובר 2026. היא פורסמה ב-21 באוקטובר 2026 כתיקון האחרון בסדרת 2026.8, שנפתחה עם 2026.8.0 ב-18 באוגוסט, והיא מחליפה את 2026.8.4 מה-14 באוקטובר כ-image tag ברירת המחדל בקובץ ה-Compose הרשמי. הפרויקט דורש מארח עם לפחות 2 ליבות CPU ו-2 GB של RAM. התייחסו לכך כאל רף המינימום. PostgreSQL וה-worker שניהם תופסים זיכרון לאחר שהשרת פועל במשך יום.

דרישות קדם

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

הרץ את ה-stack כמשתמש רגיל בקבוצה docker ולא כ-root. חברות בקבוצה זו שקולה להרשאות root על המארח, לכן הענק אותה לחשבון פריסה (deploy) אחד בלבד, בהתאם להנחיות ב-חשבונות משתמש עם הרשאות מינימליות ב-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 אמורה להציג שלושה מכולות (containers) פעילות, כאשר postgresql ידווח על healthy ברגע שהבדיקה שלו תעבור בהצלחה. ההפעלה הראשונה מריצה את עדכוני מסד הנתונים (migrations), לכן יש להמתין דקה לפני שממשק האינטרנט יגיב.

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

קובץ ה-Compose מסמן את שני הערכים כנדרשים באמצעות התבנית ${VAR:?message}: ${PG_PASS:?database password required} בשירות PostgreSQL ו-${AUTHENTIK_SECRET_KEY:?secret key required} בשרת ובעובד (worker). המשמעות היא ש-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 token באותה הדרך.
• 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 כחשבון חירום (break-glass) עם סיסמה ארוכה השמורה במקום לא מקוון. אם תהליך או שלב תקול נועל אתכם מחוץ למערכת, הפקודה docker compose run --rm server create_recovery_key 10 akadmin, המורצת מתוך /opt/authentik, תדפיס קישור שיחבר אתכם ישירות כ־akadmin. לכל מי שמחזיק בקישור זה תהיה אותה רמת גישה, לכן התייחסו אליו כאל סיסמה. עבודה יומיומית תחת חשבון מובנה משותף פוגעת ביומן הביקורת (audit log), כיוון שכל אירוע יירשם תחת akadmin ולא ניתן יהיה לדעת מי ביצע אותו. טיעון זה תקף גם במורד הזרם של Authentik: פתרון כגון כלי ניהול עצמי מסוג OneCLI המקצה לכל אדם סוכן משלו מותיר עקבות קריאים רק אם הזהות המגיעה אליו שייכת לאדם אחד, ולא לחשבון התחברות שכל הצוות חולק.

הצבת Authentik מאחורי ה-reverse proxy שלכם

חשיפת פורט 9000 לאינטרנט עובדת, אך אתם זקוקים ל-TLS (אבטחת שכבת תעבורה) ולשם מתחם אמיתי. אם אתם כבר מריצים את ההגדרה מתוך Traefik כ-reverse 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 שומר על כל ההגדרות מהקובץ הרשמי ומקבל את ה-labels. בדקו בעזרת curl -I https://auth.example.com/if/user/, שאמור להשיב HTTP/2 200. שגיאת 404 page not found מצד Traefik משמעותה שאף router לא התאים לבקשה. ודאו שה-labels הגיעו למכולה, שכלל ה-Host() תואם במדויק לשם המתחם, ושהבקשה הגיעה לנקודת הכניסה (entry point) של ה-HTTPS שבה ה-router מאזין.

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

הגנה על יישום בודד באמצעות Forward Auth

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

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

הגדירו את ה-middleware פעם אחת, על ה-container של 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-entitlements,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 היא רשימת ה-headers ש-Traefik מעתיק מהתשובה של Authentik לבקשה שהוא שולח ל-upstream. אם תשמיטו אותה, היישום עדיין יהיה מוגן, אך הוא לעולם לא ידע מי המשתמש, ולכן כל רכיב שקורא את X-authentik-username לצורך התחברות אוטומטית יישאר מנותק. פער זה בולט ביותר מול יישום שמנהל התחברות משלו, כגון מעקב אימונים עצמי של openGym והתחברות ה-passkey שלו, שם ה-headers הם ההבדל בין הנחיה אחת לשתיים עבור אותו עמוד.

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

    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

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

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

כשלים שתיתקל בהם בפועל

לולאת הפניה (redirect) אינסופית בין היישום לדף ההתחברות. ה-host החיצוני בספק אינו תואם למה שהדפדפן משתמש בו; בדרך כלל מדובר ב-http:// בספק לעומת https:// בשורת הכתובת. עוגיית ה-session מוגדרת עבור origin שונה, ולכן כל חזרה נראית כבקשה אנונימית חדשה. תקן את ה-host החיצוני ומחק עוגיות עבור שני הדומיינים לפני בדיקה חוזרת.

שגיאת 404 ב-/outpost.goauthentik.io/start. ה-outpost router חסר, או שהעדיפות שלו נמוכה מזו של ה-router הכללי (catch-all) עבור אותו host.

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

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

מתי Keycloak הוא הבחירה המתאימה יותר

Keycloak הוא הפרויקט הוותיק יותר, הנתמך על ידי Red Hat, והוא מהווה בחירה חזקה יותר עבור משימות ניהול זהויות ארגוניות קלאסיות: פדרציית SAML כבדה, תיווך התחברויות ממספר ספקי זהות חיצוניים בו-זמנית, וייצוא וייבוא של realms כנתיב הגירה מתועד. התמיכה המסחרית העומדת מאחוריו חשובה לארגונים מסוימים על הנייר. המחיר הוא של-Keycloak אין proxy משלו, ולכן הגנה על יישום שאינו תומך ב-OIDC (OpenID Connect) או ב-SAML מחייבת הרצה של רכיב כמו oauth2-proxy לצדו. ספק ה-proxy המובנה של 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 אינו מכיל עותק של AUTHENTIK_SECRET_KEY, ושחזור תחת מפתח שונה יבטל את כל הסשנים הפעילים; לכן, שמירה על המפתח המקורי מאפשרת לשרת המשוחזר להמשיך לפעול כפי שהיה.

שדרוגים מתבצעים באמצעות שינוי תג (tag). הגדירו את AUTHENTIK_TAG בתוך .env לגרסה הרצויה, ולאחר מכן הריצו את docker compose pull ואחריו את docker compose up -d. אם לא הגדרתם את AUTHENTIK_TAG, הגרסה תיקבע לפי ברירת המחדל הכתובה בתוך compose.yml עצמו; לכן, הורדת עותק חדש יותר של קובץ זה מהווה את השדרוג, וזהו המסלול המתואר בתיעוד השדרוג הרשמי. קראו תחילה את הערות השחרור (release notes). Authentik משתמשת בגרסאות מבוססות תאריך, ונכון לאוקטובר 2026 התיעוד שלה מציין כי שדרוגים חייבים להתבצע לפי רצף הגרסאות הראשיות: עברו לתיקון (patch) האחרון בסדרה שבה אתם משתמשים, ולאחר מכן עברו דרך כל סדרה מאוחרת יותר לפי הסדר, ללא דילוג על אף אחת. Authentik אינה תומכת בביצוע downgrade, לכן בצעו את ה-dump של מסד הנתונים לפני ה-pull, ולא אחריו.

FAQ

האם ניתן לארח את Authentik באופן עצמאי בחינם?

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

האם אני חייב להשתמש ב-Traefik כדי להפעיל את Authentik?

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

מדוע היישום המוגן שלי "קופץ" ללא הפסקה בין דף ההתחברות לשגיאה?

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

כמה זיכרון RAM דורש Authentik?

המינימום המתועד נכון לאוקטובר 2026 הוא 2 ליבות CPU ו-2 GB של RAM, עבור PostgreSQL, השרת וה-worker יחד. בשרת עם 2 GB, עומס זיכרון עלול להפעיל את ה-OOM killer של ה-kernel, שמסיים את התהליך עם ה-badness score הגבוה ביותר: בערך נתח הזיכרון המוקצה שהוא צורך, בתוספת ה-oom_score_adj שלו. כאשר מדובר ב-worker, התסמין הוא הפסקה של משימות רקע ושליחת דוא"ל, בעוד דף ההתחברות ממשיך לעבוד. הקצו 4 GB אם אותו שרת מריץ גם את היישומים שאתם מאבטחים.