Kubernetes Secret
Secret介绍
参考文档
Secret的主要作用是保管私密数据,比如密码,OAuth Tokens,SSH Key等信息。这些私密信息放在Secret对象中比直接放在Pod或Docker Image中更加安全,也更方便管理。
Secret一旦被创建,则可以通过以下三种方式来使用:
- 在创建Pod时,通过为pod指定Service Account来自动使用该Secret,主要用于API Server鉴权的过程
- 通过挂载Secret到Pod来使用它
- Docker镜像下载时使用,通过指定Pod的spc.ImagePullSecret来引用。一般用于私有仓库登录拉取镜像
Kubernetes会自动创建包含用于访问API的凭据的Secret,并自动修改您的pod以使用此类Secret。这是Kubernetes 默认的行为,我们也可以通过自定义的方式禁用或者创建我们所需要的Secret。
自定义Secret
使用命令创建账号密码形式的Secrets
如果在集群中,pod需要访问数据库,那么我们可以使用文件的方式定义一个Secret,在本地主机上创建一个./username.txt和./password.txt的文件:
# echo "admin" > ./username.txt
# echo "123456" > ./password.txt
# kubectl create secret generic db-user-pass --from-file=./username.txt --from-file=./password.txt
查看Secret信息:
# kubectl get secret/db-user-pass -o wide
NAME TYPE DATA AGE
db-user-pass Opaque 2 1m# kubectl describe secrets/db-user-pass
Name: db-user-pass
Namespace: default
Labels: <none>
Annotations: <none>Type: OpaqueData
====
password.txt: 7 bytes
username.txt: 6 bytes
这里并不会显示文件中的具体信息。
使用YAML文件创建Secret
使用YMAL创建Secert时,每个账号密码的项目必须是转换为base64的编码。
[root@node-1 secret]# echo -n 'admin' | base64
YWRtaW4=
[root@node-1 secret]# echo -n '123456' | base64 # 不能有空格或换行符,或使用 base64 | tr -d '\n'
MTIzNDU2
创建YAML文件:
apiVersion: v1
kind: Secret
metadata:name: mysecret
type: Opaque
data:username: YWRtaW4= # 账号密码使用base64的编码方式password: MTIzNDU2
查看具体信息:
[root@node-1 secret]# kubectl get secret mysecret -o yaml
apiVersion: v1
data:password: MTIzNDU2username: YWRtaW4=
kind: Secret
metadata:creationTimestamp: 2018-07-18T09:02:20Zname: mysecretnamespace: defaultresourceVersion: "898655"selfLink: /api/v1/namespaces/default/secrets/mysecretuid: 47369a09-8a69-11e8-9c5f-000c295f81fb
type: Opaque
如果要查看密码,可以对编码解密:
# echo 'YWRtaW4=' | base64 --decode
admin# echo 'MTIzNDU2' | base64 -d
123456
Secret的使用
当创建好一个Secret后,可以通过多种方式使用Secret,一般有如下场景:
- 在创建Pod时,通过Pod指定Service Account来自动使用该Secret
- 通过挂载该Secret到Pod来使用。
- 在私有仓库下载Docker镜像时,可以指定Pod的参数 spec.ImagePullSecrets来引用。
通过挂载到Pod的方式引用
通过如下步骤:
- 创建一个Secret,也可以使用现有的Secret,多个Pod可以使用同一个Secret
- 定义Pod时,添加参数.spec.volumes[],可以自定义卷名,在.spec.volumes[].secret.secretName参数中指定Secret对象名。
- 给每一个需要使用到此Secret的容器添加参数.spec.containers[].volumeMounts[],指定.spec.containers[].volumeMounts[].readOnly = true 和 .spec.containers[].volumeMounts[].mountPath参数来存放Secret到未使用的空目录中。
- 修改镜像或者通过目录的方式,使程序能够通过使用目录路径的方式找到Secret,每个存放在Secret中的key值,都会以文件的形式挂载到挂载目录中。
这里给出一个示例:
apiVersion: v1
kind: Pod
metadata:name: mypod
spec:containers:- name: mypodimage: redisvolumeMounts:- name: foomountPath: "/etc/foo"readOnly: truevolumes:- name: foosecret:secretName: mysecret
在使用Secret时,需要注意以下几点:
- 需要使用的Secret都需要通过spec.volumes参数指定。
- 如果在一个Pod中有多个容器,那么每个容器都需要指定一个volumeMounts的挂载目录,但是spec.volumes 值需要指定一个即可。
- 你可以根据自己的需要将多个文件存放在一个Secret,也可以使用多个Secret。
我们也可以控制Secret的key文件在挂载卷中的映射路径,可以使用.spec.volumes[].secret.items来指定key的路径:
apiVersion: v1
kind: Pod
metadata:name: mypod
spec:containers:- name: mypodimage: redisvolumeMounts:- name: foomountPath: "/etc/foo"readOnly: truevolumes:- name: foosecret:secretName: mysecretitems: # 这里为usrname的key指定了一个单独的路径 /etc/foo/my-group/my-username- key: username path: my-group/my-username # password 将使用默认的/etc/foo/password
如果使用.spec.volumes[].secret.items参数,那么只有在items中被指定的key才能被投射到指定的目录。要使用Secret中的所有key,所有key都必须列在items字段中。 所有列出的key必须存在于相应的Secret中。 否则,不会创建volume。
Secret 文件的权限设置
我们可以设置Secret的文件的权限,默认情况下文件的权限是0644. 我们可以根据需要,指定整个挂载目录的权限来覆盖单个Key文件的权限:
apiVersion: v1
kind: Pod
metadata:name: mypod
spec:containers:- name: mypodimage: redisvolumeMounts:- name: foomountPath: "/etc/foo"volumes:- name: foosecret:secretName: mysecretdefaultMode: 256 # 这里是使用十进制表示的,转换为8进制为0400
这样在指定的挂载卷下,所有被Secret创建的文件都有400的权限。需要注意的是,JSON参数不支持八进制的表示方式,所以使用十进制的256方式来表示400权限。但是在使用YAML格式的文件定义Pod时可以正常使用八进制的表示方式。
同理,也可以指定key的路径,并分配权限:
apiVersion: v1
kind: Pod
metadata:name: mypod
spec:containers:- name: mypodimage: redisvolumeMounts:- name: foomountPath: "/etc/foo"volumes:- name: foosecret:secretName: mysecretitems:- key: usernamepath: my-group/my-usernamemode: 511 #这里表示0777的权限。
在安装Secret卷的容器内,keys显示为文件,key值基于64进行解码并存储在这些文件中。 但是在这些文件中是以明文方式存储的,容器中的程序负责从文件中读取秘密。
即使已经被挂载到卷中使用的Secret,也依然会随着Secret的更新而自动更新。 Kubelet将会在每个同步周期内检测当前被挂载的Secret是否是最新的。
容器中使用subPath volume 方式挂载的Secret将不会被更新。
以环境变量的方式使用Secret
使用环境变量的方式有如下特性:
- 可以创建一个新的Secret,也可以使用现有的,多个Pod可以共用一个Secret。
- 在定义Pod时,修改需要引用Secret的Container的配置参数,添加Secret,在env[].valueFrom.secretKeyRef参数中指定Secret的Key。
- 修改镜像或使用命令行模式,使应用能通过环境变量找到Secret的key.
如下示例:
apiVersion: v1
kind: Pod
metadata:name: secret-env-pod
spec:containers:- name: mycontainerimage: redisenv:- name: SECRET_USERNAMEvalueFrom:secretKeyRef:name: mysecretkey: username- name: SECRET_PASSWORDvalueFrom:secretKeyRef:name: mysecretkey: passwordrestartPolicy: Never
在此示例中,Secret会以环境变量的方式加载到容器中:
$ echo $SECRET_USERNAME
admin
$ echo $SECRET_PASSWORD
123456
拉取镜像时使用imagePullSecrets
在设置的私有仓库中拉取镜像时,我们可以使用imagePullSecrets来作为仓库的登录密码。
可以通过两种方式来使用imagePullSecrets:
- 手动指定imnagePullSecrets
- 自动添加imagePullSecrets
在Pod中指定一个ImagePullSecret
使用命令行创建一个ImagePullSecret, 将大写的部分改为具体的参数:
kubectl create secret docker-registry myregistrykey --docker-server=DOCKER_REGISTRY_SERVER --docker-username=DOCKER_USER --docker-password=DOCKER_PASSWORD --docker-email=DOCKER_EMAIL
secret "myregistrykey" created.
如果需要访问多个私有仓库,可以为每个仓库创建一个Secret, 当拉取镜像时,Kubelet会合并所有的imagePullSecrets到一个虚拟的.docker/config.json文件中。
Pods拉取镜像只能在自己的命名空间中识别Secrets,所以在有多个namespaces的情况下,需要给每namespace都执行相同的操作。
还可以使用yaml或json文件的方式来创建ImagePullSecret。不过需要注意以下三点:
- 在data选项中设置.dockerconfigjson的名称
- 将docker认证文件以base64编码方式编码,所得的结果配置在data[".dockerconfigjson"] 参数中。
- 设置类型为kubernetes.io/dockerconfigjson
通过如下步骤配置:
- 使用命令行登录私有docker Registry
# docker login localhost:5000
登录成功之后,会创建一个.docker/config.json的文件,此文件包含了登录的账号密码信息:
# cat .docker/config.json
{"auths": {"localhost:5000": {"auth": "dGVzdDp0ZXN0MTIzCg==" # 使用base64方式编码的账号密码}},"HttpHeaders": {"User-Agent": "Docker-Client/17.09.1-ce (linux)"}
}
- 将此文件内容转换为base64编码:
# cat /root/.docker/config.json | base64 ewoJImF1dGhzIjogewoJCSJsb2NhbGhvc3Q6NTAwMCI6IHsKCQkJImF1dGgiOiAiZEdWemREcDBa WE4wTVRJekNnPT0iICAjIOS9v+eUqGJhc2U2NOaWueW8j+e8lueggeeahOi0puWPt+WvhueggQoJ CX0KCX0sCgkiSHR0cEhlYWRlcnMiOiB7CgkJIlVzZXItQWdlbnQiOiAiRG9ja2VyLUNsaWVudC8x Ny4wOS4xLWNlIChsaW51eCkiCgl9Cn0K
- 创建YAML,将输出的结果配置到data[".dockerconfigjson"]参数中:
apiVersion: v1 kind: Secret metadata: name: myregistrykey namespace: awesomeapps data: .dockerconfigjson: ewoJImF1dGhzIjogewoJCSJsb2NhbGhvc3Q6NTAwMCI6IHsKCQkJImF1dGgiOiAiZEdWemREcDBa WE4wTVRJekNnPT0iICAjIOS9v+eUqGJhc2U2NOaWueW8j+e8lueggeeahOi0puWPt+WvhueggQoJ CX0KCX0sCgkiSHR0cEhlYWRlcnMiOiB7CgkJIlVzZXItQWdlbnQiOiAiRG9ja2VyLUNsaWVudC8x Ny4wOS4xLWNlIChsaW51eCkiCgl9Cn0K type: kubernetes.io/dockerconfigjson
提示:
- 在执行过程中遇到报错信息:"no objects passed to create" ,说明base64编码的字符无效
- 如果遇到类似"Secret "myregistrykey" is invalid: data[.dockerconfigjson]: invalid value ...的报错,说明数据已成功取消base64编码,但无法解析为.docker/config.json文件
- 创建Pod时,添加Secret:
apiVersion: v1
kind: Pod
metadata:name: foonamespace: awesomeapps
spec:containers:- name: fooimage: janedoe/awesomeapp:v1imagePullSecrets:- name: myregistrykey
添加ImagePullSecrets到 Service account (Pod 自动添加ImagePullSecrets)
- 创建了上述的ImagePullSecrets后,执行如下命令:
# kubectl get secrets myregistrykey
NAME TYPE DATA AGE
myregistrykey kubernetes.io/.dockerconfigjson 1 1d# kubectl patch serviceaccount default -p '{\"imagePullSecrets\": [{\"name\": \"myregistrykey\"}]}'
在默认的Service account的命名空间中使用这个Secret,并将它作为ImagePullSecret。
- 导出default得 Serviceaccount文件:
kubectl get serviceaccounts default -o yaml > ./sa.yaml
- 编辑此文件,删除"resourceVersion"所在的行,添加 "imagePullSecrets:"参数:
$ cat sa.yaml
apiVersion: v1
kind: ServiceAccount
metadata:creationTimestamp: 2015-08-07T22:02:39Zname: defaultnamespace: defaultselfLink: /api/v1/namespaces/default/serviceaccounts/defaultuid: 052fb0f4-3d50-11e5-b066-42010af0d7b6
secrets:
- name: default-token-uudge
imagePullSecrets:
- name: myregistrykey
4.重新生成 ServiceAccount:
$ kubectl replace serviceaccount default -f ./sa.yaml
serviceaccounts/default
经过这样的配置之后,在当前namespaces中新创建的Pod都会自动添加如下参数:
spec:imagePullSecrets:- name: myregistrykey
Secret的限制
使用Secret的注意事项
- Secret以mount的方式载到Container时,将会验证所指向的Secret是否存在,如果Secret不存在,除非标明这个Secret是可选的参数,否则Pod中的Container将不会被启动,所以Secret必须在Pod创建之前被创建。
- Secret API对象存在于一个namespaces中,它只能被同一个namespaces的Pods使用。
- 每个单独的Secret大小都不能超过1MB,Kubernetes不鼓励创建大尺寸的Secret,因为这样将会占用API Server和kubelet的大量内存。当然创建过多的小的Secret也会占用大量内存,这个需要根据场景进行合理的规划。
- Secret只能应用于通过API Server创建的Pods,这包括使用
kubectl
命令创建的Pods和通过RC直接创建的Pods。不包含使用kubelet--manifest-url
参数,--config
参数创建的Pod,使用REST API直接创建的也无法使用。 - 通过secretKeyRef引用已命名的Secret中不存在的key将阻止pod启动。
- 用于通过envFrom填充环境变量的密钥将具有可以被忽略的key,这些key可以被视为无效的环境变量时, 该pod将被允许启动。 此时,kubernetes将会生成一个事件,其原因是InvalidVariableNames,该消息将包含跳过的无效键列表,可以通过如下命令查看:
$ kubectl get events LASTSEEN FIRSTSEEN COUNT NAME KIND SUBOBJECT TYPE REASON 0s 0s 1 dapi-test-pod Pod Warning InvalidEnvironmentVariableNames kubelet, 127.0.0.1 Keys [1badkey, 2alsobad] from the EnvFrom secret default/mysecret were skipped since they are considered invalid environment variable names.
Secret的加载过程
通过API Server创建pod时,API Sserver不会检查是否存在可以引用的Secret。 一旦pod被调度,kubelet将尝试获取Secret值。 如果由于该Secret不存在或由于暂时缺少与API服务器的连接而无法获取该Secret,则kubelet将定期重试。 它将报告有关pod的事件,说明它尚未启动的原因。 获取Secret后,kubelet将创建并安装包含它的卷。 在安装所有pod的卷之前,pod的容器都不会启动。
在Kubelet启动Pod中的Container后,Container中和Secret相关的Volume将不会被改变,即使Secret本身被修改了。
如果要使用更新后的Secret,必须删除旧的Pod,并重新创建一个新的Pod.
Secret的应用示例
Pod中使用SSH Key
创建一个包含SSH Key的Secret:
kubectl create secret generic ssh-key-secret --from-file=ssh-privatekey=/path/to/.ssh/id_rsa --from-file=ssh-publickey=/path/to/.ssh/id_rsa.pub
提示:在发送自己的ssh密钥之前要仔细考虑:群集的其他用户可以访问该Secret。 使用您希望与您共享Kubernetes群集的所有用户都可以访问的Service Account,如果他们被泄露,可以撤销此Secret.
创建一个Pod,使用此Secret:
kind: Pod
apiVersion: v1
metadata:name: secret-test-podlabels:name: secret-test
spec:volumes:- name: secret-volumesecret:secretName: ssh-key-secretcontainers:- name: ssh-test-containerimage: mySshImagevolumeMounts:- name: secret-volumereadOnly: truemountPath: "/etc/secret-volume"
当容器的命令运行时,指定的key将会在如下目录被使用:
/etc/secret-volume/ssh-publickey
/etc/secret-volume/ssh-privatekey
然后容器可以自由地使用Secret数据来建立ssh连接。
为Pod加载生产/测试 认证信息
在不同环境中,可以指定不同的Secret,比如生产和测试Secret的进行区分。
首先,创建生产,测试两个不同的Secret:
$ kubectl create secret generic prod-db-secret --from-literal=username=produser --from-literal=password=Y4nys7f11
secret "prod-db-secret" created
$ kubectl create secret generic test-db-secret --from-literal=username=testuser --from-literal=password=iluvtests
secret "test-db-secret" created
注意:特殊字符如 '$', '*', '!'需要转义。如果密码中包含特殊字符,需要使用 \ 来进行转义,如,使用密码为:S!B*d$zDsb ,那需要执行如下命令:
kubectl create secret generic dev-db-secret --from-literal=username=devuser --from-literal=password=S\\!B\\\*d\\$zDsb
如果是以指定文件的方式,使用‘--from-file’的方式,就不需要转义。
创建Pod:
apiVersion: v1
kind: List
items:
- kind: PodapiVersion: v1metadata:name: prod-db-client-podlabels:name: prod-db-clientspec:volumes:- name: secret-volumesecret:secretName: prod-db-secretcontainers:- name: db-client-containerimage: myClientImagevolumeMounts:- name: secret-volumereadOnly: truemountPath: "/etc/secret-volume"
- kind: PodapiVersion: v1metadata:name: test-db-client-podlabels:name: test-db-clientspec:volumes:- name: secret-volumesecret:secretName: test-db-secretcontainers:- name: db-client-containerimage: myClientImagevolumeMounts:- name: secret-volumereadOnly: truemountPath: "/etc/secret-volume"
两个Container中都会文件系统中找到如下文件,其中包含不同容器环境的值:
/etc/secret-volume/username
/etc/secret-volume/password
请注意两个pod的规格如何仅在一个字段中有所不同; 这有助于从常见的pod配置模板创建具有不同功能的pod。
您可以使用两个服务帐户进一步简化基本容器规范:一个称为prod-user,使用prod-db-secret,另一个称为test-user,带有test-db-secret。 然后,pod规范可以缩短为,例如:
kind: Pod
apiVersion: v1
metadata:name: prod-db-client-podlabels:name: prod-db-client
spec:serviceAccount: prod-db-clientcontainers:- name: db-client-containerimage: myClientImage
在Secret volume中隐藏密钥文件
如果想在Pod中使用.filename的方式隐藏密钥文件,可以使用如下的定义方式:
kind: Secret
apiVersion: v1
metadata:name: dotfile-secret
data:.secret-file: dmFsdWUtMg0KDQo=
---
kind: Pod
apiVersion: v1
metadata:name: secret-dotfiles-pod
spec:volumes:- name: secret-volumesecret:secretName: dotfile-secretcontainers:- name: dotfile-test-containerimage: k8s.gcr.io/busyboxcommand:- ls- "-l"- "/etc/secret-volume"volumeMounts:- name: secret-volumereadOnly: truemountPath: "/etc/secret-volume"
secret-volume中将会包换一个单独的文件 .secret-file , 在dotfile-test-container容器中将会在如下路径存放此文件:
/etc/secret-volume/.secret-file
使Secret只在一个容器中可见
考虑到应用程序需要回应HTTP请求,处理一些复杂的业务逻辑,使用HMAC签名的方式加密消息。由于应用逻辑的复杂性,在服务器中可能存在未被注意的远程文件读取漏洞,这可能会将私钥暴露给×××者。
这可以分为两个容器中的两个进程:一个前端容器,它处理用户交互和业务逻辑,但是看不到私钥; 和一个可以看到私钥的签名者容器,并响应来自前端的简单签名请求(例如,通过localhost网络)
使用这种分区方法,×××者现在必须欺骗应用程序服务器做一些相当随意的事情,这可能比让它读取文件更困难。
最佳实践
当部署与Secret API进行交互的应用时,应使用如RBAC等认证策略加以限制。
Secret通常具有跨越一系列重要性的价值,其中许多可能导致Kubernetes集群发生更改。
由于这些原因,使用wathc和list在namespace中操作Secret是非常高的的权限,我们应该尽量避免普通用户有此权限。应该仅为最高特权的系统级组件保留查看和列出群集中所有Secret的功能。
需要访问Secret API的应用程序应该根据需要执行get请求。 这使管理员可以限制对所有Secret 的访问,同时白名单列出对应用所需的各个实例的访问权限。
为了提高循环get的性能,客户端可以设计引用Secret的资源,然后使用watch此资源,在引用更改时重新请求Secret。此外,还提出了一种允许客户端watch单个资源的“bulk watch ”API,并且可能会在未来的Kubernetes版本中提供。
安全策略
保护
由于可以独立于使用它们的pod创建Secret对象,因此在创建,查看和编辑pod的工作流程中泄露Secret的风险较小。系统还可以对Secret对象采取额外的保护措施,例如尽可能避免将其写入磁盘。
如果该节点上的pod需要使用Secret,则仅将Secret发送到此节点,并且Secret不会被写入磁盘。它存储在tmpfs中。一旦删除依赖它的pod,它就会被删除。
在大多数Kubernetes项目维护的发行版中,用户与apiserver之间的通信以及从apiserver到kubelet的通信受SSL / TLS保护。通过这些通道传输时,有效保护了Secret。
节点上的Secret数据存储在tmpfs卷中,因此不会停留在节点上。
在同一节点上可能存在几个pod的Secret。但是,只有pod请求的Secret可能在其容器中可见。因此,一个Pod无法访问另一个pod的Secret。
Pod中可能有几个容器。但是,pod中的每个容器都必须在其volumeMounts中请求Secret卷,以使其在容器中可见。这可用于在Pod级别构建有用的安全分区。
风险
- 在API服务器中,Secret数据以明文形式存储在etcd中;因此:
- 管理员应限制对管理员用户的etcd访问权限
- API服务器中的Secret数据在etcd使用的磁盘上处于静止状态;管理员可能想要在不再使用时擦除/粉碎etcd使用的磁盘
- 如果通过JSON或YAML文件配置Secret,该文件的Secret数据编码为base64,共享此文件或将其签入到源存储库意味着该密钥已被泄露。 Base64编码不是加密方法,被认为与纯文本相同。
- 应用程序仍然需要在从卷读取后保护Secret值,例如不会意外地将其记录或传输给不受信任的一方。
- 可以创建使用Secret的用户也可以看到该Secret的值。即使apiserver策略不允许该用户读取Secret对象,用户也可以运行暴露Secret的pod。
- 如果运行了etcd的多个副本,则它们之间将共享Secret。默认情况下,etcd不保护与SSL / TLS的对等通信,但可以配置。
- 目前,任何在任何节点上具有root权限的人都可以通过kubelet从apiserver中读取任何Secret。计划的功能是仅向实际需要它们的节点发送Secret,以限制根漏洞对单个节点的影响。
提示:从1.7版本开始,已经支持在REST中对Secret数据加密。参考文档
转载于:https://blog.51cto.com/tryingstuff/2147789
Kubernetes Secret相关推荐
- kubernetes secret私密凭据
kubernetes Secret官方地址 案例 包含 SSH 密钥的 Pod Secret 卷中以点号开头的文件(隐藏文件) 一.简介 Secret 对象类型用来保存敏感信息,例如密码.OAuth ...
- Kubernetes secret使用详解
Secret 存在意义 K8s configmap可以注入pod之内成为环境变量或者是配置文件,这些都是以明文方式保存,如果碰到密码这种的以明文方式保存就不行了,Secret更加倾向于保存要加密的文件 ...
- Kubernetes Secret的应用
Secret的概述 Secret翻译过来的意思是秘密.保密等意思.Secret主要存储k8s集群中比较敏感的一些文件,通过一些特殊的加密方式将这一些文件进行加密操作,Pod通过volume以及环境变量 ...
- Kubernetes Secret简介
Secret概述 前面文章中学习ConfigMap的时候,我们说ConfigMap这个资源对象是Kubernetes当中非常重要的一个对象,一般情况下ConfigMap是用来存储一些非安全的配置信息, ...
- kubernetes—ConfigMap 与 Secret
目录 一.ConfigMap(配置地图)介绍 1.开发中的困难 2.ConfigMap 的功能 3. 创建ConfigMap - 从目录创建 4.查看ConfigMap 5.创建ConfigMap - ...
- 使用Ceph集群作为Kubernetes的动态分配持久化存储
2019独角兽企业重金招聘Python工程师标准>>> 使用Docker快速部署Ceph集群 , 然后使用这个Ceph集群作为Kubernetes的动态分配持久化存储. Kubern ...
- DApp基础设施设计:借助Kubernetes、Docker和Parity实现可靠的以太坊事件跟踪
本文最初发表于Hacker Noon博客,经原作者Carlo Las Marias授权由InfoQ中文站翻译分享. 学习Solidity并编写智能合约相对来讲是比较容易的,但是我们发现更加困难的技术挑 ...
- Kubernetes - - k8s - v1.12.3 动态存储管理GlusterFS及使用Heketi扩容GlusterFS集群
1,准备工作 1.1 所有节点安装GFS客户端 yum install glusterfs glusterfs-fuse -y 1.2 如果不是所有节点要部署GFS管理服务,就在需要部署的节点上打上标 ...
- 配置kubernetes服务basic auth
由于一些内部服务访问并不需要鉴权,如kubernetes-dashboard.traefik-ui,所以当我们想通过外网域名访问的时候会有安全问题.这里我们可以为服务配置basic auth,访问时需 ...
最新文章
- hbase scan超时设置_如何在优化生产环境的hbase
- mysql与ms sql server_MS SQL Server和MySQL区别
- session过期跳转到登陆页面并跳出iframe框架的最简单方法
- 中小企业私有云解决方案浅谈
- 用canvas整个打飞机游戏
- tf.data.TextLineDataset()
- 没有bug队——加贝——Python 练习实例 29,30
- pptx模块的图片框
- Netty从入门到精通-伪异步I/O编程
- 机器学习中的范数规则化之L0、L1、L2范数
- 禁用win10触摸屏手势_怎样禁用、启用Win10平板边缘滑动手势
- Python札记6_字典1
- Origin画图技巧之设置框图默认设置
- 树莓派4b 4G 64位系统下安装opencv
- uniapp中字体加粗问题
- 项目经理应该如何提高团队执行力
- head first java勘误_Head First Java勘误
- WIFI------------QOS 理解:
- win10 VSCODE卡死的问题
- 笔记:对余额宝等货币基金的理解