Infisical 独立 Postgres Helm Chart（infisical-standalone-postgres）配置实战：安全加固、扩展容器与高可用部署-平芜编程栈

Infisical 独立 Postgres Helm Chart（infisical-standalone-postgres）配置实战：安全加固、扩展容器与高可用部署

【免费下载链接】infisicalInfisical is the open-source platform for secrets, certificates, and privileged access management.项目地址: https://gitcode.com/GitHub_Trending/in/infisical

导读

本文以 helm-charts/infisical-standalone-postgres/CHANGELOG.md 为脉络主线，系统梳理 Infisical 官方独立 Postgres Helm Chart（infisical-standalone）从 v1.3.0 到 v1.10.0 的核心能力演进，并逐一落到 values.yaml 与模板源码中予以印证。读完本文，你将掌握：如何通过securityContext让 Infisical 在 Kubernetes Pod Security "restricted" 标准下开箱即用；如何用extraContainers、extraInitContainers、extraEnv、extraVolumes/extraVolumeMounts挂载 HSM PKCS#11 客户端侧车容器与自定义 CA；如何利用topologySpreadConstraints、nodeSelector、tolerations编排多可用区高可用部署；以及升级该 Chart 时需要注意的 IngressClass、依赖仓库迁移等兼容性事项。

一、Chart 定位与整体结构

infisical-standalone-postgres是 Infisical 官方提供的一体化 Helm Chart，一条命令即可在 Kubernetes 中部署"Infisical 应用 + PostgreSQL + Redis + ingress-nginx"整套栈。其定位在 Chart.yaml 中描述为 "A helm chart to deploy Infisical"，当前 Chart 版本为1.10.0，appVersion为"1.0.1"。

从 Chart.yaml 可以看到它依赖三个子 Chart：

依赖	版本	仓库	启用条件
ingress-nginx	4.0.13	`https://kubernetes.github.io/ingress-nginx`	`ingress.nginx.enabled`
postgresql	14.1.10	`oci://registry-1.docker.io/bitnamicharts`	`postgresql.enabled`
redis	18.14.1	`oci://registry-1.docker.io/bitnamicharts`	`redis.enabled`

模板目录只包含 5 个文件，结构非常清晰：

templates/infisical.yaml：Deployment 与 Service 主清单；
templates/bootstrap-job.yaml：auto-bootstrap 钩子 Job；
templates/ingress.yaml：Ingress 资源；
templates/jobs-rbac.yaml：ServiceAccount、Role、RoleBinding；
templates/_helpers.tpl：命名与连接串拼接辅助函数。

安装后 NOTES.txt 会给出kubectl get all -n <namespace>、helm status、helm uninstall等常用命令提示。

二、安全加固：Pod Security "restricted" 标准开箱即用（v1.10.0）

v1.10.0（2026-07-03）是 CHANGELOG 中最新、也最关键的版本，核心工作是把安全上下文做成可配置且默认安全。

2.1 两个安全上下文的职责划分

该版本新增了infisical.podSecurityContext与infisical.containerSecurityContext两个配置键，职责划分非常考究：

containerSecurityContext承载restricted 标准要求的全部加固项，且只作用于 Infisical 自身容器（包括 auto-bootstrap Job 中的 init 容器与主容器），不会波及用户注入的容器；
podSecurityContext只设置fsGroup: 1001，用于让挂载卷对非 root 用户可写，从而不会把extraContainers、extraInitContainers的用户强制改为 UID 1001。

values.yaml 中的默认值如下：

infisical: podSecurityContext: fsGroup: 1001 containerSecurityContext: allowPrivilegeEscalation: false readOnlyRootFilesystem: false runAsNonRoot: true runAsUser: 1001 seccompProfile: type: RuntimeDefault capabilities: drop: ["ALL"]

对照 Kubernetes Pod Security 的 restricted 基线要求：runAsNonRoot、runAsUser非零、allowPrivilegeEscalation: false、seccompProfile: RuntimeDefault、drop: ALL均已默认满足，因此 Infisical Deployment 与 auto-bootstrap Job 默认即符合 restricted 标准。

2.2 readOnlyRootFilesystem 与 emptyDir 的配合

一个需要特别说明的默认值：readOnlyRootFilesystem默认保持false，因为 Infisical 应用运行时会写临时文件。如果你想开启只读根文件系统（更强的安全基线），CHANGELOG 明确给出了做法：通过infisical.extraVolumes挂载emptyDir，再通过infisical.extraVolumeMounts将/tmp等可写路径指到该卷上。例如：

infisical: containerSecurityContext: readOnlyRootFilesystem: true extraVolumes: - name: tmp emptyDir: {} extraVolumeMounts: - name: tmp mountPath: /tmp

在 templates/infisical.yaml 中可以看到，extraVolumeMounts渲染进主容器的volumeMounts，extraVolumes渲染进 Pod 的volumes，二者天然支持上述组合。

