Authelia 部署到 Kubernetes 时如何用 Secret 注入敏感配置值【免费下载链接】autheliaThe Single Sign-On Multi-Factor portal for web apps. OpenID Certified™ and Post-Quantum Cryptography Ready.项目地址: https://gitcode.com/GitHub_Trending/au/authelia把 Authelia 部署到 Kubernetes 时session.secret、存储数据库密码、LDAP 密码、SMTP 密码这类敏感配置不应该写进配置文件或明文环境变量。Authelia 官方推荐的注入方式是“文件密钥”以_FILE结尾的环境变量其值是一个文件路径Authelia 启动时从该文件读取密钥值。在 Kubernetes 中把这些值放进 Secret 资源、以只读文件形式挂载进容器再把_FILE变量指向这些文件即可。本文按 Kubernetes Secrets 集成 与 Secrets 配置方法 两篇文档给出从创建 Secret、挂载到容器到验证的完整路径。哪些配置项可以按文件密钥注入只有名称以key、secret、password、token或certificate_chain结尾的配置键才支持文件方式加载。取该配置项对应的环境变量名在其后加_FILE后缀变量的值必须是 Authelia 进程可读的文件路径。Kubernetes 集成文档示例中使用的对应关系如下Secret 中的键对应的_FILE环境变量JWT_SECRETAUTHELIA_JWT_SECRET_FILESESSION_SECRETAUTHELIA_SESSION_SECRET_FILEREDIS_PASSWORDAUTHELIA_SESSION_REDIS_PASSWORD_FILEREDIS_SENTINEL_PASSWORDAUTHELIA_REDIS_HIGH_AVAILABILITY_SENTINEL_PASSWORD_FILELDAP_PASSWORDAUTHELIA_AUTHENTICATION_BACKEND_LDAP_PASSWORD_FILESTORAGE_ENCRYPTION_KEYAUTHELIA_STORAGE_ENCRYPTION_KEY_FILESTORAGE_PASSWORDAUTHELIA_STORAGE_POSTGRES_PASSWORD_FILESMTP_PASSWORDAUTHELIA_NOTIFIER_SMTP_PASSWORD_FILEDUO_SECRET_KEYAUTHELIA_DUO_API_SECRET_KEY_FILEOIDC_HMAC_SECRETAUTHELIA_IDENTITY_PROVIDERS_OIDC_HMAC_SECRET_FILEOIDC_ISSUER_PRIVATE_KEYAUTHELIA_IDENTITY_PROVIDERS_OIDC_ISSUER_PRIVATE_KEY_FILE完整的可密钥化配置键列表见 Secrets 配置方法 文档。另有一条限制需要知道对象列表类型的配置段无法通过环境变量或密钥配置包括访问控制的rules、OpenID Connect Provider 的clients、session 的cookies以及 server 端点的authz部分。前置关闭 Pod 的 Service LinksKubernetes 集成介绍 文档指出Authelia 的配置管理系统与默认为true的enableServiceLinks选项冲突必须改为false--- apiVersion: v1 kind: Pod metadata: name: authelia spec: enableServiceLinks: false ...如果使用 Deployment则在spec.template.spec中加入同样的enableServiceLinks: false字段。创建 Authelia Secret主路径stringData 清单创建secret.yml后用kubectl apply -f应用。下面的清单取自源文档其中的值是文档示例值文档明确说明不能原样使用——只保留你实际用到的键并把值换成自己的密钥--- kind: Secret apiVersion: v1 metadata: name: authelia stringData: JWT_SECRET: - NwsVsXv4YCAF9suxWZmT7N6PSzmouCDHqVpzbS5niBKo49b7rTREmwFe6roKswf4 SESSION_SECRET: - DkezH5zcMQsvaU38YVu673i6JDH4VPiik9xPmYsTN3KPNkxSiiyZ8ASFTdcBcu8q REDIS_PASSWORD: - VfhdNhgFG5mLU9s3cjQn9im6dkiWNu3FEUPJRi9bqGm3UV6xzGBZgvdCJhoy26d9 REDIS_SENTINEL_PASSWORD: - sSJMfX9A6Q6vTpD6rHXcLn2j5kN557RwuohAeyZuGqH9P9LGfuSMnzi9woYZuNqU LDAP_PASSWORD: - zafcAShEBfgc48DihdRnnb6UJEGKqzg3FdeZXZ3rhrg6tu2oDoYSBA88w9NPvDhZ STORAGE_PASSWORD: - NMHf9Z7C5UQYuKKgh9BJTKeccoZt6c647FQqsEHhkapkkndPkPw3d8bnvkqLgiZ5 STORAGE_ENCRYPTION_KEY: - rH87rjVMQBvzVgj8vVGSxhop2PPwddrJ7B6oSkGcmoganMf4wqANp9AJwaMHt8RA SMTP_PASSWORD: - oi4Yag5HX8Bhc5JTr49nRkdPEr4JcPMfLAPvXxNpHtHqiHXfx3isdWXuTg7yCtjk DUO_SECRET_KEY: - d4ypk2UQXxuo86s7vJ2rYWPa5KoxDfU9JQWgEqtANiBaJVQSG8PJbD9U24eiVuPC OIDC_HMAC_SECRET: - eSopMjbiuCMhEbXGFsm5B8KWKszxV3CJWSLYrWnBJja4rFNvDxti388WyBjdrsHb OIDC_ISSUER_PRIVATE_KEY: | -----BEGIN PRIVATE KEY----- 完整私钥内容 -----END PRIVATE KEY----- ...源文档示例中OIDC_ISSUER_PRIVATE_KEY的 PEM 块内是...占位符实际使用时替换为你的完整私钥内容含 BEGIN/END 行。kubectl apply -f secret.yml同一份清单也可以写成type: Opaque加data:的 base64 编码形式完整的 base64 示例见 Kubernetes Secrets 集成 文档。可选分支Kustomize secretGenerator如果你用kubectl apply -k部署可以在kustomization.yaml中用secretGenerator从本地文件生成 Secret--- generatorOptions: disableNameSuffixHash: true labels: type: generated app: authelia secretGenerator: - name: authelia files: - DUO_SECRET_KEY - JWT_SECRET - LDAP_PASSWORD - OIDC_HMAC_SECRET - OIDC_ISSUER_PRIVATE_KEY - REDIS_PASSWORD - REDIS_SENTINEL_PASSWORD - SESSION_SECRET - SMTP_PASSWORD - STORAGE_ENCRYPTION_KEY - STORAGE_PASSWORD ...files中列出的每一项必须是与kustomization.yaml同目录下真实存在的文件文件内容即期望的密钥值。disableNameSuffixHash: true让生成的 Secret 名称保持为authelia与后续挂载清单中的secretName对应。把 Secret 挂载到 Authelia 容器在 Pod 模板Pod、Deployment、StatefulSet、DaemonSet 均可挂载卷中把 Secret 以只读方式挂载到/app/secrets并为每个密钥设置对应的_FILE环境变量。以下是源文档的部署清单摘录--- spec: containers: - name: authelia env: - name: AUTHELIA_DUO_API_SECRET_KEY_FILE value: /app/secrets/DUO_SECRET_KEY - name: AUTHELIA_JWT_SECRET_FILE value: /app/secrets/JWT_SECRET - name: AUTHELIA_AUTHENTICATION_BACKEND_LDAP_PASSWORD_FILE value: /app/secrets/LDAP_PASSWORD - name: AUTHELIA_IDENTITY_PROVIDERS_OIDC_HMAC_SECRET_FILE value: /app/secrets/OIDC_HMAC_SECRET - name: AUTHELIA_IDENTITY_PROVIDERS_OIDC_ISSUER_PRIVATE_KEY_FILE value: /app/secrets/OIDC_ISSUER_PRIVATE_KEY - name: AUTHELIA_SESSION_REDIS_PASSWORD_FILE value: /app/secrets/REDIS_PASSWORD - name: AUTHELIA_REDIS_HIGH_AVAILABILITY_SENTINEL_PASSWORD_FILE value: /app/secrets/REDIS_SENTINEL_PASSWORD - name: AUTHELIA_SESSION_SECRET_FILE value: /app/secrets/SESSION_SECRET - name: AUTHELIA_NOTIFIER_SMTP_PASSWORD_FILE value: /app/secrets/SMTP_PASSWORD - name: AUTHELIA_STORAGE_ENCRYPTION_KEY_FILE value: /app/secrets/STORAGE_ENCRYPTION_KEY - name: AUTHELIA_STORAGE_POSTGRES_PASSWORD_FILE value: /app/secrets/STORAGE_ENCRYPTION_KEY volumeMounts: - mountPath: /app/secrets name: secrets readOnly: true volumes: - name: secrets secret: secretName: authelia items: - key: DUO_SECRET_KEY path: DUO_SECRET_KEY - key: JWT_SECRET path: JWT_SECRET - key: OIDC_HMAC_SECRET path: OIDC_HMAC_SECRET - key: OIDC_ISSUER_PRIVATE_KEY path: OIDC_ISSUER_PRIVATE_KEY - key: REDIS_PASSWORD path: REDIS_PASSWORD - key: REDIS_SENTINEL_PASSWORD path: REDIS_SENTINEL_PASSWORD - key: SESSION_SECRET path: SESSION_SECRET - key: SMTP_PASSWORD path: SMTP_PASSWORD - key: STORAGE_ENCRYPTION_KEY path: STORAGE_ENCRYPTION_KEY - key: STORAGE_PASSWORD path: STORAGE_PASSWORD ...使用这个摘录时注意三点_FILE变量的值必须是 Authelia 进程可读的文件路径路径不存在或不可读时 Authelia 会加载失败Authelia 会自动去掉文件内容末尾的换行符。摘录只包含你实际使用的密钥items里的key/path与 Secret 中的键名一一对应。源文档示例中AUTHELIA_STORAGE_POSTGRES_PASSWORD_FILE指向的是/app/secrets/STORAGE_ENCRYPTION_KEY文件与其他键的“一个密钥对应一个文件”的映射不一致。文档未解释该行写法实际使用前请自行核对每个_FILE变量确实指向对应密钥的文件。必须遵守的限制同一个密钥只能定义一次Secrets 是分层配置模型的第三层但这一层有特殊规则如果同一个密钥既通过文件密钥方式定义如AUTHELIA_JWT_SECRET_FILE又通过配置文件如jwt_secret或普通环境变量如AUTHELIA_JWT_SECRET定义Authelia 会拒绝启动。迁移到 Secret 注入时要确认配置文件和环境变量里没有残留同一密钥的明文定义。另外两点来自 Secrets 配置方法 文档的说明4.30.0 及以上版本技术上允许把密钥值直接写进不带_FILE后缀的普通环境变量但文档强烈不建议这样做推荐文件方式。如果确实需要把密钥留在配置文件里文档建议将配置文件权限设置为 0600避免其他用户或进程访问。验证注入是否生效部署前用 authelia config validate 命令检查配置它的用途就是对 YAML 与环境配置做部署前校验authelia config validate --config config.yml容器场景下配置文件默认位于/config/configuration.yml--config参数按你的实际配置文件路径替换。部署后的判断依据是文档给出的加载行为_FILE变量指向的文件不存在或不可读时Authelia 会加载失败。因此启动失败时最直接要核对的就是每个_FILE变量的路径在容器内是否存在、且对 Authelia 进程可读。可选替代由 Helm Chart 自动生成并注入Authelia Helm Chart 会自动生成密钥并注入到 Authelia 部署中省去手写 Secret 清单的步骤。添加仓库helm repo add authelia https://charts.authelia.com helm repo update文档说明该 chart 目前处于 beta 状态可能包含破坏性变更。如果需要自己完全控制 Secret 的内容与命名使用前面的主路径。完成 Secret 注入后配置文件中不再包含敏感值可以以仓库根目录的 配置模板 为基础整理其余非敏感配置各密钥配置键的完整列表与各配置方法的安全说明见 Secrets 配置方法 文档。【免费下载链接】autheliaThe Single Sign-On Multi-Factor portal for web apps. OpenID Certified™ and Post-Quantum Cryptography Ready.项目地址: https://gitcode.com/GitHub_Trending/au/authelia创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考