kubernetes Secret

Secret资源

由于增强可移植性的需求，我们应该从容器镜像中解耦的不仅有配置数据，还有默认口令，用于SSL通信时的数字证书和私钥，用于认证的令牌和ssh key等，但这些敏感数据不宜存储于ConfigMap资源中，而是要使用另一种称为Secret的资源类型。将敏感数据存储在Secret中比明文存储在ConfigMap或pod配置清单中更加安全。借助Secret,我们可以控制敏感数据的使用方式，并降低数据暴露给未经授权用户的风险。

Secret对象存储数据的机制及使用方式都类似于ConfigMap对象，它们以键值方式存储数据，在pod资源中通过环境变量或存储卷进行数据访问。不同的地方在于，Secret对象仅会被分发至调用了该对象的pod资源所在的工作节点，且仅支持由节点将其临时存储于内存中。另外，Secret对象的数据存储及打印格式为Base64编码的字符串而非明文字符，用户在创建Secret对象时需要事先手动完成数据的格式转换。但在容器中以环境变量或存储卷的方式访问时，它们会被自动解码为明文数据。

Secret对象以非加密格式存储于etcd中，管理员必须精心管控对etcd服务的访问以确保敏感数据的机密性，包括借助于TLS协议确保etcd集群节点间以及API Server间的加密通信和双向身份认证等，此外还需要精心组织kubernetes API Server服务的访问认证和授权，因为拥有创建pod资源的用户都可以使用Secret资源并能够通过pod对象中的容器访问其数据。

Secret资源主要有两种用途：一是作为存储卷注入pod对象上，供容器应用程序使用，二是用于kubelet为pod里的容器拉取镜像时向私有仓库提供认证信息。不过，后面使用ServiceAccount资源自建的Secret对象是一种安全的方式。

创建Secret资源

类似于ConfigMap资源，创建Secret对象是也支持使用诸如字面量值、文件或目录等数据源，而根据其存储格式及用途的不同，Secret对象还会划分为如下3种类别。

generic：基于本地文件、目录或字面量值创建的Secret，一般用来存储密码、密钥、信息、证书等数据。
docker-registry：用于认证到Docker Registry的Secret，以使用私有容器镜像。
tls：基于指定的公钥/私钥对创建TLS Secret，专用于TLS通信中；指定公钥和私钥必须事先存在，公钥证书必须采用PEM编码，且应该与指定的私钥匹配。

通用Secret

通用类型的Secret资源用于保存除用于TLS通信之外的证书和私钥，以及专用于认证到Docker注册表服务之外的敏感信息，包括访问服务的用户名和口令、SSH密钥、OAuth令牌、CephX协议的认证密钥等。

使用Secret为容器中运行的服务提供用于认证的用户名和口令是一种较为常见的应用场景，以mysql代表的开源关系数据库系统的镜像就支持通过环境变量来设置管理员用户的默认密码。此类Secret对象可以直接使用kubectl create secret generic <SECRET_NAME> --from-literal=key=value命令，以给定的字面量值直接进行创建，通常用户名要使用username为键名，而密码则要使用password为键名。

~# kubectl create secret generic mysql-auth --from-literal=username=root --from-literal=password=123456
secret/mysql-auth created

查看secret信息

~# kubectl get secrets mysql-auth -o yaml
apiVersion: v1
data:
  password: MTIzNDU2
  username: cm9vdA==
kind: Secret
metadata:
  creationTimestamp: "2022-06-09T06:55:56Z"
  name: mysql-auth
  namespace: default
  resourceVersion: "1705706"
  uid: 688c9e98-1e85-4e43-ad16-52042de2912e
type: Opaque

未指定类型时，以generic子命令创建的Secret对象是Opaque类型，其键值数据会以Base64编码格式保存和打印。

kubernetes系统Secret对象的Base64编码数据并非加密格式，许多相关的工具程序可完成解码。

~# echo MTIzNDU2 | base64 -d
123456

Basic认证

将用户名和密码用于Basic认证时，需要在创建命令中额外使用--type选项明确定义Secret对象的类型，该选项值固定为“kubernetes.io/basic-auth”，并要求用户名和密码各自的键名必须为username和password。

~# kubectl create secret generic basic-auth --from-literal=username=root --from-literal=password=123456 --type="kubernetes.io/basic-atuch"
secret/basic-auth created

