关于Secret对象
和ConfigMap对象用来保存明文格式的参数不同,Kubernetes 的 Secret 对象类型是用来保存敏感信息的,这些敏感信息包括:密码、登录凭证、OAuth 令牌和ssh key等。
在Secret中可以指定“type=Opaque”,这样secret就会使用通用结构保存key-value对,而不验证其结构的有效性。
Secret概述
Secret解决了密码、token、秘钥等敏感数据的配置问题,而不需要把这些敏感数据暴露到镜像或者Pod Spec中。Secret可以以Volume或者环境变量的方式使用。
用户可以创建 secret,同时系统也创建了一些 secret。
要使用 secret,pod 需要引用 secret。Pod 可以用两种方式使用 secret:作为 volume 中的文件被挂载到 pod 中的一个或者多个容器里,或者当 kubelet 为 pod 拉取镜像时使用。
Secret类型
- Service Account:用来访问Kubernetes API,由Kubernetes自动创建,并且会自动挂载到Pod的 /run/secrets/kubernetes.io/serviceaccount 目录中。
- Opaque:base64编码格式的Secret,用来存储密码、秘钥等。
- kubernetes.io/dockerconfigjson:用来存储私有docker registry的认证信息
web端管理secret
从web控制台管理secret:
1. 以授权用户身份登录到web控制台。
2. 创建或选择一个项目来承载secret。
3. 导航到resource——>secrets。
Secret使用场景
- password和user names
敏感信息(如password和user name)可以存储在一个secret中,该secret被挂载为容器中的数据卷。数据显示为位于容器的数据卷目录中的文件中的内容。然后,应用程序(如数据库)可以使用这些secret对用户进行身份验证。
- 传输层安全性(TLS)和密钥对
通过让集群将签名证书和密钥对生成到项目名称空间中的secret中,可以实现对服务的通信的保护。证书和密钥对使用PEM格式存储以类似tls.crt和tls.key的格式存储在secret的pod中。
KeyStore
KeyStore 和 TrustStore是JSSE中使用的两种文件。这两种文件都使用java的keytool来管理,他们的不同主要在于用途和相应用途决定的内容的不同。
这两种文件在一个SSL认证场景中,KeyStore用于服务器认证服务端,而TrustStore用于客户端认证服务器。
比如在客户端(服务请求方)对服务器(服务提供方)发起一次HTTPS请求时,服务器需要向客户端提供认证以便客户端确认这个服务器是否可信。这里,服务器向客户端提供的认证信息就是自身的证书和公钥,而这些信息,包括对应的私钥,服务器就是通过KeyStore来保存的。当服务器提供的证书和公钥到了客户端,客户端就要生成一个TrustStore文件保存这些来自服务器证书和公钥。
apache kafka可以使用SSL加密连接,还可以限制客户端访问, 给客户端发行证书,只允许持有证书的客户端访问。 下面使用jdk的keytool工具来生成证书,配置kafka。
apache kafka可以使用SSL加密连接,还可以限制客户端访问,
给客户端发行证书,只允许持有证书的客户端访问。
下面使用jdk的keytool工具来生成证书,配置kafka。
为了便于演示,ca和服务器证书使用相同的密码,如下:
KSPASS=xxxx
客户端证书密码如下:
CLIENT_PASS=yyyy
本文结合一个具体的实例给出如何在公有云环境上配置Kafka broker与client之间的SSL设置。
测试环境
- 阿里云机一台(Server端):主机名是kafka1,负责运行单节点的Kafka集群
- Mac笔记本一台(Client端):通过公网连接阿里云机器上的Kafka服务,给Kafka集群发送消息以及消费消息
......
Kafka is a distributed,partitioned,replicated commit logservice。它提供了类似于JMS的特性,但是在设计实现上完全不同,此外它并不是JMS规范的实现。kafka对消息保存时根据Topic进行归类,发送消息者成为Producer,消息接受者成为Consumer,此外kafka集群有多个kafka实例组成,每个实例(server)成为broker。无论是kafka集群,还是producer和consumer都依赖于zookeeper来保证系统可用性集群保存一些meta信息。