Kubernetes 集群安全

最新推荐文章于 2023-06-24 10:36:45 发布
最新推荐文章于 2023-06-24 10:36:45 发布
阅读量613 收藏 3
点赞数 1
分类专栏： # K8s 文章标签： kubernetes 运维 安全 linux
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/qq_39578545/article/details/108938369
版权

集群安全

一、机制说明

Kubernetes作为一个分布式集群的管理工具，保证集群的安全性是其一个重要的任务。API Server 是集群内部各个组件通信的中介，也是外部控制的入口。所以Kubernetes的安全机制基本就是围绕保护API Server来设计的。Kubernetes使用了认证（Authentication）、鉴权（Authorization）、准入控制（Admission Control）三步来保证API Server的安全

二、Authentication（认证）

2.1 认证方式

  • HTTP Token 认证：通过一个Token来识别合法用户
    HTTP Token认证是用一个很长的特殊编码方式的并且难以被模仿的字符串Token来表达客户的一种方式。Token是一个很长的很复杂的字符串，每一个Token对应一个用户名存储在API Server能访问的文件中。当客户端发起API调用请求时，需要在HTTP Header里放入Token
  • HTTP Base 认证：通过用户名+密码的方式认证
    用户名:密码用BASE64算法进行编码后的字符串放在HTTP Request中的HeatherAuthorization域里发送给服务端，服务端收到后进行编码，获取用户名及密码
  • HTTPS证书认证：基于CA根证书签名的客户端身份认证方式（双向认证） —— 基本常用❤

在这里插入图片描述
在这里插入图片描述
htps证书加密的工作流程

  1. https证书加密的第一步是认证服务器。
    一些主流浏览器会内置一个受信任的CA机构列表，并会保存相关CA机构的https证书。当用户在访问部署了https证书的网站时，服务器会提供经CA机构颁发的https证书，如果认证该服务器证书的CA机构是存在于浏览器的受信任CA机构列表当中，并且该https证书中的所有信息均与当前证在访问的网站所有信息一致，那么浏览器就会认为服务端是可信的，并从https证书中取得公钥（也就是CSR文件），用于后面的流程。

  2. https证书加密的第二步是协商会话秘钥。
    在服务器认证完获取公钥之后，利用公钥与服务器进行加密通信，协商出两个会话秘钥，用于加密客户端和加密服务端互发数据时的会话秘钥。这个秘钥是随机生成的，每一次协商产生的结果都不一样，所以安全性也是比较高的。

  3. https证书加密的第三步是加密传输。
    当客户端和服务器端都拥有了协商的会话密钥之后，进行数据传输时，都是以密文的方式进行传输。这样的传输方式，保证了数据的私密性和完整性，再也不用担心数据在传输过程中被第三者窃取和篡改了。

  1. 客户端发起HTTPS请求
  2. 服务端的配置
    采用HTTPS协议的服务器必须要有一套数字证书，可以是自己制作或者CA证书。区别就是自己颁发的证书需要客户端验证通过，才可以继续访问，而使用CA证书则不会弹出提示页面。这套证书其实就是一对公钥和私钥。公钥给别人加密使用，私钥给自己解密使用。
  3. 服务端传送证书
    这个证书其实就是公钥，只是包含了很多信息，如证书的颁发机构，过期时间等。
  4. 客户端解析证书
    这部分工作是有客户端的TLS来完成的，首先会验证公钥是否有效，比如颁发机构，过期时间等，如果发现异常，则会弹出一个警告框，提示证书存在问题。如果证书没有问题，那么就生成一个随即值，然后用证书对该随机值进行加密。
  5. 客户端传送加密证书信息
    这部分传送的是用证书加密后的随机值，目的就是让服务端得到这个随机值，以后客户端和服务端的通信就可以通过这个随机值来进行加密解密了。
  6. 服务端解密证书信息
    服务端用私钥解密后，得到了客户端传过来的随机值(私钥)，然后把内容通过该值进行对称加密。所谓对称加密就是，将信息和私钥通过某种算法混合在一起，这样除非知道私钥，不然无法获取内容，而正好客户端和服务端都知道这个私钥，所以只要加密算法够彪悍，私钥够复杂，数据就够安全。
  7. 传输加密后的信息
    这部分信息是服务段用私钥加密后的信息，可以在客户端被还原。
  8. 客户端解密信息
    客户端用之前生成的私钥解密服务段传过来的信息，于是获取了解密后的内容。
    PS: 整个握手过程第三方即使监听到了数据，也束手无策。

