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

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

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

Authentik מופץ כשלושה שירותים בקובץ ה-Compose הזה: מסד נתונים PostgreSQL, תהליך server, ותהליך worker. המכולה של השרת מריצה גם את ה-embedded 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 בונה את כתובות ה-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 אמור להציג שלושה קונטיינרים, כאשר postgresql מדווח על healthy ו-server, ו-worker מדווח על running. ההפעלה הראשונה מריצה את עדכוני מסד הנתונים (migrations), לכן יש להמתין דקה עד שהממשק האינטרנטי יגיב.

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

קובץ ה-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 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 כחשבון חירום, עם סיסמה ארוכה המאוחסנת באופן לא מקוון. עבודה שגרתית באמצעות חשבון מובנה משותף פוגעת ביומן הביקורת, משום שכל אירוע מציין 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 משמעותה שהמכולה אינה נמצאת ברשת proxy, ו-Traefik אינו יכול לנתב תעבורה למכולה שאינו מגיע אליה.

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

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

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

בממשק האינטרנט, פתחו את 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-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 לצורך התחברות אוטומטית יישאר מנותק.

היישום המוגן עצמו זקוק לשני 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) מחייבת הרצה של רכיב כמו 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 לבדו אינו מספיק, כיוון שמפתח ההצפנה (secret key) המגן על נתוני ה-session וה-token נמצא בתוך .env.

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

FAQ

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

גרסת ה-open source היא חינמית וכוללת את כל היכולות שצוינו לעיל: ה-proxy provider, ה-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 במקום ליישום עצמו.

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

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

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

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