鯖缶

HA 構成で動かすなら #568 は前提にしたいかも。
とはいえ Kanidm 自体が冗長構成をサポートしているので最初はそのまま動かすでも問題ないのかもしれないが。

サービス追加の手順:

1. kanidm group create {GROUP_NAME} {MANAGER_USER} でサービスを作る。
   • GROUP_NAME は {SERVICE_NAME}_users のような感じで統一している。必須ではないが。
   • MANAGER_USER は省略可能だが、指定しない理由は今のところ特に思い当たらない。
2. kanidm group add-members {GROUP_NAME} {USER} でログインを許可するユーザをグループに追加する。
3. kanidm system oauth2 create {CLIENT_ID} {DISPLAY_NAME} {LANDING_PAGE_URL} でクライアントを登録する。
   • CLIENT_ID と DISPLAY_NAME は面倒なので両方ともドメインを使うことが多い。
   • DISPLAY_NAME と LANDING_PAGE_URL はそれぞれ、 Kanidm の web UI のアプリ一覧のリンクで使われる名前と URI。
4. kanidm system oauth2 add-redirect-url {CLIENT_ID} {REDIRECT_URL} で redirect URL を登録する。
   • redirect URL はクライアントから指定されたものを使う。
5. kanidm system oauth2 update-scope-map {CLIENT_ID} {GROUP_NAME} email profile openid などで scope map を登録する。
   • openid は必須。他はクライアントの要請次第。
6. kanidm system oauth2 update-sup-scope-map {CLIENT_ID} {GROUP_NAME} [scopes]... で supplemental scope map を登録する。
   • 今のところ必要になったことはない。
7. クライアントを設定する。
   • discovery endpoint: https://{IDM_DOMAIN}/oauth2/openid/{CLIENT_ID}/.well-known/openid-configuration
   • authorization endpoint: https://{IDM_DOMAIN}/oauth2/authorise
   • token endpoint: https://{IDM_DOMAIN}/oauth2/token
   • user endpoint: https://idm.example.com/oauth2/openid/{CLIENT_ID}/userinfo
   • client secret: kanidm system oauth2 show-basic-secret {CLIENT_ID} で取り出せる。
   • PKCE code challenge method: S256 (非対応の場合のオプションもある)
   • OIDC token signing algorithm: ES256 (非対応の場合のオプションもある)

参考:

• OAuth2 - Kanidm Administration
• Customising - Kanidm Administration

• CA certificates | Docker Docs

イメージのビルド時に突っ込んでおくのが基本で、さもなくば update-ca-certificates をインストールして毎度呼び出せと。
だ、だるすぎる……。

nop_thread さんは #note-14 で書きました:

• CA certificates | Docker Docs

イメージのビルド時に突っ込んでおくのが基本で、さもなくば update-ca-certificates をインストールして毎度呼び出せと。
だ、だるすぎる……。

• Use lifecycle hooks | Docker Docs

post_start がコンテナ内で実行されるものであれば、ここに全てを突っ込む手はあるかもしれない。
タイムラグについて保証はないらしいが……。

nop_thread さんは #note-16 で書きました:

nop_thread さんは #note-14 で書きました:

• CA certificates | Docker Docs

イメージのビルド時に突っ込んでおくのが基本で、さもなくば update-ca-certificates をインストールして毎度呼び出せと。
だ、だるすぎる……。

• Use lifecycle hooks | Docker Docs

post_start がコンテナ内で実行されるものであれば、ここに全てを突っ込む手はあるかもしれない。
タイムラグについて保証はないらしいが……。

一応できたにはできた。

services:
  svc:
    #...
    volumes:
      - type: bind
        source: {{ HOST_ROOT_CA_PATH }}
        target: {{ GUEST_ROOT_CA_PATH }}
        read_only: true
    post_start:
      - command: cp {{ CONTAINER_ROOT_CA_PATH }} /usr/local/share/ca-certificates/
        user: root
      - command: update-ca-certificates
        user: root

bind mount で直接 /usr/local/share/ca-certificates/ に突っ込むでも良いが、まあとにかくできた。
これで wget 等も通るようになる。

ただ問題は、 urllib3 なんかを使っているとシステムの CA bundle を使ってくれないので結局アプリ側からは証明書エラーが出ることがある。
おそらくはサーバアプリの起動時にキャッシュされてしまってその後更新されたシステムの CA bundle を読んでくれていないせいだろう。
アプリの起動タイミング (というかフックの実行タイミング) の問題なので $REQUESTS_CA_BUNDLE を /etc/ssl/certs/ca-certificates.crt とかにしても解決しない。
こまった。

nop_thread さんは #note-17 で書きました:

ただ問題は、 urllib3 なんかを使っているとシステムの CA bundle を使ってくれないので結局アプリ側からは証明書エラーが出ることがある。
おそらくはサーバアプリの起動時にキャッシュされてしまってその後更新されたシステムの CA bundle を読んでくれていないせいだろう。
アプリの起動タイミング (というかフックの実行タイミング) の問題なので $REQUESTS_CA_BUNDLE を /etc/ssl/certs/ca-certificates.crt とかにしても解決しない。
こまった。

いろいろ試していたら、以下のようにしてできた。

FROM mrmn/pdfding:{{ pdfding_docker_tag }}
COPY custom-root-ca.crt /usr/local/share/ca-certificates/
USER root
RUN update-ca-certificates
ENV REQUESTS_CA_BUNDLE=/etc/ssl/certs/ca-certificates.crt
USER nonroot

どうも certifi の証明書を使っていてシステムの証明書ストアは見てくれていないような雰囲気があって、 $REQUESTS_CA_BUNDLE を設定することなしに (update-ca-certificates の実行だけで) 接続させることができなかった。
めんどくせえライブラリだな。 user preference を尊重せんかい。