2.3 与 bundled ingress-nginx 的兼容性提醒

CHANGELOG 同时给出了一个重要的限制说明：bundled 的 ingress-nginx 子 Chart 默认不满足 restricted 标准。若要让整个 release 都在 restricted 下运行，需要三选一：

禁用 bundled ingress-nginx（ingress.nginx.enabled: false），改用集群内已有的、符合 restricted 的控制器；
把 ingress-nginx 部署到其他 namespace；
自行提供 restricted-safe 的控制器覆盖配置。

2.4 向后兼容与渲染逻辑

本版本向后兼容：升级时会触发一次性的 Pod 滚动重启；若将podSecurityContext或containerSecurityContext设为null，对应的securityContext块会被整体省略。

模板中的渲染逻辑印证了这一点——templates/infisical.yaml 与 templates/bootstrap-job.yaml 均使用{{- with $infisicalValues.podSecurityContext }}守卫；容器级上下文则在 templates/infisical.yaml（主容器）与 templates/bootstrap-job.yaml（init 容器wait-for-infisical与主容器infisical-bootstrap）分别注入，保证了 bootstrap Job 同样受安全上下文约束。

三、扩展容器：Sidecar、Init 容器与环境变量（v1.9.0 / v1.7.3）

3.1 侧车容器：HSM PKCS#11 客户端接入（v1.9.0）

v1.9.0（2026-05-28）新增infisical.extraContainers与infisical.extraInitContainers，官方文档点名的典型场景是HSM PKCS#11 客户端侧车（例如 Entrust nShield），让 Infisical 与硬件安全模块共享 PKCS#11 套接字。

values.yaml 中的示例：

infisical: extraContainers: - name: hsm-client image: my-hsm-client:latest volumeMounts: - name: pkcs11-socket mountPath: /var/run/hsm extraInitContainers: - name: wait-for-hsm image: busybox:latest command: ['sh', '-c', 'until nc -z hsm-host 9004; do sleep 2; done']

模板侧，templates/infisical.yaml 将extraInitContainers渲染到spec.initContainers，templates/infisical.yaml 将extraContainers直接追加到spec.containers列表尾部。注意 init 容器会在 Infisical 主容器启动前完成前置等待（如等待 HSM 服务就绪），这正是"先就绪、后启动"的典型编排。

3.2 额外环境变量：NODE_EXTRA_CA_CERTS 等（v1.7.3）

v1.7.3（2026-03-07）新增infisical.extraEnv，用于通过 Helm values 直接注入环境变量而无需手改 Deployment 清单。官方示例中强调的典型用途是NODE_EXTRA_CA_CERTS——当企业环境需要让 Node.js 进程信任自建 CA 时：

infisical: extraEnv: - name: NODE_EXTRA_CA_CERTS value: /etc/ssl/certs/ca-certificates.crt

该列表在 templates/infisical.yaml 中通过toYaml直接追加到主容器env数组，与自动生成的DB_CONNECTION_URI、REDIS_URL以及envFrom引用的kubeSecretRef（默认infisical-secrets，见 values.yaml）并列生效。

3.3 自定义卷与挂载的完整支持（v1.4.1 / v1.7.1）

infisical.extraVolumes与infisical.extraVolumeMounts自 v1.4.1（2025-03-19）引入；v1.7.1（2025-10-10）修复了一个关键缺陷：此前自定义卷与挂载只会加到 Infisical 核心 Pod，不会加到数据库迁移 Pod。该修复保证在迁移场景下自定义卷同样生效——例如迁移 Job 需要访问自建 CA 文件或 HSM 套接字时，这一修复至关重要。

四、Ingress 演进：专用 IngressClass 避免控制器冲突（v1.8.0）

v1.8.0（2026-04-06）对 bundled ingress-nginx 做了一个重要的行为变更：控制器改用专用 IngressClass 名称infisical-nginx（controllerValue 为k8s.io/infisical-nginx），取代常见的nginx类名，避免 bundled 控制器误接管集群中其他 Ingress 资源、也避免与已有 ingress 控制器产生冲突。

values.yaml 中对应的子 Chart 配置：

ingress-nginx: controller: ingressClassResource: name: infisical-nginx controllerValue: k8s.io/infisical-nginx default: false ingressClass: infisical-nginx

Ingress 资源的类名选择逻辑在 templates/ingress.yaml 中一目了然：

ingressClassName: {{ $ingress.ingressClassName | default (ternary "infisical-nginx" "nginx" $ingress.nginx.enabled) }}

即：

场景	生效的 ingressClassName
使用 bundled ingress-nginx（`ingress.nginx.enabled: true`）	`infisical-nginx`（升级后控制器与 Ingress 同步更新，无需手动操作）
自带 ingress 控制器（`ingress.nginx.enabled: false`）	默认`nginx`
在 values 中显式设置`ingress.ingressClassName`	以自定义值为准