2.2 需要认证节点

在这里插入图片描述两种类型

  • Kubenetes组件对API Server的访问：kubectl、Controller Manager、Scheduler、kubelet、kube-proxy

  • Kubenetes 管理的Pod对容器的访问：Pod（dashborad也是以Pod形式运行）

安全性说明：

  • Controller Manager、Scheduler与API Server在同一台机器，所以直接使用API Server的非安全端口访问，–insecure-bind-address=127.0.0.1
  • kubectl、kubelet、kube-proxy访问API Server就都需要证书进行HTTPS双向认证

证书颁发：

  • 手动签发：通过K8S集群的跟CA进行签发HTTPS证书
  • 自动签发：Kubelet首次访问API Server时，使用token做认证，通过后，Controller Manager会为kubelet生成一个证书，以后的访问都是用证书做认证了

2.3 kubeconfig

kubeconfig文件包含集群参数（CA证书、API Server地址），客户端参数（上面生成的证书和私钥），集群context 信息（集群名称、用户名）Kubenetes组件通过启动时指定不同的 kubeconfig文件可以切换到不同的集群。

cd ~/.kube
cat config

2.4 ServiceAccount

Pod中的容器访问API Server。因为Pod的创建、销毁是动态的，所以要为它手动生成证书就不可行了。Kubenetes使用了Service Account解决Pod访问API Server的认证问题

2.5 Secret 与 SA 的关系

K8S设计了一种资源对象叫做Secret，分为两类，一种是用于ServiceAccount的service-account-token，另一种是用于保存用户自定义保密信息的Opaque。ServiceAccount中用到包含三个部分：Token、ca.crt、namespace。

  • token：使用API Server私钥签名的JWT（Json web token，基于JSON的开放标准）。用于访问API Server时，Server端认证
  • ca.crt：根证书，用于Client端验证API Server发送的证书
  • namespace：标识这个service-account-token的作用域名空间
kubectl get secret --all-namespaces
kubectl describe secret default-token-5gm9r --namespace=kube-system
kubectl get pod -n kube-system
kubectl exec kube-proxy-fb85x -n kube-system -it -- /bin/sh
# ls /run/secrets/kubernetes.io/serviceaccount

默认情况下，每个namespace都会有一个ServiceAccount，如果Pod在创建时没有指定ServiceAccount,
就会使用Pod所需的enamespace的ServiceAccount
默认挂载目录：/run/secrets/kubernetes.io/serviceaccount

在这里插入图片描述
 

三、Authorization（鉴权）

上面认证过程，只是确认通信的双方都确认了对方是可信的，可以相互通信。而鉴权是确定请求方有哪些资源的权限。API Server目前支持以下几种授权策略（通过API Server的启动参数–authorization-mode设置）

  • AlwaysDeny：表示拒绝所有的请求，一般用于测试
  • AlwaysAllow：允许接收所有请求，如果集群不需要授权流程，则可以采用该策略
  • ABAC（Attribute-Based Access Control）：基于属性的访问控制，表示使用用户配置的授权规则对用户请求进行匹配和控制。（需要重启API Server生效）
  • Webbook：通过调用外部REST服务对用户进行授权
  • RBAC（Role-Based Access Control）：基于角色的访问控制，现行默认规则

3.1 RBAC授权模式❤

RBAC（Role-Based Access Control）基于角色的访问控制，在Kubernetes 1.5中引入，现行版本成为默认标准。相对其它访问控制方式，拥有以下优势：

  • 对集群中的资源（如deployment，pod，cpu）和非资源（如pod状态）均拥有完整的覆盖
  • 整个RBAC完全由几个 API 对象完成，同其它API对象一样，可以用kubectl或API进行操作
  • 可以在运行时进行调整，无需重启API Server

