0

我有一个在 kubernetes 集群中以特权模式运行的守护程序集。这是守护程序集的 YAML 规范。

apiVersion: extensions/v1beta1
kind: DaemonSet
metadata:
  name: my-daemon
spec:
  template:
    metadata:
      labels:
        app: my-daemon
    spec:
      hostNetwork: true
      serviceAccountName: my-sa-account
      containers:
      - name: my-daemon
        image: akhilerm/my-daemon:0.5
        imagePullPolicy: Always
        securityContext:
          privileged: true
...
...

我没有使用privileged:true，而是转向 linux 功能以授予对 DaemonSet 的权限。因此，我将所有 linux 功能添加到容器中并删除了privileged:true. 这是新的 YAML 规范

apiVersion: extensions/v1beta1
kind: DaemonSet
metadata:
  name: my-daemon
spec:
  template:
    metadata:
      labels:
        app: my-daemon
    spec:
      hostNetwork: true
      serviceAccountName: my-sa-account
      containers:
      - name: my-daemon
        image: akhilerm/my-daemon:0.5
        imagePullPolicy: Always
        securityContext:
          capabilities:
            add: ["NET_BROADCAST", "NET_ADMIN", ..all CAPs..,"SYS_ADMIN"]
...
...

但是当与 linux 功能一起使用时，守护进程的行为并不像预期的那样。在这两种情况下，/proc/1/status容器内的权限位图都是相同的。

...
SigPnd: 0000000000000000
ShdPnd: 0000000000000000
SigBlk: 0000000000010000
SigIgn: 0000000000000004
SigCgt: 0000000000014002
CapInh: 0000003fffffffff
CapPrm: 0000003fffffffff
CapEff: 0000003fffffffff
CapBnd: 0000003fffffffff
CapAmb: 0000000000000000
...

在 kubernetes 中使用带有 pod 的 linux 功能时，我还需要设置更多字段或权限吗？

4

1 回答 1

0

我不是 100% 确定，但这个问题可能在缺失的capabilities:领域。

apiVersion: extensions/v1beta1
kind: DaemonSet
metadata:
  name: my-daemon
spec:
  template:
    metadata:
      labels:
        app: my-daemon
    spec:
      hostNetwork: true
      serviceAccountName: my-sa-account
      containers:
      - name: my-daemon
        image: akhilerm/my-daemon:0.5
        imagePullPolicy: Always
        securityContext:
          capabilities:
            add: ["NET_BROADCAST", "NET_ADMIN", ..all CAPs..,"SYS_ADMIN"]
...
...

或者

apiVersion: extensions/v1beta1
kind: DaemonSet
metadata:
  name: my-daemon
spec:
  template:
    metadata:
      labels:
        app: my-daemon
    spec:
      hostNetwork: true
      serviceAccountName: my-sa-account
      containers:
      - name: my-daemon
        image: akhilerm/my-daemon:0.5
        imagePullPolicy: Always
        securityContext:
          capabilities:
            add:
            - NET_BROADCAST
            - NET_ADMIN
            - ...
            - SYS_ADMIN
...
...

测试它，让我知道是否有任何成功。如果没有 - 我将尝试更深入地挖掘并为您提供另一种解决方案。我在所有示例中都找到了这种格式，所以希望它会有所帮助。作为一个真实的例子，我可以为您提供kubernetes-the-not-so-hard-way-with-ansible-ingress-with-traefik文章以及以下解释：

securityContext:
  capabilities:
    drop:
    - ALL
    add:
    - NET_BIND_SERVICE

如果没有这个设置，我们将无法在端口 80 和 443 上绑定 Traefik（这对于所有想要使用端口 < 1024 的服务基本上都是如此）。我们也可以使用 privileged: true 但这会使攻击面更大。因此，使用 Linux Capabilities 可以让我们对超级用户权限进行细粒度控制，并将权限降至最低。

或者 Kubernetes 官方security-context文章中的另外 1 篇，但这次配置是针对 Pod 的：

apiVersion: v1
kind: Pod
metadata:
  name: security-context-demo-4
spec:
  containers:
  - name: sec-ctx-4
    image: gcr.io/google-samples/node-hello:1.0
    securityContext:
      capabilities:
        add: ["NET_ADMIN", "SYS_TIME"]

希望这会帮助你。

于 2019-02-04T16:46:25.017 回答