不能只用 Service 暴露 phpMyAdmin，因其无认证、无 TLS、无访问控制且易被扫描；必须通过 Ingress 实现 HTTPS 终止、外部认证、IP 限制，并配合 NetworkPolicy 阻断集群内直连。
phpMyAdmin 是一个暴露数据库管理界面的 Web 应用，直接部署在 Kubernetes 中时，若仅靠 Service（如 NodePort）暴露，会带来明确的安全风险——它默认不带身份认证、无 TLS 加密、无访问控制粒度，且常被扫描器盯上。Ingress 本身不提供“安全策略”，但它是实施安全控制的**必要前置载体**；真正起作用的是围绕 Ingress 构建的一整套防护层。
为什么不能只用 Service 暴露 phpMyAdmin？
直接用 nodeport 或 loadbalancer 暴露 phpmyadmin service，等于把管理后台裸奔在公网或内网任意节点端口上：
-
NodePort强制占用 30000–32767 端口，多个服务时易冲突，且防火墙规则难收敛 - 没有 HTTPS：明文传输登录凭证和 SQL 查询，中间人可直接截获
- 无法限制来源 IP 或用户代理，自动化扫描工具（如
sqlmap、nuclei）一扫一个准 - 无法与现有单点登录（SSO）、OIDC 认证网关集成
Ingress 是 TLS 终止和路径级防护的唯一可行入口
Kubernetes 的 Ingress 资源本身只是规则声明，但它的实现者（如 ingress-nginx）支持在七层做精细化控制。要让 phpMyAdmin 安全可用，必须通过 Ingress 配置以下几项：
- 强制
tls字段 +secretName，启用 HTTPS 并终止 SSL，避免证书在 Pod 内管理 - 添加
nginx.ingress.kubernetes.io/ssl-redirect: "true"注解，杜绝 HTTP 明文访问 - 用
nginx.ingress.kubernetes.io/auth-url接入外部认证服务（如 Keycloak），而不是依赖 phpMyAdmin 自带的弱密码框 - 通过
nginx.ingress.kubernetes.io/configuration-snippet插入deny all;+allow 192.168.10.0/24;控制源 IP 段
NetworkPolicy 和 Ingress 必须配合使用
即使 Ingress 层做了 TLS 和认证，Pod 之间仍可能被横向渗透。比如攻击者若已进入集群某 Pod，可直连 phpMyAdmin 的 ClusterIP —— 这是 Ingress 管不到的。
必须补一道 NetworkPolicy：
- 设置
podSelector匹配phpmyadmin的标签（如app: phpmyadmin） -
policyTypes: [Ingress]+ingress.from只允许来自ingress-nginx所在命名空间和标签（如app: ingress-nginx）的流量 - 禁止其他所有 Pod 主动连接该服务（尤其要阻断来自
default命名空间的访问）
容易忽略的关键点
很多人以为配了 Ingress + TLS 就万事大吉，其实还有三个硬伤常被跳过：
立即学习“PHP免费学习笔记（深入）”；
-
phpMyAdmin的blowfish_secret必须通过Secret挂载进容器，不能写死在 ConfigMap 或镜像里 - Ingress Controller 自身需禁用
nginx.ingress.kubernetes.io/enable-cors: "true"（除非真需要跨域），否则可能扩大攻击面 - 若用自签名证书，浏览器会报错；但生产环境若用 Let’s Encrypt，需确认
ingress-nginx的 ValidatingWebhook 未拦截 ACME HTTP01 挑战路径（即/.well-known/acme-challenge/必须透传）
