我对Kubernetes的学习有些晚 – 15. 安全性 –

2 年 ago

科, 雅

4 minutes

ストーリー

一足遅れて Kubernetes を学び始める – 16. コンポーネント –

上次

开始学习Kubernetes时落后了一步 – 在第14章调度中，我们学习了有关使用亲和性等进行Pod调度的内容。现在，我们将学习有关安全性的内容。

服务账户

据说为了控制在Pod中执行的进程，被分配的帐户被称为服务帐户。

apiVersion: v1
kind: ServiceAccount
metadata:
  name: sample-serviceaccount
  namespace: default
imagePullSecrets:
  - name: hogehoge

我会试着申请这个。

pi@raspi001:~/tmp $ k apply -f sample-serviceaccount.yaml
pi@raspi001:~/tmp $ k get serviceaccounts sample-serviceaccount -o yaml
...
secrets:
- name: sample-serviceaccount-token-4xhgm

サービスアカウントが作成されました。また、imagePullSecretsの内容がsecretsに登録されました。(sample-serviceaccount-token-4xhgm)
imagePullSecretsはprivateなdockerレジストリに使います。

pi@raspi001:~/tmp $ k get secrets sample-serviceaccount-token-4xhgm -o yaml
apiVersion: v1
data:
  ca.crt: ...
  namespace: ZGVmYXVsdA==
  token: ...
kind: Secret
metadata:
  annotations:
    kubernetes.io/service-account.name: sample-serviceaccount
    kubernetes.io/service-account.uid: 4bd076da-8854-11e9-af26-b827eb8ccd80
  creationTimestamp: "2019-06-06T12:12:04Z"
  name: sample-serviceaccount-token-4xhgm
  namespace: default
  resourceVersion: "584634"
  selfLink: /api/v1/namespaces/default/secrets/sample-serviceaccount-token-4xhgm
  uid: 4bfbe8bb-8854-11e9-af26-b827eb8ccd80
type: kubernetes.io/service-account-token

你已经注册了必要的认证令牌。

基于角色的访问控制（RBAC）

RBAC将创建的服务账户与所允许的操作相关联，通过角色绑定(RoleBinding)来进行权限管理。可以通过角色绑定将多个服务账户绑定到一个角色上。

RBAC有两个层级，一个是命名空间级别，另一个是集群级别。
集群级别的设置范围更大一些。（如果要跨命名空间进行设置，则应选择集群级别。）

RoleBindingとClusterRoleBinding

操作の種類ですが、どのDeploymentやDaemonSetのようなリソースに対して下記のものがあります。

*全ての処理create作成delete削除get取得list一覧取得update更新patch一部変更watch変更の追従

关于Kubernetes的RBAC

此次将参考 Kubernetes 道场第20天的内容 – 角色/角色绑定/集群角色/集群角色绑定。

我将使用新创建的服务账户创建一个上下文，并尝试从该账户中获取Pod信息。
为此，需要通过服务账户的认证信息进行预先配置。
※ 由于”Role”和”ClusterRole”之间没有太大区别，因此我将尝试使用”Role”。

pi@raspi001:~/tmp $ TOKEN=$(k get secret/sample-serviceaccount-token-jd279 -o json | jq -r .data.token)
pi@raspi001:~/tmp $ DECODE_TOKEN=$(echo -n $TOKEN | base64 -d)
pi@raspi001:~/tmp $ k config set-credentials sample-serviceaccount --token $DECODE_TOKEN

然后，创建一个上下文（sample-sa-context）并使用它。

pi@raspi001:~/tmp $ k config set-context sample-sa-context --user sample-serviceaccount --cluster kubernetes
pi@raspi001:~/tmp $ k config use-context sample-sa-context
pi@raspi001:~/tmp $ k config get-contexts
CURRENT   NAME                          CLUSTER      AUTHINFO                NAMESPACE
          kubernetes-admin@kubernetes   kubernetes   kubernetes-admin
*         sample-sa-context             kubernetes   sample-serviceaccount

我会尝试使用新创建的服务帐户来获取Pod的信息。