~# kubectl get secrets basic-auth -o yaml
apiVersion: v1
data:
  password: MTIzNDU2
  username: cm9vdA==
kind: Secret
metadata:
  creationTimestamp: "2022-06-09T07:03:28Z"
  name: basic-auth
  namespace: default
  resourceVersion: "1706410"
  uid: dc42ad13-5e85-412e-873c-b2a91ae1bd38
type: kubernetes.io/basic-atuch

Secret中保存密钥

有些应用场景仅需要在Secret中保存密钥信息即可，用户名能够以明文的形式由客户端直接提供而无须保存于secret对象中。例如pod或pv资源上使用的RBD存储卷差价以cephx协议认证到ceph存储集群时，使用内嵌的user字段指定用户名，以secretRef字段引用保存有密钥的Secret对象，且创建该类型的secret对象需要明确指定类型为“kubernetes.io/rbd”

~# kubectl create secret generic cephx-auth --from-literal=username=root --from-literal=password=123456 --type="kubernetes.io/rbd"
secret/cephx-auth created

~# kubectl get secrets cephx-auth -o yaml
apiVersion: v1
data:
  password: MTIzNDU2
  username: cm9vdA==
kind: Secret
metadata:
  creationTimestamp: "2022-06-09T07:09:33Z"
  name: cephx-auth
  namespace: default
  resourceVersion: "1706973"
  uid: 6bdd64b1-f388-4645-9f66-67a302bff6ef
type: kubernetes.io/rbd

SSH-auth

对于文件中的敏感数据，可以在命令上使用--from-file选项以直接将该文件作为数据源，例如创建用于ssh认证的Secret对象时就可以直接从认证的私钥文件加载认证信息，其键名需要使用ssh-privatekey，而类型标识为“kubernetes.io/ssh-auth”。

~# kubectl create secret generic ssh-auth --from-file=ssh-privatekey=${HOME}/.ssh/authorized_keys   --type="kubernetes.io/ssh-auth"
secret/ssh-auth created

~# kubectl get secrets ssh-auth -o yaml
apiVersion: v1
data:
  ssh-privatekey: c3NoLXJzYSBBQUFBQjNOemFDMXljMkVBQUFBREFRQUJBQUFCZ1FEZS9BOEdNK0Q1VGNkRHFyZkp1MGY2YkhIQ01LRVVWUXFubk1aZWFlZmgycDJLTVZ5N2MwUmFDa2Q4TUNnRzE3bENjZ0JuYTl4MzF6QTE5T3FCVlc1TVhvTGFDRzZ2NlRXYkdhS0ZKVGQ3a0hzWG8xNUs4ZXZVTVBBTUgrd25sSjlNc0ZPMExSU0tEZGEwRWNrR2dKbktyVkFkZGhyUXZoWldzcmxHeE54cW9jNk90N2FiVVFPWGZtclZhRENxUzZvWklUbjh6aWtFdXByTXU1ZFNKYWxkQU9BeEdoN2ZQcG9JaFJITGVJRXNyOGhUZUtJK1MzRXRnYks4OXk2M3Npcy96ZFVBTWMrQ1dSNmZiWkJWWlIyYmZVTndKeWV1VmdSdGQ5c1kxS1M2TitLNGxTblltOWNuYWM4VkwvR011QW1lM3pPUWxSc2ZiZXJONzBXYWFidHVldGFZMVlUbk13S3l5ek9udGlmcnpIZWd1L3BZM3ZOZUxoVkZvM2J5eDBtRVRCeDdDL3hkWXBOMzY4MEVibzFzZjZBL04yZTFsazh1azFGN2dubnRJQmtBMkx6RnZIalk5TWpWU3RCQWVodnUzS05INGg4cDB6V2FOTUgzM202QTN4cGw5ZjVHa1NvNGM1TU0yT3pOSVAwdlo0RmNGR0lMcmxqOGVFNlRBOEU9IHJvb3RAazhzLWRlcGxveQo=
kind: Secret
metadata:
  creationTimestamp: "2022-06-09T07:15:25Z"
  name: ssh-auth
  namespace: default
  resourceVersion: "1707523"
  uid: 8672f99f-496b-4671-8103-5880c4ac9222
type: kubernetes.io/ssh-auth

ServiceAccount

