Kubernetes Secret

Secret介绍

参考文档

Secret的主要作用是保管私密数据，比如密码，OAuth Tokens,SSH Key等信息。这些私密信息放在Secret对象中比直接放在Pod或Docker Image中更加安全，也更方便管理。

Secret一旦被创建，则可以通过以下三种方式来使用：

  1. 在创建Pod时，通过为pod指定Service Account来自动使用该Secret，主要用于API Server鉴权的过程
  2. 通过挂载Secret到Pod来使用它
  3. 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:  Opaque

Data
====
password.txt:  7 bytes
username.txt:  6 bytes

这里并不会显示文件中的具体信息。

使用YAML文件创建Secret

使用YMAL创建Secert时，每个账号密码的项目必须是转换为base64的编码。

[[email protected] secret]# echo -n ‘admin‘ | base64
YWRtaW4=
[[email protected] 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

查看具体信息：

[[email protected] secret]# kubectl get secret mysecret  -o yaml
apiVersion: v1
data:
  password: MTIzNDU2
  username: YWRtaW4=
kind: Secret
metadata:
  creationTimestamp: 2018-07-18T09:02:20Z
  name: mysecret
  namespace: default
  resourceVersion: "898655"
  selfLink: /api/v1/namespaces/default/secrets/mysecret
  uid: 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的方式引用

通过如下步骤：

  1. 创建一个Secret,也可以使用现有的Secret,多个Pod可以使用同一个Secret
  2. 定义Pod时，添加参数.spec.volumes[]，可以自定义卷名，在.spec.volumes[].secret.secretName参数中指定Secret对象名。
  3. 给每一个需要使用到此Secret的容器添加参数.spec.containers[].volumeMounts[]，指定.spec.containers[].volumeMounts[].readOnly = true 和 .spec.containers[].volumeMounts[].mountPath参数来存放Secret到未使用的空目录中。
  4. 修改镜像或者通过目录的方式，使程序能够通过使用目录路径的方式找到Secret,每个存放在Secret中的key值，都会以文件的形式挂载到挂载目录中。

这里给出一个示例：

apiVersion: v1
kind: Pod
metadata:
  name: mypod
spec:
  containers:
  - name: mypod
    image: redis
    volumeMounts:
    - name: foo
      mountPath: "/etc/foo"
      readOnly: true
  volumes:
  - name: foo
    secret:
      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: mypod
    image: redis
    volumeMounts:
    - name: foo
      mountPath: "/etc/foo"
      readOnly: true
  volumes:
  - name: foo
    secret:
      secretName: mysecret
      items:          # 这里为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: mypod
    image: redis
    volumeMounts:
    - name: foo
      mountPath: "/etc/foo"
  volumes:
  - name: foo
    secret:
      secretName: mysecret
      defaultMode: 256      # 这里是使用十进制表示的，转换为8进制为0400

这样在指定的挂载卷下，所有被Secret创建的文件都有400的权限。需要注意的是，JSON参数不支持八进制的表示方式，所以使用十进制的256方式来表示400权限。但是在使用YAML格式的文件定义Pod时可以正常使用八进制的表示方式。

同理，也可以指定key的路径，并分配权限：

apiVersion: v1
kind: Pod
metadata:
  name: mypod
spec:
  containers:
  - name: mypod
    image: redis
    volumeMounts:
    - name: foo
      mountPath: "/etc/foo"
  volumes:
  - name: foo
    secret:
      secretName: mysecret
      items:
      - key: username
        path: my-group/my-username
        mode: 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: mycontainer
    image: redis
    env:
      - name: SECRET_USERNAME
        valueFrom:
          secretKeyRef:
            name: mysecret
            key: username
      - name: SECRET_PASSWORD
        valueFrom:
          secretKeyRef:
            name: mysecret
            key: password
  restartPolicy: 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

通过如下步骤配置：

  1. 使用命令行登录私有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)"
    }
}
  1. 将此文件内容转换为base64编码：

    # cat /root/.docker/config.json | base64
