OpenShift集群配置Webhook认证器遇配置被覆盖问题求助

我之前在Kubernetes集群成功搞定了webhook authenticator：通过--authentication-token-webhook-config-file=/etc/kubernetes/manifests/customconfigs/auth-config.yml指定外部认证端点，用curl -k https://CLUSTER_ENDPOINT:6443/api --header "Authorization: Bearer <TOKEN>"测试时，外部认证服务能正常收到POST请求。

现在在本地CRC OpenShift集群测试（刚接触OCP），碰到个麻烦：任何配置修改都会被其他Operator/控制器覆盖。想请教两个问题：

1. 配置为啥会被覆盖（我猜是观察者机制导致的），怎么解决？
2. OpenShift里有没有认证相关的主配置？能不能实现webhook authenticator？

1. 配置被覆盖的原因及解决办法 #

OpenShift的控制平面组件（比如kube-apiserver）是由Cluster Version Operator (CVO) 和对应组件的Operator（比如kube-apiserver Operator）管控的，这些Operator会一直盯着组件的期望状态，一旦发现你手动改的配置和Operator维护的期望状态不一样，就会自动给你改回去——这就是配置被覆盖的根本原因。

解决步骤：

• 别直接去改静态配置文件，得用OpenShift提供的自定义资源（CR）来调整。针对kube-apiserver，你需要编辑KubeAPIServer这个CR，把webhook相关配置加进去。
• 举个配置例子：

  apiVersion: config.openshift.io/v1
  kind: KubeAPIServer
  metadata:
    name: cluster
  spec:
    authentication:
      tokenWebhook:
        config:
          file: /etc/kubernetes/manifests/customconfigs/auth-config.yml
  

• 注意：要确保你的auth-config.yml文件在kube-apiserver容器的挂载范围内，如果是自定义文件，可能需要先把文件放到对应的Secret里，再挂载到容器中，再在CR里引用路径。

2. OpenShift的认证主配置及webhook支持 #

OpenShift有专门的认证核心配置，就是OAuth CR（config.openshift.io/v1版本），不过这个是管OpenShift自带的OAuth认证体系的。而你要的Kubernetes原生token webhook authenticator，OpenShift完全支持，只是不能像原生K8s那样直接改apiserver启动参数，必须通过Operator管理的CR来配置。

简单说：

• OpenShift的kube-apiserver和原生K8s的apiserver功能一致，支持token webhook认证，只是配置方式要符合OpenShift的Operator管理逻辑，通过KubeAPIServer CR来注入对应的启动参数或配置。
• 如果你需要的是和K8s完全一致的token webhook认证流程，直接通过KubeAPIServer CR配置就行，不用动OAuth CR。

内容的提问来源于stack exchange，提问作者vijeth.ag