摘要：kubernetes secret 未显示设定时，默认的配置就是opaque类型。

kubernetes secret 未显示设定时，默认的配置就是opaque类型。

service创建的时候，不指定的话，默认就是ClusterIP的服务类型。

编码生成密文：

echo -n "明文" |base64

解码恢复明文：

echo -n "密文"| base64 -d

这里的d代表decode，解码的意思。

Base64是一种编码方式，它会对数据进行编码，编码以后的结果放入secret资源清单的配置文件。

secret.yaml:

apiVersion: v1

kind: Secret

metadata:

name: mysecret

namespace: default

type: Opaque

data:

password: xxx(密文)

username: XXX（密文）

这里使用的密文value，是经过base64算法编码以后的密码，但是这里的key是没有经过编码的。

编码和解码的过程，是base64位算法通过编解码库进行的，多次执行会生成相同的编码或者解码的结果。

一个没有被编码的数据，拿去解码的话，由于数据库中没有数据，所以解码之后会出现乱码，去解码一定得到的不是原数据。

当已经编码过的数据，放入pod中被调用的话，它的value会被自动解码。

如果对value没有进行编码，就写入了secret资源对象的资源清单文件中，那么在使用的时候会自动解码，就会出现乱码。

secret对象的value值必须经过base64编码，才可以去使用。

一定要把secret资源对象中key的value值进行编码才能去使用。

通过secret资源清单文件secret.yaml去创建secret:

kubectl create -f secret.yaml

查看 kubernetes集群中的secret：

kubectl get secret -n $default

通过describe去描述secret资源对象：

kubectl describe secret mysecret -n default

可以查看到数据段data中的字段有多少个字节，但是不会看到编码后的密码。

可以对比configmap:

kubectl get cm $configmap_name -n $default

或者：

kubectl describe cm $configmap -n $default

可以看到configmap是明文显示的数据。

但是kubectl describe secret $secret_name -n $namespace_name的时候，它的key是明文的，但是它的value是经过编码的密文，它不会以明文的形式告诉用户编码值。它的key是明文的，但是value是一个隐藏的信息。

获取secret资源对象的value值，可以使用：

kubectl get secret mysecret -n default -o yaml

可以将secret资源对象输出为资源清单文件。

这样可以把拿到手的已经编码过的密文，经过解码得到原数据。

echo -n "密文" | base64 -d

通过base64算法的decode解码，得到原数据。这样就得到了需要的原数据或者说是数据本身。

所以这个secret资源对象编码之后的密文，是可以通过解码去恢复的，是可以获取到的。这个数据好像隐藏了，但是对于一个真正了解kubernetes集群特性的运维工程师来说，可以通过一条命令方案给还原回来。

不能把secret当成唯一的安全手段。

如果数据库密码要求没那么严格的，也是可以放在secret中，它相对于configmap来说更加安全一点，但是不能当作安全的唯一手段。

opaque类型的secret资源对象，可以做不同的内容。

桃红柳绿

鼓励的话语：人，只要不放弃努力，就一定可以东山再起！

来源：闪现哭唧唧