1、RBAC的API资源对象说明
RBAC引入了4个新的顶级资源对象：Role、ClusterRole、RoleBinding、ClusterRoleBinding，4 种对象类型均可以通过kubectl与API操作
在这里插入图片描述
Kubenetes组件（kubectl、kube-proxy）或是其他自定义的用户在向CA申请证书时，需要提供一个证书请求文件(用户、组在这里面定义)：

{
	"CN": "admin", # 用户名
	"hosts": [],
	"key": {
		"algo": "rsa",
		"size": 2048
	},
	"names": [{
		"C": "CN",
		"ST": "HangZhou",
		"L": "XS",
		"O": "system:masters",  # O就是组织
		"OU": "System"
	}]
}

API Server会把客户端证书的CN字段作为User，把names.O字段作为Group；

kubelet使用 TLS Bootstaping认证时，API Server可以使用Bootstrap Tokens或者Token authenticationfile验证token，无论哪一种，Kubenetes都会为token绑定一个默认的User和 Group；

Pod使用 ServiceAccount认证时，service-account-token中的JWT会保存User信息；

有了用户信息，再创建一对角色/角色绑定(集群角色/集群角色绑定)资源对象，就可以完成权限绑定了

3.2 Role and ClusterRole

在RBAC API中，Role表示一组规则权限，权限只会增加(累加权限，设置表示能干什么，而不能设置不能干什么)，不存在一个资源一开始就有很多权限而通过RBAC对其进行减少的操作；Role可以定义在一个namespace中，如果想要跨namespace则可以创建ClusterRole。

kind: Role
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata: 
  namespace: default
  name: pod-reader
rules: 
- apiGroups: [""]#"" indicates the core API group
  resources: ["pods"]
  verbs: ["get", "watch", "list"]

ClusterRole具有与Role相同的权限角色控制能力，不同的是ClusterRole是集群级别的，ClusterRole可以用于：

  • 集群级别的资源控制( 例如node访问权限 )
  • 非资源型endpoints( 例如/healthz访问 )
  • 所有命名空间资源控制(例如pods )
kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
  name: secret-reader
rules:
- apiGroups: [""]
  resources: ["secrets"]
  verbs: ["get","watch","list"]

3.3 RoleBinding and ClusterRoleBinding

RoloBinding可以将角色中定义的权限授予用户或用户组，RoleBinding包含一组权限列表(subjects)，权限列表中包含有不同形式的待授予权限资源类型**(users、groups、service accounts)；** RoloBinding同样包含对被Bind的Role引用；RoleBinding适用于某个命名空间内授权，而ClusterRoleBinding适用于集群范围内的授权。

将default命名空间的pod-readerRole授予jane用户，此后jane用户在default命名空间中将具有pod-reader的权限：

kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:  
  name: read-pods 
  namespace: default
subjects:
- kind: User  
  name: jane  
  apiGroup: rbac.authorization.k8s.io
roleRef:  
  kind: Role  
  name: pod-reader  
  apiGroup: rbac.authorization.k8s.io

RoleBinding同样可以引用ClusterRole来对当前namespace内用户、用户组或ServiceAccount进行授权，这种操作允许集群管理员在整个集群内定义一些通用的ClusterRole，然后在不同的 namespace中使用RoleBinding来引用。