ewoJImF1dGhzIjogewoJCSJsb2NhbGhvc3Q6NTAwMCI6IHsKCQkJImF1dGgiOiAiZEdWemREcDBa
WE4wTVRJekNnPT0iICAjIOS9v+eUqGJhc2U2NOaWueW8j+e8lueggeeahOi0puWPt+WvhueggQoJ
CX0KCX0sCgkiSHR0cEhlYWRlcnMiOiB7CgkJIlVzZXItQWdlbnQiOiAiRG9ja2VyLUNsaWVudC8x
Ny4wOS4xLWNlIChsaW51eCkiCgl9Cn0K
  2. 创建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文件
  1. 创建Pod时，添加Secret:
apiVersion: v1
kind: Pod
metadata:
  name: foo
  namespace: awesomeapps
spec:
  containers:
    - name: foo
      image: janedoe/awesomeapp:v1
  imagePullSecrets:
    - name: myregistrykey

添加ImagePullSecrets到 Service account (Pod 自动添加ImagePullSecrets)

  1. 创建了上述的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。

  1. 导出default得 Serviceaccount文件：
kubectl get serviceaccounts default -o yaml > ./sa.yaml
  1. 编辑此文件，删除"resourceVersion"所在的行，添加 "imagePullSecrets:"参数：
$ cat sa.yaml
apiVersion: v1
kind: ServiceAccount
metadata:
  creationTimestamp: 2015-08-07T22:02:39Z
  name: default
  namespace: default
  selfLink: /api/v1/namespaces/default/serviceaccounts/default
  uid: 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-pod
  labels:
    name: secret-test
spec:
  volumes:
  - name: secret-volume
    secret:
      secretName: ssh-key-secret
  containers:
  - name: ssh-test-container
    image: mySshImage
    volumeMounts:
    - name: secret-volume
      readOnly: true
      mountPath: "/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: Pod
  apiVersion: v1
  metadata:
    name: prod-db-client-pod
    labels:
      name: prod-db-client
  spec:
    volumes:
    - name: secret-volume
      secret:
        secretName: prod-db-secret
    containers:
    - name: db-client-container
      image: myClientImage
      volumeMounts:
      - name: secret-volume
        readOnly: true
        mountPath: "/etc/secret-volume"
- kind: Pod
  apiVersion: v1
  metadata:
    name: test-db-client-pod
    labels:
      name: test-db-client
  spec:
    volumes:
    - name: secret-volume
      secret:
        secretName: test-db-secret
    containers:
    - name: db-client-container
      image: myClientImage
      volumeMounts:
      - name: secret-volume
        readOnly: true
        mountPath: "/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-pod
  labels:
    name: prod-db-client
spec:
  serviceAccount: prod-db-client
  containers:
  - name: db-client-container
    image: 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-volume
    secret:
      secretName: dotfile-secret
  containers:
  - name: dotfile-test-container
    image: k8s.gcr.io/busybox
    command:
    - ls
    - "-l"
    - "/etc/secret-volume"
    volumeMounts:
    - name: secret-volume
      readOnly: true
      mountPath: "/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数据加密。参考文档

原文地址：http://blog.51cto.com/tryingstuff/2147789

时间： 2024-10-10 19:01:12

Kubernetes Secret的相关文章

Kubernetes之容器

Images You create your Docker image and push it to a registry before referring to it in a Kubernetes pod. The image property of a container supports the same syntax as the docker command does, including private registries and tags. Updating Images Us

【免费下载】全套最新 5、Kubernetes 视频教程+教学资料+学习课件+源代码+软件开发工具

5.Kubernetes视频教程 网盘地址: 链接:https://pan.baidu.com/s/11W8KDUjk36USxdrA8p0t4A 提取码:43xt 加公众号 获取更多新教程 教程目录大纲 ./5.Kubernetes ├── 10.Kubernetes - Helm 及其它功能性组件 │?? ├── 1.笔记 │?? │?? ├── 1.部署 Helm.pdf │?? │?? ├── 2.使用 Helm 部署 dashboard .pdf │?? │?? ├── 3.使用 He