另注意 templates/ingress.yaml 默认声明了两条路径：/（Prefix匹配）与/ss-webhook（Exact匹配，用于 Secret Scanning webhook），后端 Service 端口均为 8080，与主容器的containerPort: 8080和就绪探针/api/status（见 templates/infisical.yaml）保持一致。

五、高可用与调度编排（v1.6.1 / v1.5.0）

5.1 拓扑分布约束：跨可用区高可用（v1.6.1）

v1.6.1（2025-07-03）新增infisical.topologySpreadConstraints，用于把 Pod 均匀分布到多个可用区/节点，降低单点故障影响面。默认replicaCount: 2（见 values.yaml），配合拓扑约束可形成跨可用区的双副本部署。示例：

infisical: replicaCount: 3 topologySpreadConstraints: - maxSkew: 1 topologyKey: topology.kubernetes.io/zone whenUnsatisfiable: ScheduleAnyway labelSelector: matchLabels: component: infisical

该配置在 templates/infisical.yaml 中渲染进spec.template.spec.topologySpreadConstraints。注意matchLabels需与模板生成的标签一致（component: infisical，参见 templates/_helpers.tpl 的infisical.matchLabels定义）。

5.2 节点选择与污点容忍（v1.5.0）

v1.5.0（2025-03-26）新增nodeSelector与tolerations：

nodeSelector：将 Pod 调度到带特定标签的节点（例如专用 GPU/合规节点池）；
tolerations：允许 Pod 调度到带污点的节点（例如独占节点池）。

infisical: nodeSelector: node-pool: infisical tolerations: - key: dedicated operator: Exists effect: NoSchedule

模板在 templates/infisical.yaml 中同样以with守卫渲染，未配置时整块省略。配合早前版本就支持的affinity（values.yaml），可以完成"亲和性 + 拓扑分布 + 容忍"三层调度组合。

六、依赖与镜像仓库演进（v1.7.0 / v1.7.2）

6.1 PostgreSQL / Redis 迁移到 OCI Bitnami Charts（v1.7.0）

v1.7.0（2025-09-30）做了两项基础设施级变更：

PostgreSQL 与 Redis 的 Helm 依赖迁移到 OCI Bitnami Charts——Chart.yaml 中二者仓库均为oci://registry-1.docker.io/bitnamicharts；
默认 Postgres 与 Redis 镜像仓库迁移到mirror.gcr.io/postgresql|redis——见 values.yaml 与 values.yaml，分别使用mirror.gcr.io/bitnamilegacy/postgresql与mirror.gcr.io/bitnamilegacy/redis。

这意味着旧版基于 HTTPS Helm 仓库（charts.bitnami.com/bitnami）的依赖解析方式不再适用，拉取依赖时应使用helm dependency update从 OCI registry 解析。

6.2 autoDatabaseSchemaMigration 的移除（v1.7.2）

v1.7.2（2025-10-20）彻底移除了autoDatabaseSchemaMigration配置项，理由是更新版本的 Infisical 会在启动流程中自动执行数据库迁移。如果你从更早版本升级，需要从 values 中删除该键，否则 Helm 会因未知键而告警；当前 values.yaml 中也不再存在该配置。另外 values.yaml 保留了infisical.databaseSchemaMigrationJob配置块（镜像仓库ghcr.io/groundnuty/k8s-wait-for、tagno-root-v2.0），用于等待依赖就绪的辅助作业。

6.3 默认镜像 tag 的持续更新

CHANGELOG 记录了默认infisical.image.tag的演进：v1.7.3 更新为v0.158.0，v1.7.2 更新为v0.151.0；当前 values.yaml 中默认为v0.158.0。镜像仓库为infisical/infisical，拉取策略IfNotPresent。升级 Chart 时建议关注该默认值，以便获得最新的应用功能与安全修复。

七、数据库连接与迁移细节（v1.3.0 / v1.4.0）

7.1 复用已有 Postgres 连接串 Secret（v1.3.0）

v1.3.0（2024-10-28）新增postgresql.useExistingPostgresSecret，允许通过 K8s Secret 提供既有 PostgreSQL 连接串，而不使用 Chart 内置的 Postgres：

postgresql: enabled: false useExistingPostgresSecret: enabled: true existingConnectionStringSecret: name: my-pg-conn key: DB_CONNECTION_URI

当enabled: true时，templates/infisical.yaml 会通过secretKeyRef把连接串注入主容器DB_CONNECTION_URI；而当postgresql.enabled: true时，则走 templates/_helpers.tpl 的infisical.postgresDBConnectionString模板拼接：

postgresql://<username>:<password>@<postgres-service>:5432/<database>