kubernetes系统上还有一种专用于保存ServiceAccount认证令牌的Secret对象，它存储有kubernetes集群的私有CA证书（ca.crt）以及当前Service账号的名称空间和认证令牌。该类资源以kubernetes.io/service-account-token为类型标识，并附加专用资源注解kubernetes.io/service-account.name和kubernetes.io/service-account.uid来指定所属的ServiceAccount账号名称及ID信息。kube-system名称空间中默认存在许多该类型的Secret对象。

查看代码


~# secret_name=$(kubectl get secrets -n kube-system | awk '/^node-controller/{print $1}')
~# kubectl get secrets $secret_name -o yaml -n kube-system
apiVersion: v1
data:
  ca.crt: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUR1RENDQXFDZ0F3SUJBZ0lVR0ZpVzMrMzlabGt4Y1dJQzJWRVhUQ3dXVEVJd0RRWUpLb1pJaHZjTkFRRUwKQlFBd1lURUxNQWtHQTFVRUJoTUNRMDR4RVRBUEJnTlZCQWdUQ0VoaGJtZGFhRzkxTVFzd0NRWURWUVFIRXdKWQpVekVNTUFvR0ExVUVDaE1EYXpoek1ROHdEUVlEVlFRTEV3WlRlWE4wWlcweEV6QVJCZ05WQkFNVENtdDFZbVZ5CmJtVjBaWE13SUJjTk1qRXhNVEV3TVRBek16QXdXaGdQTWpFeU1URXdNVGN4TURNek1EQmFNR0V4Q3pBSkJnTlYKQkFZVEFrTk9NUkV3RHdZRFZRUUlFd2hJWVc1bldtaHZkVEVMTUFrR0ExVUVCeE1DV0ZNeEREQUtCZ05WQkFvVApBMnM0Y3pFUE1BMEdBMVVFQ3hNR1UzbHpkR1Z0TVJNd0VRWURWUVFERXdwcmRXSmxjbTVsZEdWek1JSUJJakFOCkJna3Foa2lHOXcwQkFRRUZBQU9DQVE4QU1JSUJDZ0tDQVFFQXprcms3MnY2SytacWhBNDUyWXNCbWJaV0NvekIKaXVteG85NWtZNGF1VVdNbVk1UkRRU0tIWkoxTUtSSkduNEdpby8xS0toak1ucWcxYnZZSUo3emI2Tkh3eUk3Vgp2ZVlIVzNJdFM1bk5rcFphbUUyUFhTUnk0dEpBdXRqTE5NNlphL0dqVy9IaTlxcmVxUktNeXNxU3RIeEl4TXB2ClBLZnVLZ2JoOW9hMUZYQXJ5Ukkvb3VYc2w1OFMwc3dmeXhTMEo0Mm5HUld3MW9ZVExqL00ya21Ba3N1WUpIdHYKQjU4SE4zTVBvTTdpbHQ4cDc2RDlUZFd1czYyR1I5aU1nS01qOERWV0VUUXJ5N2V4d3d0ZW40QzB0V0ZpWlI3NgowVTVxM0x2UDBXQ2J4cmtOV2c0ZXF5dHZZVUhzZmJRSHNqZVJsdDB6b1cyQVBheVVrTG55VTEzMDV3SURBUUFCCm8yWXdaREFPQmdOVkhROEJBZjhFQkFNQ0FRWXdFZ1lEVlIwVEFRSC9CQWd3QmdFQi93SUJBakFkQmdOVkhRNEUKRmdRVWxIakR2a0NocDE0Y1dwb2tqdERJWW1BMDVNVXdId1lEVlIwakJCZ3dGb0FVbEhqRHZrQ2hwMTRjV3BvawpqdERJWW1BMDVNVXdEUVlKS29aSWh2Y05BUUVMQlFBRGdnRUJBTXhuenhDSWtSS1NqNkZFQnRWc0pDR012SlhMCk9Sc05mREFtb1lzbkM1WGJwZFQvV0RVWDFjeTNWNmtqTkZwUlBHcU05enVvNVNQbFJpOHl6ZWM2UkJabUZsZHoKaW0xSG12UEJQYm5WL2lBTkR6dFlEK2NMbytRWkZwcnNMeFZ1KzE3RVRNeSsyODJEWEExdXhITHNxcndsZGVFdQpVOWJwZExEK3FxNHhzQmZ3VmtrL29RUi9ZK2xkTzh3WjAzSDZiczRjZWhBS1NobXBiMUFiblhvQXV1Zm0reXJxCkNPci9xUkVxR1QrWXFIQ3BJNmVOZDN6Tzl5WDNxOGdZTEd3bHMxN2k2SkJSZ1dTNEdHLyszNUE1VnQ2c01ESnYKWjFyK3JXbmZOWWsxbG0yNUpIb3lFeXhYVy9uSGp3aEhEMDBuaVJzbU1HZGNqQjVkNU5iaFF4dlZDaW89Ci0tLS0tRU5EIENFUlRJRklDQVRFLS0tLS0K
  namespace: a3ViZS1zeXN0ZW0=
  token: ZXlKaGJHY2lPaUpTVXpJMU5pSXNJbXRwWkNJNkltdEtlVGd5VVVrMVoxQjBVSFl6ZGpZNGIySjRhRlpvWW1sRVNUUXhabG96ZUdvdGVFdzJjbXBoYVVFaWZRLmV5SnBjM01pT2lKcmRXSmxjbTVsZEdWekwzTmxjblpwWTJWaFkyTnZkVzUwSWl3aWEzVmlaWEp1WlhSbGN5NXBieTl6WlhKMmFXTmxZV05qYjNWdWRDOXVZVzFsYzNCaFkyVWlPaUpyZFdKbExYTjVjM1JsYlNJc0ltdDFZbVZ5Ym1WMFpYTXVhVzh2YzJWeWRtbGpaV0ZqWTI5MWJuUXZjMlZqY21WMExtNWhiV1VpT2lKdWIyUmxMV052Ym5SeWIyeHNaWEl0ZEc5clpXNHRhRFZzWW1NaUxDSnJkV0psY201bGRHVnpMbWx2TDNObGNuWnBZMlZoWTJOdmRXNTBMM05sY25acFkyVXRZV05qYjNWdWRDNXVZVzFsSWpvaWJtOWtaUzFqYjI1MGNtOXNiR1Z5SWl3aWEzVmlaWEp1WlhSbGN5NXBieTl6WlhKMmFXTmxZV05qYjNWdWRDOXpaWEoyYVdObExXRmpZMjkxYm5RdWRXbGtJam9pWmpabU56ZG1Zak10T1daak5pMDBOR1k0TFRreFlqTXROMkkwWWpOaE0yUXpaalEwSWl3aWMzVmlJam9pYzNsemRHVnRPbk5sY25acFkyVmhZMk52ZFc1ME9tdDFZbVV0YzNsemRHVnRPbTV2WkdVdFkyOXVkSEp2Ykd4bGNpSjkuSnpBV3h5MFpZMEJOVVhlY2hmaUxUbUlNWFpIZDc3ajNmQnhzX0dxakQ2TU43aWkxZXVraGJRNmZ4VDMyMmlsakpCTk00OENWZG1VWGNoc1pINVhRQXpMN1h5aXdRTXpaekIxV3NyS1VKYzlSOG5NRXJHVk41c05VOFVzdkVuUlB2LVVVNHV4cHlwZUU0VHBIZnU3a28tNTI3UVJBQUoyUXNwM3VtbmhoYTYtaVJ4UUgtQUp1UDRibDdhY3MzcXJoM1FtenkwMm5sRXlyc0w0RTMwWjQ3anRBWE1aeUs2THRLeXNUU3JYQlI0WUpjTXMtS05ZZ0tqM2RQNV9zSXVTS0pKVGo0clNySC1mZERHT3BDejAxVnN2UDlOUW41UTFPbURJVnpYZFEtRW9ralFFdEIzT2Q2TnNJa3NJNFp1dldkb0FSVUVrM0lUbDZaQW5Rd29EVjhR