pi@raspi001:~/tmp $ k get po
Error from server (Forbidden): pods is forbidden: User "system:serviceaccount:default:sample-serviceaccount" cannot list resource "pods" in API group "" in the namespace "default"

发生错误了。这是因为”sample-serviceaccount”没有绑定任何角色。
好的，我们来做Role绑定。

我将回到原来的状态。

pi@raspi001:~/tmp $ k config use-context kubernetes-admin@kubernetes

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: sample-role
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "watch", "list"]

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: sample-rolebinding
  namespace: default
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: sample-role
subjects:
- kind: ServiceAccount
  name: sample-serviceaccount
  namespace: default

pi@raspi001:~/tmp $ k apply -f sample-role.yaml
pi@raspi001:~/tmp $ k apply -f sample-rolebinding.yaml

那么，我会再试一次。

pi@raspi001:~/tmp $ k config use-context sample-sa-context
pi@raspi001:~/tmp $ k get po
NAME                                      READY   STATUS    RESTARTS   AGE
...

哦，我成功获取了！我会恢复原状。

pi@raspi001:~/tmp $ k config use-context kubernetes-admin@kubernetes

安全环境

可以对容器进行安全设置。例如，可以添加或删除功能，更改运行用户或组，将文件设为只读等。

apiVersion: v1
kind: Pod
metadata:
  name: sample-capabilities
spec:
  containers:
    - name: nginx-container
      image: nginx:1.12
      securityContext:
        capabilities:
          add: ["SYS_ADMIN"]
          drop: ["AUDIT_WRITE"]

我会申请并查看其中内容。

pi@raspi001:~/tmp $ k apply -f sample-capabilities.yaml
pi@raspi001:~/tmp $ k exec -it sample-capabilities /bin/bash
root@sample-capabilities:/# apt update && apt install libcap2-bin
root@sample-capabilities:/# capsh --print | grep Current
Current: = cap_chown,cap_dac_override,cap_fowner,cap_fsetid,cap_kill,cap_setgid,cap_setuid,cap_setpcap,cap_net_bind_service,cap_net_raw,cap_sys_chroot,cap_sys_admin,cap_mknod,cap_setfcap+eip
root@sample-capabilities:/# exit

最近cap_sys_admin的使用似乎在增加，但是找不到audit_write权限。
说实话，我之前并不知道有哪些权限，所以参考了这个资料。

PodSecurityContext:

Pod 安全上下文

您可以为每个Pod（容器）设置安全配置。
例如，您可以控制要执行的用户或组，拒绝root执行，并覆盖内核参数。

apiVersion: v1
kind: Pod
metadata:
  name: sample-runuser
spec:
  securityContext:
    runAsUser: 99
    # runAsGroup: 99
    supplementalGroups:
    - 1001
    - 1002
  containers:
    - name: centos-container
      image: centos:7
      command: ["/bin/sleep", "3600"]

我正在申请。

pi@raspi001:~/tmp $ k apply -f sample-runuser.yaml
pi@raspi001:~/tmp $ k exec -it sample-runuser -- id
uid=99(nobody) gid=99(nobody) groups=99(nobody),1001,1002
pi@raspi001:~/tmp $ k exec -it sample-runuser -- ps aux | grep sleep
nobody       1  0.0  0.0   2032   372 ?        Ss   14:02   0:00 /bin/sleep 3600

用户已被更改为nobody(99)。此外，在supplementalGroups中，可以将指定的GID添加到主要的GID中。

其他（其中的其他）

据说还有PodSecurityPolicy、NetworkPolicy以及认证和授权的AdmissionControl。

整理收拾

pi@raspi001:~/tmp $ k delete -f sample-serviceaccount.yaml -f sample-role.yaml -f sample-rolebinding.yaml -f sample-capabilities.yaml -f sample-runuser.yaml
pi@raspi001:~/tmp $ k config delete-context sample-sa-context

最终

我主要学习了RBAC。
当多人协作开发时，最好是根据不同的上下文进行开发。
就像我们这次所做的那样，通过RBAC可以管理谁具有哪些权限，
这样就不太可能因为给予了过多的权限而导致事故。
（虽然说，我只是个人使用，并不清楚情况…）
下次是最后一次了。