CentOS上安装Kubernetes集群（四）使用Traefi暴露Kubernetes服务

k8s的集群大多数情况需要对外服务,而服务暴露的方式有很多,这里选取traefik来讲解,其它就暂时不详细介绍,包括Istio,代后续更新后再补充上来.一句话,来不及解释,赶紧上车. Traefkik简介 Traefik是开源边缘路由器,类似 nginx.apache 那样的反向代理服务器.网关,代表系统接收请求,并找出负责处理这些请求的组件.Traefik自动发现适合您服务的配置,同时热更新支持多种负载均衡算法断路器,重试提供监控.管理 UI 界面用 go 语言开发,天然的拥抱 k8s Tra

k8s glusterfs heketi

kubernetes集群上node节点安装glusterfs的服务端集群(DaemonSet方式),并将heketi以deployment的方式部署到kubernetes集群,主要是实现 storageclass Heketi是一个具有resetful接口的glusterfs管理程序, Heketi提供了一个RESTful管理界面,可用于管理GlusterFS卷的生命周期.借助Heketi,Kubernetes 可以动态地配置GlusterFS卷和任何支持的持久性类型.Heketi将自动确定整个

Istio技术与实践6：Istio如何为服务提供安全防护能力

凡是产生连接关系,就必定带来安全问题,人类社会如此,服务网格世界,亦是如此.今天,我们就来谈谈Istio第二主打功能---保护服务.那么,便引出3个问题:? Istio凭什么保护服务?? Istio具体如何保护服务?? 如何告诉Istio发挥保护能力? 1 Istio凭什么保护服务?将单体应用程序分解为一个个服务,为大型软件系统的开发和维护带来了诸多好处,比如更好的灵活性.可伸缩性和可复用性.但这也带来了一些安全问题:? 为了抵御中间人×××,需要对流量进行加密? 为了提供灵活的服务访问控制,需

k8s在dashboard实现静态文件认证

参考:  https://www.cnblogs.com/wayneiscoming/p/7715623.html   ,   https://jimmysong.io/kubernetes-handbook/guide/rbac.md  , https://feisky.gitbooks.io/kubernetes/zh/plugins/authentication.html   ,  https://jimmysong.io/kubernetes-handbook/guide/rbac.ht

k8s使用Glusterfs动态生成pv

一.环境介绍 [[email protected] ~]# cat /etc/hosts127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4::1 localhost localhost.localdomain localhost6 localhost6.localdomain6 172.31.250.152 k8s-m172.31.250.153 node1172.31.250.154 node

idou老师教你学istio1：如何为服务提供安全防护能力

今天,我们就来谈谈Istio主打功能---保护服务. 那么,便引出3个问题: Istio 凭什么保护服务? Istio 具体如何保护服务? 如何告诉 Istio 发挥保护能力? Istio凭什么保护服务? 将单体应用程序分解为一个个服务,为大型软件系统的开发和维护带来了诸多好处,比如更好的灵活性.可伸缩性和可复用性.但这也带来了一些安全问题: 为了抵御中间***,需要对流量进行加密 为了提供灵活的服务访问控制,需要 mTLS(双向的安全传输层协议)和细粒度的访问策略 要审计谁在什么时候做了什么,

关于Istio 1.1，你所不知道的细节

本文整理自Istio社区成员Star在 Cloud Native Days China 2019 北京站的现场分享 第1则 主角 Istio Istio作为service mesh领域的明星项目,从2016年发布到现在热度不断攀升. Istio & Envoy Github Star Growth 官网中Istio1.1的架构图除了数据面的Envoy和控制面的Pilot,Mixer,Citadel三大组件外,引入了Galley组件验证Istio API 的配置. Istio能带来什么收益呢? 开