search

awslabs / amazon-eks-ami

Packer configuration for building a custom EKS AMI
https://awslabs.github.io/amazon-eks-ami/
MIT No Attribution
2.4k stars 1.13k forks source link

seccomp profile not works for syscalls 435 439 #1401

Open alan2112000 opened 11 months ago

alan2112000 commented 11 months ago

What happened: The syscalls in the seccomp did not be allowed to use in pod. We are using playwright to crawl website and I followed the instruction, to create seccomp profile and apply to the pod. It works in our legacy environment AWS Region: us-west-2 Kubernetes Version: 1.21 EKS Version: eks.20 Instance Type: r5.large AMI: amazon-eks-node-1.21-v20220406

After upgraded the cluster to 1.27 and amazon-eks-node-1.27-v20230816 AMI, there are three types of syscalls show in audit.log

type=SECCOMP msg=audit(1692609701.878:800): auid=4294967295 uid=1001 gid=1001 ses=4294967295 pid=768 comm="node" exe="/venv/lib/python3.10/site-packages/playwright/driver/node" sig=0 arch=c000003e syscall=330 compat=0 ip=0x7effec06211b code=0x7ffc0000
type=SECCOMP msg=audit(1692605223.072:587): auid=4294967295 uid=1001 gid=1001 ses=4294967295 pid=16630 comm="scrapy" exe="/usr/bin/python3.10" sig=0 arch=c000003e syscall=435 compat=0 ip=0x7f03f7a4d9ed code=0x7ffc0000
type=SECCOMP msg=audit(1692605179.452:515): auid=4294967295 uid=1001 gid=1001 ses=4294967295 pid=16777 comm="ldd" exe="/usr/bin/bash" sig=0 arch=c000003e syscall=439 compat=0 ip=0x7f8b628d7ca4 code=0x7ffc0000

According to the syscalls table

I added 

330 pkey_alloc
435 clone3
439 faccessat2

into seccomp profile, but only the 330 audit log is gone.

What you expected to happen:

seccomp profile should work for new syscalls 435 439, so I can change the action to SCMP_ACT_ERRNO.

How to reproduce it (as minimally and precisely as possible):

  1. Create the same EKS environment like below
  2. Create the seccomp profile in the node
  3. Apply the example pod into cluster.
  4. The pod will turn into error state.(cannot create a new thread)

Anything else we need to know?:

Environment

BASE_AMI_ID="ami-0a6c4ce5a4a59e9e2"
BUILD_TIME="Wed Aug 16 02:57:51 UTC 2023"
BUILD_KERNEL="5.10.186-179.751.amzn2.x86_64"
ARCH="x86_64"
cartermckinnon commented 11 months ago

I'm not aware of anything specific to AL2 that would cause this. Are you able to reproduce it on a different distro, like the EKS Ubuntu AMI?

alan2112000 commented 11 months ago

With same environment I mentioned above (1.27), I used EKS ubuntu AMI I cannot reproduce the bug. I event don't have to add any new syscalls into the seccomp profile to make it works.

Environment

AMI Version: ubuntu-eks/k8s_1.27/images/hvm-ssd/ubuntu-focal-20.04-amd64-server-20230628 Kernel: 5.15.0-1039-aws Release Information(run cat /etc/lsb-release)

DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=20.04
DISTRIB_CODENAME=focal
DISTRIB_DESCRIPTION="Ubuntu 20.04.6 LTS"