默认值为postgresql://infisical:root@postgresql:5432/infisicalDB（用户名、密码、库名分别来自postgresql.auth.username/password/database，见 values.yaml）。

7.2 非 default namespace 的迁移修复与 ServiceAccount（v1.3.0 / v1.4.0）

v1.3.0 修复了数据库迁移在非defaultnamespace 下不执行的问题；
v1.4.0（2024-11-06）将 Chart 完整文档化，并引入infisical.serviceAccount.create——默认自动创建 ServiceAccount（values.yaml 中create: true），命名规则为<release-name>-infisical（见 templates/_helpers.tpl）。

ServiceAccount 关联的 RBAC 在 templates/jobs-rbac.yaml 中定义：主 Role 对batch/jobs具备get/watch/list权限；当autoBootstrap.enabled时，另建一个针对 Secret 的 Role（get/create/update）并绑定到 bootstrap 目标 namespace，支撑 bootstrap Job 将根身份凭据写回 K8s Secret。

八、Auto-bootstrap：一键初始化实例（贯穿多版本）

虽然 auto-bootstrap 在 v1.3.0 之前就已存在，但后续版本持续为其补齐安全上下文（v1.10.0）与 RBAC（v1.4.0）。其工作流见 templates/bootstrap-job.yaml：

以post-install钩子（权重 10）创建 Job，Job 名称带.Release.Revision，并在下次钩子创建前删除（before-hook-creation）；
init 容器wait-for-infisical用curlimages/curl:8.14.1轮询http://<release>-infisical:8080/api/status直到就绪；
主容器使用infisical/cli:<tag>执行bootstrap命令，通过--output=k8-secret、--k8-secret-name、--k8-secret-namespace、--organization、--k8-secret-template与--ignore-if-bootstrapped=true参数，把格式化后的 root identity 凭据写入目标 Secret；
凭据来源为infisical.autoBootstrap.credentialSecret.name指定的 Secret（通过envFrom注入）。

启用方式（values.yaml）：

infisical: autoBootstrap: enabled: true organization: "my-org" secretDestination: name: "infisical-bootstrap-secret" namespace: "default" credentialSecret: name: "infisical-bootstrap-credentials"

默认secretTemplate为{"data":{"token":"{{.Identity.Credentials.Token}}"}}，支持encodeBase64等函数，可自定义写入 Secret 的字段结构。

九、升级路径与兼容性速查

综合 CHANGELOG 全部条目，升级时建议按此清单核对：

v1.7.2 起：删除 values 中的autoDatabaseSchemaMigration（应用启动时自动迁移）；
v1.7.0 起：依赖解析改为 OCI（oci://registry-1.docker.io/bitnamicharts），需要执行helm dependency update；
v1.8.0 起：bundled ingress-nginx 使用infisical-nginx专用 IngressClass；自带控制器的用户无需改动（默认回落nginx）；显式设置过ingress.ingressClassName的覆盖继续生效；
v1.10.0 起：默认注入 pod/container 两级安全上下文，升级会触发一次性 Pod 滚动；如需完全自管，可将对应键设为null；
v1.9.0 起：可使用extraContainers/extraInitContainers扩展 Pod，注意它们与podSecurityContext（仅fsGroup）的设计配合，不会强制改变其运行用户；
v1.7.1 起：extraVolumes/extraVolumeMounts会同时作用于核心 Pod 与迁移相关作业。

快速开始（查看安装方式，不修改仓库）：

# 在仓库根目录下 helm dependency build helm-charts/infisical-standalone-postgres helm install infisical helm-charts/infisical-standalone-postgres \ --namespace infisical --create-namespace \ --set ingress.hostName=app.example.com

安装前还需准备存放 Infisical 根凭据的 Secret（默认引用名为infisical-secrets，通过infisical.kubeSecretRef配置），或启用autoBootstrap自动生成。

十、结语

从 v1.3.0 到 v1.10.0，infisical-standalone-postgresChart 的演进脉络非常清晰：先是修复非 default namespace 迁移、补齐 ServiceAccount 与 Secret 复用（v1.3.0/v1.4.0）；随后开放调度编排（nodeSelector/tolerations、topologySpreadConstraints）与自定义卷/环境变量/侧车容器（v1.5.0/v1.6.1/v1.4.1/v1.7.3/v1.9.0）；再完成依赖体系的 OCI 化与镜像仓库迁移（v1.7.0/v1.7.2）；最终在 v1.8.0 与 v1.10.0 分别解决了 IngressClass 冲突与 Pod Security restricted 合规这两个生产环境最关心的议题。每一步都同步体现在 values.yaml 与模板源码中，本文给出的全部配置均可直接用于生产实践。

【免费下载链接】infisicalInfisical is the open-source platform for secrets, certificates, and privileged access management.项目地址: https://gitcode.com/GitHub_Trending/in/infisical

创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考