k8s的secret基本概念及案例
secret相对于configMap，功能上是相似的
但是secret是以其他编码方式去记录配置信息的，但是也可以被解读，只不过有技术门槛，不是那么容易就被解读。
使用base64可以解码：echo ** | base64 -d
**是kubectl describe secret secretName -o yaml中的值的编码
secret有三种类型：(查看：kubectl create secret --help)
docker-registry 一般保存docker-registry的认证信息
generic 通用的，一般保存一些密码数据
tls 一般保存私钥或证书
pod创建时若连接到私有仓库中需要认证，则要创建专用的secret （docker-registry）类型的
pod.spec.imagePullSecrets字段中需要指明secret的name
generic方式的secret，里面的键值虽说不是铭文，但是解码的技术手段要求不高。
对于密码类型的信息，最好用数据卷挂载方式来实现信息的注入，然后以文件形式挂载到挂载点，设置权限。
例：用数据卷方式，将mysql的密码注入到pod的容器中。
1.创建secret
kubectl create secret generic test --from-literal=MYSQL_ROOT_PASSWORD=smb@nds
2.创建pod
1 vim myapp-demo.yaml
2 apiVersion: apps/v1
3 kind: Deployment
4 metadata:
5 name: myapp-demo
6 namespace: default
7 spec:
8 replicas: 1
9 selector:
10 matchLabels:
11 app: myapp
12 template:
13 metadata:
14 labels:
15 app: myapp
16 spec:
17 containers:
18 - name: myapp
19 image: ikubernetes/myapp:v1
20 imagePullPolicy: IfNotPresent
21 ports:
22 - name: http
23 containerPort: 80
24 volumeMounts:
25 - name: mysql
26 mountPath: /test/
27 volumes:
28 - name: mysql
29 secret:
30 secretName: test
3.启动pod，查看信息是否注入
1 kubectl apply -f myapp-demo.yaml
2 kubectl exec -it myapp-demo-75f8f9bf9f-8nbdv -- /bin/sh
3 / # cat test/MYSQL_ROOT_PASSWORD
4 smb@nds/ #
可以看到，信息注入后是明文的，可以设置查看访问权限解决。
k8s中secret解析
概览
Secret是用来保存小片敏感数据的k8s资源，例如密码，token，或者秘钥。这类数据当然也可以存放在Pod或者镜像中，但是放在Secret中是为了更方便的控制如何使用数据，并减少暴露的风险。
用户可以创建自己的secret，系统也会有自己的secret。
Pod需要先引用才能使用某个secret，Pod有2种方式来使用secret：作为volume的一个域被一个或多个容器挂载；在拉取镜像的时候被kubelet引用。
內建的Secrets
由ServiceAccount创建的API证书附加的秘钥
k8s自动生成的用来访问apiserver的Secret，所有Pod会默认使用这个Secret与apiserver通信
创建自己的Secret
使用kubectl create secret命令创建Secret
假如mougePod要访问数据库，需要用户名密码，分别存放在2个文件中：username.txt，password.txt
# Create files needed for rest of example.
$ echo -n 'admin' > ./username.txt
$ echo -n '1f2d1e2e67df' > ./password.txt
kubectl create secret指令将用户名密码写到secret中，并在apiserver创建Secret
$ kubectl create secret generic db-user-pass --from-file=./username.txt --from-file=./password.txt
secret "db-user-pass" created
查看创建结果：
$ kubectl get secrets
NAME TYPE DATA AGE
db-user-pass Opaque 2 51s
$ kubectl describe secrets/db-user-pass
Name: db-user-pass
Namespace: default
Labels:
Annotations:
Type: Opaque
Data
====
password.txt: 12 bytes
username.txt: 5 bytes
get或describe指令都不会展示secret的实际内容，这是出于对数据的保护的考虑，如果想查看实际内容请继续往下看。
手动创建Secret
创建一个secret.yaml文件，内容用base64编码
$ echo -n 'admin' | base64
YWRtaW4=
$ echo -n '1f2d1e2e67df' | base64
MWYyZDFlMmU2N2Rm
yaml文件内容：
apiVersion: v1
kind: Secret
metadata:
name: mysecret
type: Opaque
data:
username: YWRtaW4=
password: MWYyZDFlMmU2N2Rm
创建：
$ kubectl create -f ./secret.yaml
secret "mysecret" created
解析Secret中内容
$ kubectl get secret mysecret -o yaml
apiVersion: v1
data:
username: YWRtaW4=
password: MWYyZDFlMmU2N2Rm
kind: Secret
metadata:
creationTimestamp: 2016-01-22T18:41:56Z
name: mysecret
namespace: default
resourceVersion: "164619"
selfLink: /api/v1/namespaces/default/secrets/mysecret
uid: cfee02d6-c137-11e5-8d73-42010af00002
type: Opaque
base64解码：
$ echo 'MWYyZDFlMmU2N2Rm' | base64 --decode
1f2d1e2e67df
……
限制
需要被挂载到Pod中的secret需要提前创建，否则会导致Pod创建失败
secret是有命名空间属性的，只有在相同namespace的Pod才能引用它
单个Secret容量限制的1Mb，这么做是为了防止创建超大的Secret导致apiserver或kubelet的内存耗尽。但是创建过多的小容量secret同样也会耗尽内存，这个问题在将来可能会有方案解决
kubelet只支持由API server创建出来的Pod中引用secret，使用特殊方式创建出来的Pod是不支持引用secret的，比如通过kubelet的--manifest-url参数创建的pod，或者--config参数创建的，或者REST API创建的。
通过secretKeyRef引用一个不存在你secret key会导致pod创建失败
Kubernetes中的Secret配置
通过案例学习 Secret - 每天5分钟玩转 Docker 容器技术（110）
在下面的例子中，我们会部署一个 WordPress 应用，WordPress 是流行的开源博客系统。
我们将创建一个 MySQL service，将密码保存到 secret 中。我们还会创建一个 WordPress service，它将使用 secret 连接 MySQL。这个例子将展示如何用 secret 避免在 image 中存放敏感信息，或者在命令行中直接传递敏感数据。
创建 secret 存放 MySQL 的管理员密码。
openssl rand -base64 20 | docker secret create mysql_root_password -
密码是由 openssl 生成的随机字符串。
注意 ag7injh6juonwl09lq8st36o8 是新创建的 service 的 ID，而非 service 的内容。
上面这种方式是从标准输入读取 secret 的内容，也可以指定从文件中读取，例如：
openssl rand -base64 20 > password.txt docker secret create my_password ./password.txt
一般情况下，应用不会直接用 root 密码访问 MySQL。我们会创建一个单独的用户 workpress，密码存放到 secret mysql_password中。
openssl rand -base64 20 | docker secret create mysql_password -
创建自定义的 overlay 网络
MySQL //代码效果参考：http://hnjlyzjd.com/hw/wz_24069.html
通过 overlay 网络 mysql_private 与 WordPress 通信，不需要将 MySQL service 暴露给外部网络和其他容器。docker network create -d overlay mysql_private
创建 MySQL service
命令如下：
docker service create \
--name mysql \
--network mysql_private \
--secret source=mysql_root_password,target=mysql_root_password \
--secret source=mysql_password,target=mysql_password \
-e MYSQL_ROOT_PASSWORD_FILE="/run/secrets/mysql_root_password" \
-e MYSQL_PASSWORD_FILE="/run/secrets/mysql_password" \
-e //代码效果参考：http://hnjlyzjd.com/xl/wz_24067.html
MYSQL_USER="wordpress" \-e MYSQL_DATABASE="wordpress" \
mysql:latest
MYSQL_DATABASE 指明创建数据库 wordpress。
MYSQL_USER 和 MYSQL_PASSWORD_FILE 指明创建数据库用户 workpress，密码从 secret mysql_password 中读取。
有关 mysql 镜像环境变量更详细的使用方法可参考
创建 WordPress service
MySQL service 已就绪，现在创建 WordPress service。命令如下：
docker service create \
--name wordpress \
--network mysql_private \
--publish 30000:80 \
--secret source=mysql_password,target=wp_db_password \
-e WORDPRESS_DB_HOST="mysql:3306" \
-e WORDPRESS_DB_NAME="wordpress" \
-e WORDPRESS_DB_USER="wordpress" \
-e WORDPRESS_DB_PASSWORD_FILE="/run/secrets/wp_db_password" \
wordpress:latest
WORDPRESS_DB_HOST 指明 MySQL service 地址 mysql:3306，这里用到了 DNS。
WORDPRESS_DB_NAME 指明 WordPress 的数据库为 wordpress，与前面 MYSQL_DATABASE 一致。
WORDPRESS_DB_USER 指明连接 WordPress 数据库的用户为 wordpress，与前面 MYSQL_USER 一致。
WORDPRESS_DB_PASSWORD_FILE 指明数据库的用户 wordpress 的密码，从 secret mysql_password 中获取。
有关 wordpress 镜像环境变量更详细的使用方法可参考
验证 WordPress
访问
能正常显示初始化界面，表明 WordPress 已经连接到 MySQL，部署成功。
Secret 就讨论到这里，下一节我们学习 Stack。
书籍：
1.《每天5分钟玩转Docker容器技术》
2.《每天5分钟玩转OpenStack》
kubernetes资源类型--secret和Service Account
secret
概念
secret对象类型主要目的是保存和处理敏感信息/私密数据，比如密码，OAuth tokens，ssh keys等信息。将这些信息放在secret对象中比 直接放在pod或docker image中更安全，也更方便使用。
一个已经创建好的secrets对象有两种方式被pod对象使用，其一，在container中的volume对象里以file的形式被使用，其二，在pull images时被kubelet使用。
类型
Opaque任意字符串，默认类型
kubernetes.io/service-account-token:作用于ServiceAccount
kubernetes.io/dockercfg:作用于Docker registry，用户下载docker镜像认证使用
Opaque
创建
文件
实现把需要加密的内容实现base64编码
echo -n lykops | base64
bHlrb3Bz
echo -n 1qaz2wsx | base64
MXFhejJ3c3g=
然后写入lykops-secret.yaml
apiVersion: v1
kind: Secret
metadata:
name: test-secret
namespace: default
type: Opaque
data:
password: MXFhejJ3c3g=
username: bHlrb3Bz
导入kubectl create -f lykops-secret.yaml
命令行
kubectl createsecret generic lykops --secret --from-literal=username=lykops--from-literal=password=1qaz2wsx
pod引用
cat [ EOF > lykops-secret.yaml
apiVersion: v1
kind: Pod
metadata:
name: lykops-secret-pod
labels:
software: apache
project: lykops
app: lykops-secret-pod
version: v1
spec:
containers:
-name: lykops-secret-pod
image: web:apache
command: 【'sh' , '/etc/run.sh'】
env:
- name: SECRET_USERNAME
valueFrom:
secretKeyRef:
name: lykops-secret
key: username
- name: SECRETPASSWORD
valueFrom:
secretKeyRef:
name: lykops-secret
key: password
EOF
kubectl create -f lykops-secret-pod.yaml
然后进入pod
kubectl exec -it lykops-secret-pod /bin/bash
执行env | grep -i '^SECRET'
SECRET_USERNAME=lykops
SECRET_PASSWORD=1qaz2wsx
imagePullSecrets
当在需要安全验证的环境中拉取镜像时，需要通过用户名和密码。
apiVersion: v1
kind: Secret
metadata:
name: myregistrykey
namespace: awesomeapps
data:
.dockerconfigjson:UmVhbGx5IHJlYWxseSByZWVlZWVlZWVlZWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWxsbGxsbGxsbGxsbGxsbGxsbGxsbGxsbGxsbGxsbGx5eXl5eXl5eXl5eXl5eXl5eXl5eSBsbGxsbGxsbGxsbGxsbG9vb29vb29vb29vb29vb29vb29vb29vb29vb25ubm5ubm5ubm5ubm5ubm5ubm5ubm5ubmdnZ2dnZ2dnZ2dnZ2dnZ2dnZ2cgYXV0aCBrZXlzCg==
type: kubernetes.io/dockerconfigjson
·或者直接通过命令创建
kubectl create secret docker-registrymyregistrykey --docker-server=DOCKER_REGISTRY_SERVER--docker-username=DOCKER_USER --docker-password=DOCKER_PASSWORD--docker-email=DOCKER_EMAIL
·接下来拉取镜像的时候，就可以使用了
apiVersion: v1
kind: Pod
metadata:
name: foo
namespace: awesomeapps
spec:
containers:
-name: foo
image: janedoe/awesomeapp:v1
imagePullSecrets:
-name: myregistrykey
·其实本质上还是kubelet把这个认证放到了docker的目录下面，如下：
Service Account
概念
Service Account（以下简称SA）的使用场景：运行在pod里的进程需要调用K8S API以及非K8S API的其它服务。SA
cat ~/.docker/config.json
{
"auths": {
"10.39.0.118": {
"auth": "Y2hlbm1vOmNtMTM4MTE2NjY3ODY="
},
"10.39.0.12:5000": {
"auth": "dXNlcjAxOjEyMzQ1YQ=="
},
"": {
"auth": "dXNlcjAxOjEyMzQ1YQ=="
}
}
}
并不是给K8S集群的用户使用的，而是给pod里面的进程使用的，它为pod提供必要的身份认证。
如果K8S开启了SA（位于/etc/kubernetes/controller-manager的KUBE_ADMISSION_CONTROL="--admission-control=NamespaceLifecycle,NamespaceExists,LimitRanger,SecurityContextDeny,ServiceAccount,ResourceQuota"），那么会在每个namespace下面都会创建一个默认的default的SA。
配置
当用户在namespace下创建pod时会默认使用sa。
……
volumes:
-name: default-token-rsf8r
secret:
defaultMode: 420
secretName:default-token-rsf8r
具体看一下secret
kubectl get secret default-token-rsf8r -oyaml
apiVersion: v1
data:
namespace: ZGVmYXVsdA==
token:ZXlKaGJHY2lPaUpTVXpJMU5pSXNJblI1Y0NJNklrcFhWQ0o5LmV5SnBjM01pT2lKcmRXSmxjbTVsZEdWekwzTmxjblpwWTJWaFkyTnZkVzUwSWl3aWEzVmlaWEp1WlhSbGN5NXBieTl6WlhKMmFXTmxZV05qYjNWdWRDOXVZVzFsYzNCaFkyVWlPaUprWldaaGRXeDBJaXdpYTNWaVpYSnVaWFJsY3k1cGJ5OXpaWEoyYVdObFlXTmpiM1Z1ZEM5elpXTnlaWFF1Ym1GdFpTSTZJbVJsWm1GMWJIUXRkRzlyWlc0dGNuTm1PSElpTENKcmRXSmxjbTVsZEdWekxtbHZMM05sY25acFkyVmhZMk52ZFc1MEwzTmxjblpwWTJVdFlXTmpiM1Z1ZEM1dVlXMWxJam9pWkdWbVlYVnNkQ0lzSW10MVltVnlibVYwWlhNdWFXOHZjMlZ5ZG1salpXRmpZMjkxYm5RdmMyVnlkbWxqWlMxaFkyTnZkVzUwTG5WcFpDSTZJakJrWlRJek5UYzFMVEptTURJdE1URmxOeTA1T0dRd0xUVXlOVFJqTkRZeU9HRmtPU0lzSW5OMVlpSTZJbk41YzNSbGJUcHpaWEoyYVdObFlXTmpiM1Z1ZERwa1pXWmhkV3gwT21SbFptRjFiSFFpZlEuSmxuamM0Y0xNYkZrRlJVQjIyWGtFN2t4bTJ1dS1aQm9sUTh4VEdDNmdLOTdSZTVOMzBuY2V0SWJsanVOVWFlaDhtMDk2R19nMHE3cmRvWm5XMTV2OFBVXzNyM1hWWlBNc1lxbGRpZlNJbWtReXFqeEphVlBka3Izam5GWVBkVWNaTmk3MFF3cWtEdm5sMXB4SFRNZTZkTVNPTlExbUVoMHZSbHBhRTdjVWtTVlg5blRzaFVJVTVXWE9wRUxwdTVjVjBHV3ZGeDRDSzR6Umt3clNMdlV5X2d5UGZwLWdYVFZQWU80NkJKSWZtaVhlZGhVaW9nempPN285eGxDbUxQVkhyNkFIZGViNExiTVA1dkJ2MlBSZ2RrMW9keTR0VEdxLVRGU3M2VkNoMTZ4dk5IdTRtRVN5TjZmcXVObzJwYUFOelY4b251aTJuaU4yNTU1TzN4SFdR
kind: Secret
metadata:
annotations:
kubernetes.io/service-account.name: default
kubernetes.io/service-account.uid: 0de23575-2f02-11e7-98d0-5254c4628ad9
name: default-token-rsf8r
namespace: default
resourceVersion: "12551"
selfLink: /api/v1/namespaces/default/secrets/default-token-rsf8r
uid:75c0a236-2f02-11e7-98d0-5254c4628ad9
type: kubernetes.io/service-account-token
上面的内容是经过base64加密过后的，直接进入容器内：
ls -l /var/run/secrets/kubernetes.io/serviceaccount/
total 0
lrwxrwxrwx 1 root root 13 May 4 23:57 ca.crt -> ..data/ca.crt
lrwxrwxrwx 1 root root 16 May 4 23:57 namespace -> ..data/namespace
lrwxrwxrwx 1 root root 12 May 4 23:57 token -> ..data/token
可以看到已将ca.crt 、namespace和token放到容器内了，那么这个容器就可以通过https的请求访问apiserver了。
Kubernetes里的secret最基本的用法
Secret解决了密码、token、密钥等敏感数据的配置问题，使用Secret可以避免把这些敏感数据以明文的形式暴露到镜像或者Pod Spec中。
Secret可以以Volume或者环境变量的方式使用。
使用如下命令行创建一个secret：
kubectl create secret generic admin-access --from-file=./username.txt --from-file=./password.txt
输入文件username.txt和password.txt需要手动创建，里面分别维护用于测试的用户名和密码。
创建成功后，发现secret的类型为Opaque：
实际上，Kubernetes的secret有三种类型：
1. Service Account：用来访问Kubernetes API，由Kubernetes自动创建，并且会自动挂载到Pod的 /run/secrets/kubernetes.io/serviceaccount 目录中；
2. Opaque：base64编码格式的Secret，用来存储密码、密钥等；
3. kubernetes.io/dockerconfigjson ：用来存储私有docker registry的认证信息。
而我们刚刚创建的secret的类型为Opaque，因此在kubectl get secrets的返回结果里，能看到password和username的值均为base64编码：
要在pod里消费这个secret也很容易，看一个例子：
apiVersion: v1
kind: Pod
metadata:
name: secret-pod
spec:
restartPolicy: Never
volumes:
- name: credentials
secret:
secretName: admin-access
defaultMode: 0440
containers:
- name: secret-container
image: alpine:3.8
command: 【 "/bin/sh", "-c", "cat /etc/foo/username.txt /etc/foo/password.txt" 】
volumeMounts:
- name: credentials
mountPath: "/etc/foo"
readOnly: true
创建pod，自动执行，通过log命令查看pod的日志：
发现/bin/sh命令被执行了，pod mount的目录/etc/foo下的username.txt和password.txt通过cat命令显示了输出：
kubernetes系列12—二个特色的存储卷configmap和secret
1、configmap
1.1 认识configmap
ConfigMap用于保存配置数据的键值对，可以用来保存单个属性，也可以用来保存配置文件。ConfigMap跟secret很类似，但它可以更方便地处理不包含敏感信息的字符串。
1.2 创建configmap
1.2.1 通过命令行
创建一个名为nginx-config的configmap，指定端口和server name
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
【root@master ~】# kubectl create configmap nginx-config --from-literal=nginx_port=80 --from-literal=server_name=myapp.along.com
configmap/nginx-config created
【root@master ~】# kubectl get cm
NAME DATA AGE
nginx-config 2 11s
【root@master ~】# kubectl describe cm nginx-config
Name: nginx-config
Namespace: default
Labels:
Annotations:
Data
<div class="line number13 index12 alt
