GitHub维护K8S资源最佳实践：dev仓库受限场景下的部署方案咨询

1. 仓库架构拆分，隔离内部开发与对外交付链路 #

• 保留原有私有开发仓库作为内部配置唯一可信源，所有开发、测试、生产环境的overlay配置仍在私有仓内迭代，不对外开放任何权限
• 新增独立的对外部署配置仓库，仅用于存放客户部署所需的最小化配置（仅保留生产级overlay、服务基础配置，删除内部开发用的本地/测试环境配置、调试注释等内容）
• 配置CI流水线（GitHub Action/Azure DevOps Pipeline均可），当私有开发仓的配置合并到稳定发布分支时，自动过滤内部专属内容后同步到对外配置仓，无需人工干预保证配置一致性

2. 用OCI制品托管配置，替代直接拉取Git仓库 #

OCI制品托管是目前云原生场景下最推荐的配置分发方案，既可以和现有GitOps流程打通，又能完全隔离内部开发资源和对外交付链路

• 内部CI流程每次迭代完稳定配置后，将kustomize的base组件、对外可公开的overlay打包为OCI格式制品，推送到Azure Container Registry(ACR)或其他私有制品仓库
• 客户无需访问任何Git仓库，直接在本地kustomization文件中通过OCI地址拉取配置即可，示例写法：

apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
resources:
  # 拉取公开的基础配置制品
  - oci://<你的ACR域名>/kustomize-config/xxx-service/base:v1.2.3
  # 拉取对应环境的overlay制品
  - oci://<你的ACR域名>/kustomize-config/xxx-service/overlay/prod:v1.2.3

• 可在制品仓库侧精细配置权限，仅给客户开放对应服务、对应版本的制品拉取权限，权限粒度远细于Git仓库权限管控

3. 分层权限管控，避免全量资源暴露 #

如果确实有场景需要客户通过Git拉取配置，可通过以下方式收紧权限：

• 所有内部开发仓库可见性设为私有，仅内部研发人员有权限访问，禁止任何外部协作者加入
• 仅给外部客户开放对外部署配置仓的权限，使用GitHub外部协作者功能、或者只读Deploy Key的方式授权，Deploy Key仅绑定客户的部署服务器，不分配给个人账号
• 禁止对外仓库关联任何内部开发的提交记录、issue、CI日志等信息，避免内部开发流程泄露

4. 敏感配置外置，降低泄露风险 #

所有配置仓库（包括内部私有仓、对外配置仓）均不存储数据库密码、API密钥、证书密钥等敏感信息，对外配置中仅保留敏感配置的占位符，客户部署时通过自身K8S集群的Secret、或Azure Key Vault等服务注入真实敏感值即可，可结合kustomize的secretGenerator功能实现动态生成。 #

内容的提问来源于stack exchange，提问作者Fábio Caramelo