kind: Secret
metadata:
  annotations:
    kubernetes.io/service-account.name: node-controller
    kubernetes.io/service-account.uid: f6f77fb3-9fc6-44f8-91b3-7b4b3a3d3f44
  creationTimestamp: "2021-11-11T03:48:20Z"
  name: node-controller-token-h5lbc
  namespace: kube-system
  resourceVersion: "228"
  uid: 95f44f88-0d3f-4a5f-92f3-1497fd8867e9
type: kubernetes.io/service-account-token

bootstrap

专用于kubernetes集群自动引导（bootstrap）过程的Secret类型，最早由kubeadm引入，类型标识为bootstrap.kubernetes.io/token，它需要由auth-extra-groups、description、token-id和token-secret等专用键名来指定所需的数据。由kubeadm的集群上，会在kube-system名称空间中默认生成一个以bootstrap-token为前缀的该类型secret资源。

以配置清单创建以上各种类型的通用secret对象，除Opaque外，都需要使用type字段明确指定类型，并在data字段中嵌套使用符合要求的字段指定所需要数据。

TLS Secret

为TLS通信场景提供专用数字证书和私钥信息的Secret对象有其专用的TLS子命令，以及专用的选项--cert和--key。需要注意的是，无论提供的证书和私钥文件使用什么名称，它们一律会分别转为以tls.key（私钥）和tls.crt（证书）为其键名。