例如，以下RoleBinding引用了一个ClusterRole，这个ClusterRole具有整个集群内对secrets的访问权限；但是其授权用户dave只能访问development空间中的secrets(因为RoleBinding定义在development命名空间）

kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
  name: read-secrets
  namespace: development
subjects:
- kind: User  
  name: dave  
  apiGroup: rbac.authorization.k8s.io
roleRef:  
  kind: ClusterRole  
  name: secret-reader  
  apiGroup: rbac.authorization.k8s.io

使用ClusterRoleBinding可以对整个集群中的所有命名空间资源权限进行授权；以下 ClusterRoleBinding样例展示了授权manager组内所有用户在全部命名空间中对secrets进行访问：

kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:  
  name: read-secrets-global
subjects:
- kind: Group # 组
  name: manager  # 组名
  apiGroup: rbac.authorization.k8s.io
roleRef:  
  kind: ClusterRole  
  name: secret-reader  
  apiGroup: rbac.authorization.k8s.io

3.4 Resources

Kubernetes集群内一些资源一般以其名称字符串来表示，这些字符串一般会在API的URL地址中出现；同时某些资源也会包含子资源，例如logs资源就属于pods的子资源，API中URL样例如：GET /api/v1/namespaces/{namespace}/pods/{name}/log

如果要在RBAC授权模型中控制这些子资源的访问权限，可以通过/分隔符来实现，以下是一个定义pods资资源logs访问权限的Role定义样例

kind: Role
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:  
  namespace: default 
  name: pod-and-pod-logs-reader
rules:
- apiGroups: [""]  
  resources: ["pods/log"]  # 仅仅只能看pod的日志信息
  verbs: ["get","list"] # 动作类型，获取和列出

3.5 to Subjects

RoleBinding和ClusterRoleBinding可以将Role绑定到Subjects；Subjects可以是groups、users或者service accounts。

Subjects中Users使用字符串表示，但是Users的前缀system:是系统保留的，集群管理员应该确保普通用户不会使用这个前缀格式，

Groups命名同Users。都为一个字符串，并且没有特定的格式要求；同样system前缀为系统保留

 

★四、创建用户和授权

实例：创建一个用户只能管理dev空间

#创建用户
[root@k8s-master01 ~]# useradd devuser
[root@k8s-master01 ~]# passwd devuser


# 创建命名空间
[root@k8s-master01 ~]# kubectl create namespace dev
namespace/dev created

#创建证书请求文件，即指定用户
[root@k8s-master01 ~]# mkdir -p /usr/local/install-k8s/cert/devuser
[root@k8s-master01 ~]# cd /usr/local/install-k8s/cert/devuser
[root@k8s-master01 devuser]# vim devuser-csr.json
{
	"CN": "devuser",
	"hosts": [], # 可以使用主机，不写代表所有
	"key": {
		"algo": "rsa", # rsa算法
		"size": 2048
	},
	"names": [{
		"C": "CN",
		"ST": "BeiJing",
		"L": "BeiJing",
		"O": "k8s", # 组名
		"OU": "System"
	}]
}

#下载证书生成工具
wget https://pkg.cfssl.org/R1.2/cfssl_linux-amd64
mv cfssl_linux-amd64 /usr/local/bin/cfssl

wget https://pkg.cfssl.org/R1.2/cfssljson_linux-amd64
mv cfssljson_linux-amd64 /usr/local/bin/cfssljson

wget https://pkg.cfssl.org/R1.2/cfssl-certinfo_linux-amd64
mv cfssl-certinfo_linux-amd64 /usr/local/bin/cfssl-certinfo

#证书生成工具移至/usr/local/bin
[root@k8s-master01 bin]# ls
cfssl  cfssl-certinfo  cfssljson

#生成证书等文件，ca证书，ca私钥，创建json的文件。 ——》 输出到devuser文件
[root@k8s-master01 devuser]# cd /etc/kubernetes/pki/
[root@k8s-master01 pki]# cfssl gencert -ca=ca.crt -ca-key=ca.key  -profile=kubernetes \
/usr/local/install-k8s/cert/devuser/devuser-csr.json | cfssljson -bare devuser

在这里插入图片描述

#设置集群参数  master的IP地址
[root@k8s-master01 pki]# export KUBE_APISERVER="https://10.0.100.10:6443"
[root@k8s-master01 pki]# kubectl config set-cluster kubernetes --certificate-authority=/etc/kubernetes/pki/ca.crt --embed-certs=true --server=${KUBE_APISERVER}  --kubeconfig=devuser.kubeconfig

解析：
[root@k8s-master01 pki]# kubectl config set-cluster kubernetes \
--certificate-authority=/etc/kubernetes/pki/ca.crt \ #指定ca证书
--embed-certs=true \ #指定是否加密认证
--server=${KUBE_APISERVER} \ #指定服务器信息
--kubeconfig=devuser.kubeconfig #创建出devuser.kubeconfig文件

在这里插入图片描述
还是空的因为下面就要设置参数

#设置客户端认证参数,多了用户的信息，私钥信息
[root@k8s-master01 pki]# kubectl config set-credentials devuser \
--client-certificate=/etc/kubernetes/pki/devuser.pem \
--client-key=/etc/kubernetes/pki/devuser-key.pem \
--embed-certs=true \
--kubeconfig=devuser.kubeconfig

#设置上下文参数,绑定至某个名字空间
[root@k8s-master01 pki]# kubectl config set-context kubernetes \
--cluster=kubernetes \ #默认
--user=devuser \
--namespace=dev \
--kubeconfig=devuser.kubeconfig

在这里插入图片描述

#复制文件至用户devuser下并修改权限,修改配置文件名称为config
[root@k8s-master01 pki]# mkdir -p /home/devuser/.kube/
[root@k8s-master01 pki]# cp ./devuser.kubeconfig /home/devuser/.kube/config
[root@k8s-master01 pki]# chown devuser:devuser /home/devuser/.kube/config

#赋予admin管理员角色给用户
[root@k8s-master01 devuser]# kubectl create rolebinding devuser-admin-binding --clusterrole=admin --user=devuser --namespace=dev


切换到devuser操作
# 设置默认上下文，让kubectl读取到配置信息
[devuser@k8s-master01 ~]$ cd .kube/
[devuser@k8s-master01 .kube]$ chmod +x config 
[devuser@k8s-master01 .kube]$ kubectl config use-context kubernetes --kubeconfig=config


# 创建pod
[devuser@k8s-master01 .kube]$ kubectl run nginx --image=hub.atguigu.com/library/myapp:v1
[devuser@k8s-master01 .kube]$ kubectl get pod
NAME                     READY   STATUS    RESTARTS   AGE
nginx-55d45f8bd4-9w5n9    1/1     Running   0          9s

# 查看具体信息
[root@k8s-master01 pki]# kubectl get pod --all-namespaces -o wide | grep nginx
dev             nginx-55d45f8bd4-9w5n9                      1/1     Running   0          53s     10.244.1.73   k8s-node02     <none>           <none>

在这里插入图片描述

#该用户只能访问dev命名空间下的资源，进不了default
[devuser@k8s-master01 .kube]$ kubectl get pod -n default
Error from server (Forbidden): pods is forbidden: User "devuser" cannot list resource "pods" in API group "" in the namespace "default"

在这里插入图片描述

 

五、准入控制

准入控制是API Server的插件集合，通过添加不同的插件，实现额外的准入控制规则。甚至于API Server的一些主要的功能都需要通过Admission Controllers实现，比如ServiceAccount

官方文档上有一份针对不同版本的准入控制器推荐列表，其中最新的1.14的推荐列表是

NamespaceLifecycle,LimitRanger,ServiceAccount,DefaultStorageClass,DefaultTolerationSeconds,
MutatingAdmissionWebhook,ValidatingAdmissionWebhook,ResourceQuot

列举几个插件的功能（不同的插件实现不同的功能）：

  • NamespaceLifecycle：防止在不存在的namespace上创建对象，防止删除系统预置 namespace，删除namespace时，连带删除它的所有资源对象。
  • LimitRanger：确保请求的资源不会超过资源所在Namespace的LimitRange的限制。
  • ServiceAccount：实现了自动化添加ServiceAccount
  • ResourceQuota：确保请求的资源不会超过资源的ResourceQuota限制
果子哥丶
关注
  • 1
    点赞
  • 踩
  • 3
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
专栏目录
Kubernetes 集群安全-教程与笔记习题
05-22
Kubernetes 集群安全
Kubernetes之secrets使用
Harry的博客
10-11 3699
​ Secret解决了密码、token、密钥等敏感数据的配置问题，而不需要把这些敏感数据暴露到镜像或者Pod Spec中。Secret可以以Volume或者环境变量的方式使用。 ​
Kubernetes中Secret使用详解
全栈工程师开发手册（原创）https://github.com/tencentmusic/cube-studio
10-26 1万+
Secret解决了密码、token、密钥等敏感数据的配置问题，而不需要把这些敏感数据暴露到镜像或者Pod Spec中。Secret可以以Volume或者环境变量的方式使用。 Secret类型 Secret有三种类型： Opaque：base64编码格式的Secret，用来存储密码、密钥等；但数据也通过base64 –decode解码得到原始数据，所有加密性很弱。 kubernetes.io/doc...
每天5分钟玩转Kubernetes | 查看Secret
最新发布
COCO_gsta的博客
06-24 795
书籍来源：cloudman《每天5分钟玩转Kubernetes》一边学习一边整理老师的课程内容及试验笔记，并与大家分享，侵权即删，谢谢支持！通过kubectl get secret查看存在的secret，如图所示。显示有两个数据条目，通过kubectl describe secret查看条目的Key，如图所示。如果还想查看Value，可以用kubectl edit secret mysecret，如图所示。然后通过base64将Value反编码，如图所示。......
kubectl 命令整理（持续更新中）
阿甘兄
05-11 2940
文章目录引言1. 查询命名空间2. 查询命名空间下的内容3. yaml操作3.1 yaml查询3.2 yaml编辑4. 进入容器查看 引言 简单了解常见的查询命令格式： kubectl get <resource> [-o wide | json | yaml] [-n namespace] 获取资源的相关信息，-n指定命令空间，-o指定输出格式 resource可以是具体资源名称，如pod nginx -xxx； 或者all (仅展示几种核心资源，并不完整) –all-namespaces
Kubernetes 中的 Secret加密存储
丰耳的博客
01-03 1171
为安全方便的将K8S的secret进行git版本，需要引入对secret进行加密的工具：Sealed-Secrets
Kubernetes 集群安全 - 机制说明.pdf
10-17
本系列文档介绍使用二进制部署 kubernetes 集群的所有步骤，而不是使用 kubeadm 等自动化方式来部署集群，同时开启了集群的TLS安全认证，该安装步骤适用于所有bare metal环境、on-premise环境和公有云环境。
3、Kubernetes 集群安全 - 鉴权1
08-04
3、Kubernetes 集群安全 - 鉴权1
2、Kubernetes 集群安全 - 认证1
08-04
HTTP Base 认证：通过 用户名+密码 的方式认证用户名+：+密码 用 BASE64 算法进行编码后的字符串放在 HTTP Request 中的 Heat
Kubernetes 里的 secret 最基本的用法
SAP 资深技术专家 Jerry Wang 的技术分享
11-19 1226
Secret解决了密码、token、密钥等敏感数据的配置问题，使用Secret可以避免把这些敏感数据以明文的形式暴露到镜像或者Pod Spec中。 Secret可以以Volume或者环境变量的方式使用。 使用如下命令行创建一个secret： kubectl create secret generic admin-access --from-file=./username.txt --from-fi...
kubernetes的Service Account和secret
热门推荐
柳清风的专栏
06-04 2万+
Service AccountService Account概念的引入是基于这样的使用场景：运行在pod里的进程需要调用Kubernetes API以及非Kubernetes API的其它服务。Service Account它并不是给kubernetes集群的用户使用的，而是给pod里面的进程使用的，它为pod提供必要的身份认证。kubectl get sa --all-namespacesNAME
查看 Secret【转】
weixin_30411239的博客
07-02 963
可以通过kubectl get secret查看存在的 secret。 显示有两个数据条目，kubectl describe secret查看条目的 Key： 如果还想查看 Value，可以用kubectl edit secret mysecret： 然后通过 base64 将 Value 反编码： 下节学习如何在 Pod 中使用 Secret。 转载于:https...
kubernetes Secret 使用方法，个人学习记录
北海牧野
06-17 462
kubernetes Secret Secret 有三种类型：Service Account(SA)Opaque SecretⅠ、创建说明Ⅱ、使用方法1、将定义好的 Secret 挂载到 Volume 数据卷中2、将 Secret 导出到环境变量中kubernetes.io/dockerconfigjson 私有仓库认证 ​ secret 解决了密码、token、密钥等敏感数据的配置问题，而不需要把这些敏感数据暴露到镜像或者 Pod Sepc 中。 Secret 可以以 Volume 或者环境变量的方式使用
kubectl常用
识途老码
12-10 3093
kubectl常用命令查看集群支持的所有API资源查看api接口版本查询对应功能调用的接口启动一个pod查看pod的ip地址创建一个deployment为tomcatdemo这个deployment创建一个services查看标签指定标签查询资源删除资源 查看集群支持的所有API资源 # 查看kubectl命令行字段的简写 kubectl api-resources ## 查看services的缩写 [root@master ~]# kubectl api-resources|grep services
Kubernetes secret使用详解
小楼一夜听春雨，深巷明朝卖杏花
11-18 1369
Secret 存在意义 K8s configmap可以注入pod之内成为环境变量或者是配置文件，这些都是以明文方式保存，如果碰到密码这种的以明文方式保存就不行了，Secret更加倾向于保存要加密的文件。 Secret 解决了密码、token、密钥等敏感数据的配置问题，而不需要把这些敏感数据暴露到镜像或者 Pod Spec中。Secret 可以以 Volume 或者环境变量的方式使用。密码这种可以先存储到secret里面，然后挂载到Pod里面即可。 Secret 有三种类型： Service Acc.
kubernetes secret私密凭据
qq_37377136的博客
10-17 1183
kubernetes Secret官方地址 一、简介 Secret 对象类型用来保存敏感信息，例如密码、OAuth 令牌和 SSH 密钥。 将这些信息放在 secret 中比放在 Pod 或者 容器镜像 中来说更加安全和灵活 Secret
容器编排技术 -- Kubernetes kubectl create secret 命令详解
YunWisdom
08-28 4014
容器编排技术 -- Kubernetes kubectl create secret 命令详解 1kubectl create secret 2语法 3参考： kubectl create secret 使用指定的子命令创建secret。 语法 $ secret 参考： create docker-registry 命令 create secret generic...
k8s通过secret管理敏感信息
weixin_30650039的博客
11-14 374
应用启动过程中可能需要一些敏感信息，比如访问数据库的用户名密码或者秘钥。将这些信息直接保存在容器镜像中显然不妥，Kubernetes 提供的解决方案是 Secret。 Secret 会以密文的方式存储数据，避免了直接在配置文件中保存敏感信息。Secret 会以 Volume 的形式被 mount 到 Pod，容器可通过文件的方式使用 Secret 中的敏感数据；此外，容器也可以环境变量的方...
k8s--pod配置管理（secret和configmap）
weixin_47153988的博客
10-15 1359
文章目录一：secret配置管理1.1 Secret机密1.2 创建secret1.2.1 方式一：基于文件创建secret1.2.2 基于参数创建secret1.3 pod使用secret1.3.1 方式一：使用secret中的变量导入到pod中1.3.2 方法二：使用挂载二：ConfigMap配置管理2.1 方法一：使用kubectl创建2.2 使用变量参数形式创建configmap资源 一：secret配置管理 1.1 Secret机密 Secret解决了密码、token、密钥等敏感数据的配置问题，将
创建自己的kubernetes集群
05-13
要创建自己的 Kubernetes 集群，您需要先选择一个云平台或者物理服务器。...以上是一些基本步骤，但是创建 Kubernetes 集群可能会涉及到更多的配置和安全措施。建议您参考 Kubernetes 官方文档并进行深入研究。

“相关推荐”对你有帮助么？

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值