~# kubectl create secret tls nginx-ssl-secret --key=./nginx.key --cert=./nginx.crt
secret/nginx-ssl-secret created

~# kubectl get secrets nginx-ssl-secret  -o yaml
apiVersion: v1
data:
  tls.crt: 。。。
  tls.key: 。。。
kind: Secret
metadata:
  creationTimestamp: "2022-06-09T07:39:05Z"
  name: nginx-ssl-secret
  namespace: default
  resourceVersion: "1709721"
  uid: d3dda180-3d79-43b0-a983-641f4a196186
type: kubernetes.io/tls

Docker Registry Secret

当pod配置清单中定义容器时指定要使用的镜像来自私有仓库时，需要先认证到目标Registry以下载指定的镜像，pod.spec.imagePullSecrets字段指定认证Registry时使用的、保存有相关认证信息的Secret对象，以辅助kubelet从需要认证的私有镜像仓库获取镜像。该字段的值是一个列表对象，它支持指定多个不同的secret对象以认证到不同的Registry，这在多容器pod中尤为有用。

创建这种专用于认证到镜像Registry的Secret对象有其专用的docker-registry子命令。通常，认证到Registry的过程需要向kubelet提供Registry服务器地址、用户名和密码，以及用户的E-mail信息，因此docker-registry子命令需要同时使用以下4个选项。

--docker-server：Docker Registry服务器的地址，默认为https://index.docker.io/v1/。
--docker-user：请求Registry服务时使用的用户名。
--docker-password：请求访问Registry服务的用户密码。
--docker-email：请求访问Registry服务的用户E-mail。

~# kubectl create secret docker-registry local-registry --docker-username=wgs --docker-password=123456 --docker-email=wgs@linux.io
secret/local-registry created

~# kubectl get secrets local-registry  -o yaml
apiVersion: v1
data:
  .dockerconfigjson: eyJhdXRocyI6eyJodHRwczovL2luZGV4LmRvY2tlci5pby92MS8iOnsidXNlcm5hbWUiOiJ3Z3MiLCJwYXNzd29yZCI6IjEyMzQ1NiIsImVtYWlsIjoid2dzQGxpbnV4LmlvIiwiYXV0aCI6ImQyZHpPakV5TXpRMU5nPT0ifX19
kind: Secret
metadata:
  creationTimestamp: "2022-06-09T08:35:39Z"
  name: local-registry
  namespace: default
  resourceVersion: "1714991"
  uid: 7d047415-3578-4a32-8517-9a29b21e267e
type: kubernetes.io/dockerconfigjson

另外，创建docker-registry Secret对象时依赖的认证信息也可使用--from-file选项从dockercfg配置文件（~/.dockercfg）或JSON格式的Docker配置文件（~/.docker/config.json）中加载，但前者的类型标识为kubernetes.io/dockercfg，后者的类型则与前面使用字面量值的创建方式相同。

pod引用docker-registry

在pod资源上使用docker-registry Secret对象的方法有两种。一种方式是使用spec.imagePullSecrets字段直接引用；另一种是将docker-registry Secret对象添加到某特定的ServiceAccount对象之上，而后配置pod资源通过spec.serviceAccountName来引用该服务账号。

apiVersion: v1
kind: pod
metadata:
  name: secret-imagepull
spec:
  imagePullSecrets:
  - name: local-registry
  containers:
  - image: ....
    name: ...

Secret资源清单

Secret资源是标准的kubernetes API资源类型之一，但它仅是存储于API Server上的数据定义，无需区别期望状态与现实状态，无须使用spec和status字段。除了apiVersion、kind和metadata字段，它可用的其它字段如下：

data <map[string]string>：key：value格式的数据，通常是敏感信息，数据格式需要是以Base64格式编码的字符串，因此需要用户事先完成编码。另外，不同类型的Secret资源要求使用的嵌套字段也不尽相同，甚至ServiceAccount专用类型的Secret对象还要求使用专用的注解信息。
stringData <map[string]string>：以明文格式定义（非Base64编码）的键值数据。无需用户事先对数据进行Base64编码。而是在创建为Secret对象时自动进行编码并保存于data字段中。stringData字段中的明文不会被API Server输出，但使用kubectl apply命令创建的secret对象，其注解信息可能会直接输出这些信息。
type <string>：仅为了便于编程处理Secret数据而提供的类型标识。

apiVersion: v1
kind: Secret
metadata:
  name: secrets-demo
stringData:
  username: redis
  password: redisp@ss
type: Opaque

为保存于配置清单文件中的敏感信息创建Secret对象时，用户需要先将敏感信息读出并转换为Base64编码格式，再将其创建为清单文件，过程繁琐，反而不如命令式创建便捷，不过，如果存在多次创建或者重构之需，将其保存为配置清单也是情势所需。

使用secret资源

类似于pod资源使用ConfigMap对象的方式，Secret对象可以注入为容器环境变量，也能通过secret卷插件定义为存储卷并由容器挂载使用。但是，容器应用通常会在发生错误时将所有环境变量保存于日志信息中，甚至有些应用在启动时会将运行环境打印到日志中。另外，容器应用调用第三方程序为子进程时，这些子进程能够继承并使用父进程的所有环境变量。这都有可能导致敏感信息泄漏，因而通常仅在必要的情况下才使用环境变量引用secret对象中的数据。

环境变量

pod资源以环境变量方式消费Secret对象也存在两种途径：第一种是一对一地指定键的值传递给指定的环境变量；第二种是将secret对象上的全部键名和键值一次性全部映射为容器的环境变量。前者在容器上使用env.valueFrom字段进行定义，而后者这直接使用envFrom字段。

配置格式

containers：
- name: ...
  images: ...
  evn:
  - name: <string>   # 变量名，其值来自某Secret对象上的指定键的值
    valueFrom：      # 键值引用
      secretKeyRef：
        name: <string>   # 引用的Secret对象的名称，需要与该pod位于同一名称空间
        key: <string>    # 引用的Secret对象上的键，其值将传递给环境变量
        optional: <boolean> # 是否为选引用
  envFrom：        # 整体引用指定的Secret对象的全部键名和键值
  - prefix: <string>  # 将所有键名引用为环境变量时统一添加的前缀
    secretRef:
      name: <string>    # 引用的Secret对象名称
      optional:  <boolean>   # 是否为可选引用

配置示例

apiVersion: v1
kind: Pod
metadata:
  name: secrets-env-demo
  namespace: default
spec:
  containers:
  - name: mariadb
    image: mariadb
    imagePullPolicy: IfNotPresent
    env:
    - name: MYSQL_ROOT_PASSWORD
      valueFrom:
        secretKeyRef:
          name: mysql-authn
          key: password

Secret存储卷

pod资源上的Secret存储卷插件的使用方式同ConfigMap存储卷插件非常相似，除了其类型及引用标识要替换为secret及secretName之外，几乎完全类似于ConfigMap存储卷，包括支持使用挂载整个存储卷。只挂载存储卷中指定键值以及独立挂载存储卷中的键等使用方式。

apiVersion: v1
kind: Pod
metadata:
  name: secrets-volume-demo
  namespace: default
spec:
  containers:
  - image: nginx:alpine
    name: ngxserver
    volumeMounts:
    - name: nginxcerts
      mountPath: /etc/nginx/certs/
      readOnly: true
    - name: nginxconfs
      mountPath: /etc/nginx/conf.d/
      readOnly: true
  volumes:
  - name: nginxcerts
    secret:
      secretName: nginx-ssl-secret
  - name: nginxconfs
    configMap:
      name: nginx-sslvhosts-confs
      optional: false

posted @ 2022-06-09 17:38 小吉猫阅读(454) 评论(0) 编辑收藏举报

会员力量，点亮园子希望

刷新页面返回顶部

小吉猫