From 30a609bdef95fe301165e3f1099c153f15f57014 Mon Sep 17 00:00:00 2001 From: Danny__Wei Date: Fri, 8 Nov 2024 11:13:37 +0800 Subject: [PATCH 1/5] fix: Read kernel events by default when the behaviorModeling feature is enabled --- internal/agent/agent.go | 2 +- pkg/auditor/auditor.go | 84 +++++++++++++++++++------------------ pkg/auditor/auditor_test.go | 2 +- 3 files changed, 45 insertions(+), 43 deletions(-) diff --git a/internal/agent/agent.go b/internal/agent/agent.go index 6eda7680..94e817fb 100644 --- a/internal/agent/agent.go +++ b/internal/agent/agent.go @@ -238,7 +238,7 @@ func NewAgent( } // Create an auditor to audit violation and behavior events for AppArmor, Seccomp and BPF enforcers - agent.auditor, err = varmorauditor.NewAuditor(agent.nodeName, agent.appArmorSupported, agent.bpfLsmSupported, log.WithName("AUDIT-VIOLATIONS")) + agent.auditor, err = varmorauditor.NewAuditor(agent.nodeName, agent.appArmorSupported, agent.bpfLsmSupported, agent.enableBehaviorModeling, log.WithName("AUDIT-VIOLATIONS")) if err != nil { return nil, err } diff --git a/pkg/auditor/auditor.go b/pkg/auditor/auditor.go index fa5e8bc9..8d17c6ea 100644 --- a/pkg/auditor/auditor.go +++ b/pkg/auditor/auditor.go @@ -36,52 +36,54 @@ const ( ) type Auditor struct { - nodeName string - bootTimestamp uint64 - appArmorSupported bool - bpfLsmSupported bool - TaskStartCh chan varmortypes.ContainerInfo - TaskDeleteCh chan varmortypes.ContainerInfo - TaskDeleteSyncCh chan bool - mntNsIDCache map[uint32]uint32 // key: The init PID of contaienr, value: The mnt ns id - containerCache map[uint32]varmortypes.ContainerInfo // key: The mnt ns id of container, value: The container information - auditEventChs map[string]chan<- string // auditEventChs used for sending apparmor & seccomp behavior event to subscribers - bpfEventChs map[string]chan<- bpfenforcer.BpfEvent // bpfEventChs used for sending bpf behavior event to subscribers - journalReader *sdjournal.JournalReader - journalReaderTimeout chan time.Time - savedRateLimit uint64 - auditRbMap *ebpf.Map - capabilityMap map[uint32]string - filePermissionMap map[uint32]string - ptracePermissionMap map[uint32]string - mountFlagMap map[uint32]string - violationLogger zerolog.Logger - log logr.Logger + nodeName string + bootTimestamp uint64 + appArmorSupported bool + bpfLsmSupported bool + enableBehaviorModeling bool + TaskStartCh chan varmortypes.ContainerInfo + TaskDeleteCh chan varmortypes.ContainerInfo + TaskDeleteSyncCh chan bool + mntNsIDCache map[uint32]uint32 // key: The init PID of contaienr, value: The mnt ns id + containerCache map[uint32]varmortypes.ContainerInfo // key: The mnt ns id of container, value: The container information + auditEventChs map[string]chan<- string // auditEventChs used for sending apparmor & seccomp behavior event to subscribers + bpfEventChs map[string]chan<- bpfenforcer.BpfEvent // bpfEventChs used for sending bpf behavior event to subscribers + journalReader *sdjournal.JournalReader + journalReaderTimeout chan time.Time + savedRateLimit uint64 + auditRbMap *ebpf.Map + capabilityMap map[uint32]string + filePermissionMap map[uint32]string + ptracePermissionMap map[uint32]string + mountFlagMap map[uint32]string + violationLogger zerolog.Logger + log logr.Logger } // NewAuditor creates an auditor to audit the violations of target containers -func NewAuditor(nodeName string, appArmorSupported, bpfLsmSupported bool, log logr.Logger) (*Auditor, error) { +func NewAuditor(nodeName string, appArmorSupported, bpfLsmSupported, enableBehaviorModeling bool, log logr.Logger) (*Auditor, error) { auditor := Auditor{ - nodeName: nodeName, - appArmorSupported: appArmorSupported, - bpfLsmSupported: bpfLsmSupported, - TaskStartCh: make(chan varmortypes.ContainerInfo, 100), - TaskDeleteCh: make(chan varmortypes.ContainerInfo, 100), - TaskDeleteSyncCh: make(chan bool, 1), - mntNsIDCache: make(map[uint32]uint32, 100), - containerCache: make(map[uint32]varmortypes.ContainerInfo, 100), - auditEventChs: make(map[string]chan<- string), - bpfEventChs: make(map[string]chan<- bpfenforcer.BpfEvent), - savedRateLimit: 0, - capabilityMap: initCapabilityMap(), - filePermissionMap: initFilePermissionMap(), - ptracePermissionMap: initPtracePermissionMap(), - mountFlagMap: initMountFlagMap(), - log: log, + nodeName: nodeName, + appArmorSupported: appArmorSupported, + bpfLsmSupported: bpfLsmSupported, + enableBehaviorModeling: enableBehaviorModeling, + TaskStartCh: make(chan varmortypes.ContainerInfo, 100), + TaskDeleteCh: make(chan varmortypes.ContainerInfo, 100), + TaskDeleteSyncCh: make(chan bool, 1), + mntNsIDCache: make(map[uint32]uint32, 100), + containerCache: make(map[uint32]varmortypes.ContainerInfo, 100), + auditEventChs: make(map[string]chan<- string), + bpfEventChs: make(map[string]chan<- bpfenforcer.BpfEvent), + savedRateLimit: 0, + capabilityMap: initCapabilityMap(), + filePermissionMap: initFilePermissionMap(), + ptracePermissionMap: initPtracePermissionMap(), + mountFlagMap: initMountFlagMap(), + log: log, } // Create a systemd-journald reader to read the kernel events - if appArmorSupported { + if appArmorSupported || enableBehaviorModeling { r, err := sdjournal.NewJournalReader(sdjournal.JournalReaderConfig{ Since: time.Duration(-5) * time.Second, Matches: []sdjournal.Match{ @@ -195,7 +197,7 @@ func (auditor *Auditor) DeleteBehaviorEventNotifyCh(subscriber string) { } func (auditor *Auditor) Run(stopCh <-chan struct{}) { - if auditor.appArmorSupported { + if auditor.appArmorSupported || auditor.enableBehaviorModeling { go auditor.readFromSystemdJournald() } if auditor.bpfLsmSupported { @@ -205,7 +207,7 @@ func (auditor *Auditor) Run(stopCh <-chan struct{}) { } func (auditor *Auditor) Close() { - if auditor.appArmorSupported { + if auditor.appArmorSupported || auditor.enableBehaviorModeling { auditor.journalReaderTimeout <- time.Now() auditor.journalReader.Close() } diff --git a/pkg/auditor/auditor_test.go b/pkg/auditor/auditor_test.go index e75cf6a3..fec4c67d 100644 --- a/pkg/auditor/auditor_test.go +++ b/pkg/auditor/auditor_test.go @@ -27,7 +27,7 @@ func Test_SystemdJournald(t *testing.T) { c := textlogger.NewConfig() log.SetLogger(textlogger.NewLogger(c)) - a, err := NewAuditor("test", true, false, log.Log.WithName("AUDIT-VIOLATIONS")) + a, err := NewAuditor("test", true, false, true, log.Log.WithName("AUDIT-VIOLATIONS")) assert.NilError(t, err) syncCh := make(chan struct{}, 1) From a274953b250c53c369504387f877e4ca31f0c79d Mon Sep 17 00:00:00 2001 From: Danny__Wei Date: Fri, 8 Nov 2024 13:28:46 +0800 Subject: [PATCH 2/5] refactor: Tail the audit log file instead of reading from systemd-journald --- .github/scripts/toolchain.sh | 2 +- cmd/varmor/Dockerfile | 2 +- config/manifest/agent.yaml | 17 -- go.mod | 4 +- go.sum | 8 +- internal/agent/agent.go | 4 +- .../varmor/templates/daemonsets/agent.yaml | 13 -- pkg/auditor/audit.go | 161 ++++++++---------- pkg/auditor/auditor.go | 48 ++++-- pkg/auditor/auditor_test.go | 2 +- 10 files changed, 117 insertions(+), 144 deletions(-) diff --git a/.github/scripts/toolchain.sh b/.github/scripts/toolchain.sh index 1ea382fa..e49fb1d8 100755 --- a/.github/scripts/toolchain.sh +++ b/.github/scripts/toolchain.sh @@ -4,4 +4,4 @@ wget https://apt.llvm.org/llvm.sh -O /tmp/llvm.sh chmod +x /tmp/llvm.sh sudo /tmp/llvm.sh 17 sudo ln -s $(which llvm-strip-17) /usr/local/bin/llvm-strip -sudo apt -y install libapparmor-dev libseccomp-dev libsystemd-dev +sudo apt -y install libapparmor-dev libseccomp-dev diff --git a/cmd/varmor/Dockerfile b/cmd/varmor/Dockerfile index 4eca59f6..3dfb9a07 100644 --- a/cmd/varmor/Dockerfile +++ b/cmd/varmor/Dockerfile @@ -56,7 +56,7 @@ COPY --from=vArmor-ebpf-builder /varmor/vArmor-ebpf/pkg/bpfenforcer/bpf_bpfel.go COPY --from=vArmor-ebpf-builder /varmor/vArmor-ebpf/pkg/bpfenforcer/bpf_bpfel.o /varmor/pkg/lsm/bpfenforcer RUN apt-get update -RUN apt-get install -y libseccomp2 libseccomp-dev libsystemd-dev +RUN apt-get install -y libseccomp2 libseccomp-dev RUN export GOOS=$(echo ${TARGETPLATFORM} | cut -d / -f1) && \ export GOARCH=$(echo ${TARGETPLATFORM} | cut -d / -f2) RUN go env diff --git a/config/manifest/agent.yaml b/config/manifest/agent.yaml index b5bb9a31..c29b3d7d 100644 --- a/config/manifest/agent.yaml +++ b/config/manifest/agent.yaml @@ -52,11 +52,6 @@ spec: name: seccomp-dir - mountPath: /var/log name: var-log-dir - - mountPath: /run/log - name: run-log-dir - - mountPath: /etc/machine-id - name: machine-id - readOnly: true - mountPath: /var/run/secrets/tokens name: bound-token readinessProbe: @@ -82,10 +77,6 @@ spec: path: /run/containerd type: Directory name: containerd - - hostPath: - path: /proc - type: Directory - name: procfs - hostPath: path: /var/run/varmor/audit type: DirectoryOrCreate @@ -106,14 +97,6 @@ spec: path: /var/log type: Directory name: var-log-dir - - hostPath: - path: /run/log - type: Directory - name: run-log-dir - - hostPath: - path: /etc/machine-id - type: File - name: machine-id - projected: sources: - serviceAccountToken: diff --git a/go.mod b/go.mod index ba8d8f25..962c025b 100644 --- a/go.mod +++ b/go.mod @@ -7,13 +7,13 @@ require ( github.com/cilium/ebpf v0.16.0 github.com/containerd/containerd v1.7.5 github.com/containerd/typeurl/v2 v2.1.1 - github.com/coreos/go-systemd/v22 v22.5.0 github.com/dlclark/regexp2 v1.9.0 github.com/gin-gonic/gin v1.9.1 github.com/go-logr/logr v1.4.2 github.com/hashicorp/go-version v1.6.0 github.com/julienschmidt/httprouter v1.3.0 github.com/kyverno/kyverno v1.7.4 + github.com/nxadm/tail v1.4.11 github.com/opencontainers/runtime-spec v1.1.0 github.com/pkg/errors v0.9.1 github.com/rs/zerolog v1.33.0 @@ -46,6 +46,7 @@ require ( github.com/docker/go-events v0.0.0-20190806004212-e31b211e4f1c // indirect github.com/emicklei/go-restful/v3 v3.11.0 // indirect github.com/evanphx/json-patch v4.12.0+incompatible // indirect + github.com/fsnotify/fsnotify v1.6.0 // indirect github.com/fxamacker/cbor/v2 v2.7.0 // indirect github.com/gabriel-vasile/mimetype v1.4.2 // indirect github.com/gin-contrib/sse v0.1.0 // indirect @@ -111,6 +112,7 @@ require ( google.golang.org/genproto/googleapis/rpc v0.0.0-20240318140521-94a12d6c2237 // indirect google.golang.org/protobuf v1.34.2 // indirect gopkg.in/inf.v0 v0.9.1 // indirect + gopkg.in/tomb.v1 v1.0.0-20141024135613-dd632973f1e7 // indirect gopkg.in/yaml.v2 v2.4.0 // indirect k8s.io/kube-openapi v0.0.0-20240228011516-70dd3763d340 // indirect k8s.io/utils v0.0.0-20240711033017-18e509b52bc8 // indirect diff --git a/go.sum b/go.sum index 933be2f5..dfe7075c 100644 --- a/go.sum +++ b/go.sum @@ -37,7 +37,6 @@ github.com/containerd/ttrpc v1.2.2/go.mod h1:sIT6l32Ph/H9cvnJsfXM5drIVzTr5A2flTf github.com/containerd/typeurl/v2 v2.1.1 h1:3Q4Pt7i8nYwy2KmQWIw2+1hTvwTE/6w9FqcttATPO/4= github.com/containerd/typeurl/v2 v2.1.1/go.mod h1:IDp2JFvbwZ31H8dQbEIY7sDl2L3o3HZj1hsSQlywkQ0= github.com/coreos/go-systemd/v22 v22.3.2/go.mod h1:Y58oyj3AT4RCenI/lSvhwexgC+NSVTIJ3seZv2GcEnc= -github.com/coreos/go-systemd/v22 v22.5.0 h1:RrqgGjYQKalulkV8NGVIfkXQf6YYmOyiJKk8iXXhfZs= github.com/coreos/go-systemd/v22 v22.5.0/go.mod h1:Y58oyj3AT4RCenI/lSvhwexgC+NSVTIJ3seZv2GcEnc= github.com/cpuguy83/go-md2man/v2 v2.0.0-20190314233015-f79a8a8ca69d/go.mod h1:maD7wRr/U5Z6m/iR4s+kqSMx2CaBsrgA7czyZG/E6dU= github.com/creack/pty v1.1.9/go.mod h1:oKZEueFk5CKHvIhNR5MUki03XCEU+Q6VDXinZuGJ33E= @@ -60,6 +59,8 @@ github.com/envoyproxy/protoc-gen-validate v0.1.0/go.mod h1:iSmxcyjqTsJpI2R4NaDN7 github.com/evanphx/json-patch v4.12.0+incompatible h1:4onqiflcdA9EOZ4RxV643DvftH5pOlLGNtQ5lPWQu84= github.com/evanphx/json-patch v4.12.0+incompatible/go.mod h1:50XU6AFN0ol/bzJsmQLiYLvXMP4fmwYFNcr97nuDLSk= github.com/frankban/quicktest v1.11.3/go.mod h1:wRf/ReqHper53s+kmmSZizM8NamnL3IM0I9ntUbOk+k= +github.com/fsnotify/fsnotify v1.6.0 h1:n+5WquG0fcWoWp6xPWfHdbskMCQaFnG6PfBrh1Ky4HY= +github.com/fsnotify/fsnotify v1.6.0/go.mod h1:sl3t1tCWJFWoRz9R8WJCbQihKKwmorjAbSClcnxKAGw= github.com/fxamacker/cbor/v2 v2.7.0 h1:iM5WgngdRBanHcxugY4JySA0nk1wZorNOpTgCMedv5E= github.com/fxamacker/cbor/v2 v2.7.0/go.mod h1:pxXPTn3joSm21Gbwsv0w9OSA2y1HFR9qXEeXQVeNoDQ= github.com/gabriel-vasile/mimetype v1.4.2 h1:w5qFW6JKBz9Y393Y4q372O9A7cUSequkh1Q7OhCmWKU= @@ -199,6 +200,8 @@ github.com/modern-go/reflect2 v1.0.2/go.mod h1:yWuevngMOJpCy52FWWMvUC8ws7m/LJsjY github.com/mrunalp/fileutils v0.5.0/go.mod h1:M1WthSahJixYnrXQl/DFQuteStB1weuxD2QJNHXfbSQ= github.com/munnerz/goautoneg v0.0.0-20191010083416-a7dc8b61c822 h1:C3w9PqII01/Oq1c1nUAm88MOHcQC9l5mIlSMApZMrHA= github.com/munnerz/goautoneg v0.0.0-20191010083416-a7dc8b61c822/go.mod h1:+n7T8mK8HuQTcFwEeznm/DIxMOiR9yIdICNftLE1DvQ= +github.com/nxadm/tail v1.4.11 h1:8feyoE3OzPrcshW5/MJ4sGESc5cqmGkGCWlco4l0bqY= +github.com/nxadm/tail v1.4.11/go.mod h1:OTaG3NK980DZzxbRq6lEuzgU+mug70nY11sMd4JXXHc= github.com/onsi/ginkgo v1.16.5 h1:8xi0RTUf59SOSfEtZMvwTvXYMzG4gV23XVHOZiXNtnE= github.com/onsi/ginkgo/v2 v2.19.0 h1:9Cnnf7UHo57Hy3k6/m5k3dRfGTMXGvxhHFvkDTCTpvA= github.com/onsi/ginkgo/v2 v2.19.0/go.mod h1:rlwLi9PilAFJ8jCg9UE1QP6VBpd6/xj3SRC0d6TU0To= @@ -339,6 +342,7 @@ golang.org/x/sys v0.0.0-20220520151302-bc2c85ada10a/go.mod h1:oPkhp1MJrh7nUepCBc golang.org/x/sys v0.0.0-20220715151400-c0bba94af5f8/go.mod h1:oPkhp1MJrh7nUepCBck5+mAzfO9JrbApNNgaTdGDITg= golang.org/x/sys v0.0.0-20220722155257-8c9f86f7a55f/go.mod h1:oPkhp1MJrh7nUepCBck5+mAzfO9JrbApNNgaTdGDITg= golang.org/x/sys v0.0.0-20220811171246-fbc7d0a398ab/go.mod h1:oPkhp1MJrh7nUepCBck5+mAzfO9JrbApNNgaTdGDITg= +golang.org/x/sys v0.0.0-20220908164124-27713097b956/go.mod h1:oPkhp1MJrh7nUepCBck5+mAzfO9JrbApNNgaTdGDITg= golang.org/x/sys v0.1.0/go.mod h1:oPkhp1MJrh7nUepCBck5+mAzfO9JrbApNNgaTdGDITg= golang.org/x/sys v0.5.0/go.mod h1:oPkhp1MJrh7nUepCBck5+mAzfO9JrbApNNgaTdGDITg= golang.org/x/sys v0.6.0/go.mod h1:oPkhp1MJrh7nUepCBck5+mAzfO9JrbApNNgaTdGDITg= @@ -413,6 +417,8 @@ gopkg.in/inf.v0 v0.9.1 h1:73M5CoZyi3ZLMOyDlQh031Cx6N9NDJ2Vvfl76EDAgDc= gopkg.in/inf.v0 v0.9.1/go.mod h1:cWUDdTG/fYaXco+Dcufb5Vnc6Gp2YChqWtbxRZE0mXw= gopkg.in/natefinch/lumberjack.v2 v2.2.1 h1:bBRl1b0OH9s/DuPhuXpNl+VtCaJXFZ5/uEFST95x9zc= gopkg.in/natefinch/lumberjack.v2 v2.2.1/go.mod h1:YD8tP3GAjkrDg1eZH7EGmyESg/lsYskCTPBJVb9jqSc= +gopkg.in/tomb.v1 v1.0.0-20141024135613-dd632973f1e7 h1:uRGJdciOHaEIrze2W8Q3AKkepLTh2hOroT7a+7czfdQ= +gopkg.in/tomb.v1 v1.0.0-20141024135613-dd632973f1e7/go.mod h1:dt/ZhP58zS4L8KSrWDmTeBkI65Dw0HsyUHuEVlX15mw= gopkg.in/yaml.v2 v2.2.2/go.mod h1:hI93XBmqTisBFMUTm0b8Fm+jr3Dg1NNxqwp+5A1VGuI= gopkg.in/yaml.v2 v2.2.8/go.mod h1:hI93XBmqTisBFMUTm0b8Fm+jr3Dg1NNxqwp+5A1VGuI= gopkg.in/yaml.v2 v2.4.0 h1:D8xgwECY7CYvx+Y2n4sBz93Jn9JRvxdiyyo8CTfuKaY= diff --git a/internal/agent/agent.go b/internal/agent/agent.go index 94e817fb..e49d1ad8 100644 --- a/internal/agent/agent.go +++ b/internal/agent/agent.go @@ -238,13 +238,13 @@ func NewAgent( } // Create an auditor to audit violation and behavior events for AppArmor, Seccomp and BPF enforcers - agent.auditor, err = varmorauditor.NewAuditor(agent.nodeName, agent.appArmorSupported, agent.bpfLsmSupported, agent.enableBehaviorModeling, log.WithName("AUDIT-VIOLATIONS")) + agent.auditor, err = varmorauditor.NewAuditor(agent.nodeName, agent.appArmorSupported, agent.bpfLsmSupported, agent.enableBehaviorModeling, log.WithName("AUDITOR")) if err != nil { return nil, err } // Subscribe auditor to the monitor - agent.monitor.AddTaskNotifyChs("AUDIT-VIOLATIONS", &agent.auditor.TaskStartCh, &agent.auditor.TaskDeleteCh, &agent.auditor.TaskDeleteSyncCh) + agent.monitor.AddTaskNotifyChs("AUDITOR", &agent.auditor.TaskStartCh, &agent.auditor.TaskDeleteCh, &agent.auditor.TaskDeleteSyncCh) // [Experimental feature] // Initialize the process tracer for BehaviorModeling mode. diff --git a/manifests/varmor/templates/daemonsets/agent.yaml b/manifests/varmor/templates/daemonsets/agent.yaml index 5b717539..01361b2e 100644 --- a/manifests/varmor/templates/daemonsets/agent.yaml +++ b/manifests/varmor/templates/daemonsets/agent.yaml @@ -68,11 +68,6 @@ spec: name: containerd - mountPath: /var/log name: var-log-dir - - mountPath: /run/log - name: run-log-dir - - mountPath: /etc/machine-id - name: machine-id - readOnly: true - mountPath: /var/run/secrets/tokens name: bound-token {{- if .Values.appArmorLsmEnforcer.enabled }} @@ -121,14 +116,6 @@ spec: path: /var/log type: Directory name: var-log-dir - - hostPath: - path: /run/log - type: Directory - name: run-log-dir - - hostPath: - path: /etc/machine-id - type: File - name: machine-id - projected: sources: - serviceAccountToken: diff --git a/pkg/auditor/audit.go b/pkg/auditor/audit.go index 062e303e..7de5c625 100644 --- a/pkg/auditor/audit.go +++ b/pkg/auditor/audit.go @@ -28,90 +28,9 @@ import ( "strings" "unsafe" - "github.com/coreos/go-systemd/v22/sdjournal" - "github.com/go-logr/logr" - varmorutils "github.com/bytedance/vArmor/pkg/utils" ) -type AaSeccompEventWriter struct { - auditor *Auditor - log logr.Logger -} - -func (writer *AaSeccompEventWriter) Write(p []byte) (int, error) { - event := string(p) - - // AppArmor audit event - if strings.Contains(event, "type=1400") || strings.Contains(event, "type=AVC") { - - if strings.Contains(event, "apparmor=\"DENIED\"") { - // Write violation event to log file - index := strings.Index(event, "type=1400 audit") - if index != -1 { - event = strings.Replace(event[index:], "type=1400 audit", "type=AVC msg=audit", 1) - } - - writer.log.V(3).Info("receive an AppArmor audit event", "event", strings.TrimSpace(event)) - - // Call parse_record() of libapparmor.so to parse the event, - // and convert it to AppArmorEvent object - e, err := writer.auditor.convertAppArmorEvent(event) - if err != nil { - writer.log.Error(err, "writer.auditor.convertAppArmorEvent() failed") - return len(p), nil - } - - // Try to read the process' mnt ns id from the proc filesystem. - // Note: - // This might fail if the process has already been destroyed. - // If so, we can't associate container information for violations. - var mntNsID uint32 - var ok bool - if mntNsID, ok = writer.auditor.mntNsIDCache[uint32(e.PID)]; !ok { - mntNsID, _ = varmorutils.ReadMntNsID(uint32(e.PID)) - } - - info := writer.auditor.containerCache[mntNsID] - writer.log.V(3).Info("audit event", - "container id", info.ContainerID, - "container name", info.ContainerName, - "pod name", info.PodName, - "pod namespace", info.PodNamespace, - "pod uid", info.PodUID, - "pid", e.PID, "time", int64(e.Epoch), "event", strings.TrimSpace(event)) - - writer.auditor.violationLogger.Warn(). - Str("nodeName", writer.auditor.nodeName). - Str("containerID", info.ContainerID). - Str("containerName", info.ContainerName). - Str("podName", info.PodName). - Str("podNamespace", info.PodNamespace). - Str("podUID", info.PodUID). - Uint32("pid", uint32(e.PID)). - Uint32("mntNsID", mntNsID). - Uint64("eventTimestamp", uint64(e.Epoch)). - Str("eventType", "AppArmor"). - Interface("event", e).Msg("violation event") - } else { - // Send behavior event to subscribers - for _, ch := range writer.auditor.auditEventChs { - ch <- event - } - } - } - - // Seccomp audit event - if strings.Contains(event, "type=1326") || strings.Contains(event, "type=SECCOMP") { - // Send behavior event to subscribers - for _, ch := range writer.auditor.auditEventChs { - ch <- event - } - } - - return len(p), nil -} - func (auditor *Auditor) convertAppArmorEvent(e string) (*AppArmorEvent, error) { msg := C.CString(e) defer C.free(unsafe.Pointer(msg)) @@ -171,17 +90,81 @@ func (auditor *Auditor) convertAppArmorEvent(e string) (*AppArmorEvent, error) { return &event, nil } -func (auditor *Auditor) readFromSystemdJournald() { - auditor.log.Info("start reading from systemd-journald") +func (auditor *Auditor) processAuditEvent(event string) { + // AppArmor audit event + if strings.Contains(event, "type=1400") || strings.Contains(event, "type=AVC") { + auditor.log.V(3).Info("receive an AppArmor audit event", "event", strings.TrimSpace(event)) + + if strings.Contains(event, "apparmor=\"DENIED\"") { + // Write violation event to log file + index := strings.Index(event, "type=1400 audit") + if index != -1 { + event = strings.Replace(event[index:], "type=1400 audit", "type=AVC msg=audit", 1) + } + + // Call parse_record() of libapparmor.so to parse the event, + // and convert it to AppArmorEvent object + e, err := auditor.convertAppArmorEvent(event) + if err != nil { + auditor.log.Error(err, "writer.auditor.convertAppArmorEvent() failed") + return + } + + // Try to read the process' mnt ns id from the proc filesystem. + // Note: + // This might fail if the process has already been destroyed. + // If so, we can't associate container information for violations. + var mntNsID uint32 + var ok bool + if mntNsID, ok = auditor.mntNsIDCache[uint32(e.PID)]; !ok { + mntNsID, _ = varmorutils.ReadMntNsID(uint32(e.PID)) + } + + info := auditor.containerCache[mntNsID] + auditor.log.V(3).Info("audit event", + "container id", info.ContainerID, + "container name", info.ContainerName, + "pod name", info.PodName, + "pod namespace", info.PodNamespace, + "pod uid", info.PodUID, + "pid", e.PID, "time", int64(e.Epoch), "event", strings.TrimSpace(event)) + + auditor.violationLogger.Warn(). + Str("nodeName", auditor.nodeName). + Str("containerID", info.ContainerID). + Str("containerName", info.ContainerName). + Str("podName", info.PodName). + Str("podNamespace", info.PodNamespace). + Str("podUID", info.PodUID). + Uint32("pid", uint32(e.PID)). + Uint32("mntNsID", mntNsID). + Uint64("eventTimestamp", uint64(e.Epoch)). + Str("eventType", "AppArmor"). + Interface("event", e).Msg("violation event") + } else { + // Send behavior event to subscribers + for _, ch := range auditor.auditEventChs { + ch <- event + } + } + } + + // Seccomp audit event + if strings.Contains(event, "type=1326") || strings.Contains(event, "type=SECCOMP") { + auditor.log.V(3).Info("receive a Seccomp audit event", "event", strings.TrimSpace(event)) - writer := &AaSeccompEventWriter{ - auditor: auditor, - log: auditor.log, + // Send behavior event to subscribers + for _, ch := range auditor.auditEventChs { + ch <- event + } } +} + +func (auditor *Auditor) readFromAuditLogFile() { + auditor.log.Info("start reading from ") - err := auditor.journalReader.Follow(auditor.journalReaderTimeout, writer) - if err != sdjournal.ErrExpired { - auditor.log.Error(err, "auditor.sdjournalReader.Follow()") + for line := range auditor.auditLogTail.Lines { + auditor.processAuditEvent(line.Text) } } diff --git a/pkg/auditor/auditor.go b/pkg/auditor/auditor.go index 8d17c6ea..6f113996 100644 --- a/pkg/auditor/auditor.go +++ b/pkg/auditor/auditor.go @@ -15,13 +15,15 @@ package audit import ( + "fmt" + "io" "os" "path/filepath" - "time" + "strings" "github.com/cilium/ebpf" - "github.com/coreos/go-systemd/v22/sdjournal" "github.com/go-logr/logr" + "github.com/nxadm/tail" "github.com/rs/zerolog" "gopkg.in/natefinch/lumberjack.v2" @@ -33,6 +35,7 @@ import ( const ( logDirectory = "/var/log/varmor" ratelimitSysctl = "/proc/sys/kernel/printk_ratelimit" + auditLogPaths = "/var/log/audit/audit.log|/var/log/kern.log" ) type Auditor struct { @@ -48,8 +51,8 @@ type Auditor struct { containerCache map[uint32]varmortypes.ContainerInfo // key: The mnt ns id of container, value: The container information auditEventChs map[string]chan<- string // auditEventChs used for sending apparmor & seccomp behavior event to subscribers bpfEventChs map[string]chan<- bpfenforcer.BpfEvent // bpfEventChs used for sending bpf behavior event to subscribers - journalReader *sdjournal.JournalReader - journalReaderTimeout chan time.Time + auditLogPath string + auditLogTail *tail.Tail savedRateLimit uint64 auditRbMap *ebpf.Map capabilityMap map[uint32]string @@ -82,21 +85,30 @@ func NewAuditor(nodeName string, appArmorSupported, bpfLsmSupported, enableBehav log: log, } - // Create a systemd-journald reader to read the kernel events + // Create a tail reader to read the audit events if appArmorSupported || enableBehaviorModeling { - r, err := sdjournal.NewJournalReader(sdjournal.JournalReaderConfig{ - Since: time.Duration(-5) * time.Second, - Matches: []sdjournal.Match{ - { - Field: sdjournal.SD_JOURNAL_FIELD_TRANSPORT, - Value: "kernel", - }, - }}) + for _, path := range strings.Split(auditLogPaths, "|") { + _, err := os.Stat(path) + if err == nil { + auditor.auditLogPath = path + break + } + } + if auditor.auditLogPath == "" { + return nil, fmt.Errorf("please specify the correct file path that stores the audit logs for AppArmor and Seccomp") + } + t, err := tail.TailFile(auditor.auditLogPath, + tail.Config{ + Location: &tail.SeekInfo{Offset: 0, Whence: io.SeekEnd}, + ReOpen: true, + Follow: true, + CompleteLines: true, + }) if err != nil { return nil, err } - auditor.journalReader = r - auditor.journalReaderTimeout = make(chan time.Time) + auditor.auditLogTail = t + auditor.log.Info("start tailing audit log", "path", auditor.auditLogPath) } // Load the ringbuf map of BPF enforcer @@ -198,7 +210,7 @@ func (auditor *Auditor) DeleteBehaviorEventNotifyCh(subscriber string) { func (auditor *Auditor) Run(stopCh <-chan struct{}) { if auditor.appArmorSupported || auditor.enableBehaviorModeling { - go auditor.readFromSystemdJournald() + go auditor.readFromAuditLogFile() } if auditor.bpfLsmSupported { go auditor.readFromAuditEventRingBuf() @@ -208,8 +220,8 @@ func (auditor *Auditor) Run(stopCh <-chan struct{}) { func (auditor *Auditor) Close() { if auditor.appArmorSupported || auditor.enableBehaviorModeling { - auditor.journalReaderTimeout <- time.Now() - auditor.journalReader.Close() + auditor.auditLogTail.Stop() + auditor.auditLogTail.Cleanup() } if auditor.bpfLsmSupported { auditor.auditRbMap.Close() diff --git a/pkg/auditor/auditor_test.go b/pkg/auditor/auditor_test.go index fec4c67d..7d701264 100644 --- a/pkg/auditor/auditor_test.go +++ b/pkg/auditor/auditor_test.go @@ -27,7 +27,7 @@ func Test_SystemdJournald(t *testing.T) { c := textlogger.NewConfig() log.SetLogger(textlogger.NewLogger(c)) - a, err := NewAuditor("test", true, false, true, log.Log.WithName("AUDIT-VIOLATIONS")) + a, err := NewAuditor("test", true, false, true, log.Log.WithName("AUDITOR")) assert.NilError(t, err) syncCh := make(chan struct{}, 1) From d168ee923c18b52f850ba400034806321cdf87a2 Mon Sep 17 00:00:00 2001 From: Danny__Wei Date: Fri, 8 Nov 2024 16:47:37 +0800 Subject: [PATCH 3/5] feat: Pass the list of audit log files from the command line --- cmd/varmor/main.go | 3 +++ internal/agent/agent.go | 5 ++++- pkg/auditor/auditor.go | 5 ++--- pkg/auditor/auditor_test.go | 2 +- 4 files changed, 10 insertions(+), 5 deletions(-) diff --git a/cmd/varmor/main.go b/cmd/varmor/main.go index 932020c7..266ad7e3 100644 --- a/cmd/varmor/main.go +++ b/cmd/varmor/main.go @@ -64,6 +64,7 @@ var ( webhookMatchLabel string bpfExclusiveMode bool statusUpdateCycle time.Duration + auditLogPaths string setupLog = log.Log.WithName("SETUP") ) @@ -86,6 +87,7 @@ func main() { flag.StringVar(&webhookMatchLabel, "webhookMatchLabel", "sandbox.varmor.org/enable=true", "Configure the matchLabel of webhook configuration, the valid format is key=value or nil") flag.BoolVar(&bpfExclusiveMode, "bpfExclusiveMode", false, "Set this flag to enable exclusive mode for the BPF enforcer. It will disable the AppArmor confinement when using the BPF enforcer.") flag.DurationVar(&statusUpdateCycle, "statusUpdateCycle", time.Hour*2, "Configure the status update cycle for VarmorPolicy and ArmorProfile") + flag.StringVar(&auditLogPaths, "auditLogPaths", "/var/log/audit/audit.log|/var/log/kern.log", "Configure the file search list to select the audit log file and read the AppArmor and Seccomp audit events. Please use a vertical bar to separate the file paths, the first valid file will be used to track the audit events.") flag.Parse() // Set the webhook matchLabels configuration. @@ -157,6 +159,7 @@ func main() { managerIP, config.StatusServicePort, config.ClassifierServicePort, + auditLogPaths, stopCh, log.Log.WithName("AGENT"), ) diff --git a/internal/agent/agent.go b/internal/agent/agent.go index e49d1ad8..ed7b7ab3 100644 --- a/internal/agent/agent.go +++ b/internal/agent/agent.go @@ -101,6 +101,7 @@ func NewAgent( managerIP string, managerPort int, classifierPort int, + auditLogPaths string, stopCh <-chan struct{}, log logr.Logger) (*Agent, error) { @@ -238,7 +239,9 @@ func NewAgent( } // Create an auditor to audit violation and behavior events for AppArmor, Seccomp and BPF enforcers - agent.auditor, err = varmorauditor.NewAuditor(agent.nodeName, agent.appArmorSupported, agent.bpfLsmSupported, agent.enableBehaviorModeling, log.WithName("AUDITOR")) + agent.auditor, err = varmorauditor.NewAuditor(agent.nodeName, + agent.appArmorSupported, agent.bpfLsmSupported, agent.enableBehaviorModeling, + auditLogPaths, log.WithName("AUDITOR")) if err != nil { return nil, err } diff --git a/pkg/auditor/auditor.go b/pkg/auditor/auditor.go index 6f113996..56a9e396 100644 --- a/pkg/auditor/auditor.go +++ b/pkg/auditor/auditor.go @@ -35,7 +35,6 @@ import ( const ( logDirectory = "/var/log/varmor" ratelimitSysctl = "/proc/sys/kernel/printk_ratelimit" - auditLogPaths = "/var/log/audit/audit.log|/var/log/kern.log" ) type Auditor struct { @@ -64,7 +63,7 @@ type Auditor struct { } // NewAuditor creates an auditor to audit the violations of target containers -func NewAuditor(nodeName string, appArmorSupported, bpfLsmSupported, enableBehaviorModeling bool, log logr.Logger) (*Auditor, error) { +func NewAuditor(nodeName string, appArmorSupported, bpfLsmSupported, enableBehaviorModeling bool, auditLogPaths string, log logr.Logger) (*Auditor, error) { auditor := Auditor{ nodeName: nodeName, appArmorSupported: appArmorSupported, @@ -95,7 +94,7 @@ func NewAuditor(nodeName string, appArmorSupported, bpfLsmSupported, enableBehav } } if auditor.auditLogPath == "" { - return nil, fmt.Errorf("please specify the correct file path that stores the audit logs for AppArmor and Seccomp") + return nil, fmt.Errorf("please use --auditLogPaths command line parameter to specify the correct file paths that stores the audit logs for AppArmor and Seccomp") } t, err := tail.TailFile(auditor.auditLogPath, tail.Config{ diff --git a/pkg/auditor/auditor_test.go b/pkg/auditor/auditor_test.go index 7d701264..ccd90943 100644 --- a/pkg/auditor/auditor_test.go +++ b/pkg/auditor/auditor_test.go @@ -27,7 +27,7 @@ func Test_SystemdJournald(t *testing.T) { c := textlogger.NewConfig() log.SetLogger(textlogger.NewLogger(c)) - a, err := NewAuditor("test", true, false, true, log.Log.WithName("AUDITOR")) + a, err := NewAuditor("test", true, false, true, "/var/log/audit/audit.log|/var/log/kern.log", log.Log.WithName("AUDITOR")) assert.NilError(t, err) syncCh := make(chan struct{}, 1) From ad98ad83bb1e601d1a4d9f5123535581012083f8 Mon Sep 17 00:00:00 2001 From: Danny__Wei Date: Fri, 8 Nov 2024 17:09:41 +0800 Subject: [PATCH 4/5] docs: Add configuration instructions for the `--auditLogPaths` option --- docs/installation.md | 1 + docs/installation.zh_CN.md | 1 + docs/interface_specification.md | 2 +- docs/interface_specification.zh_CN.md | 2 +- website/docs/getting_started/installation.md | 1 + website/docs/getting_started/interface_specification.md | 2 +- 6 files changed, 6 insertions(+), 3 deletions(-) diff --git a/docs/installation.md b/docs/installation.md index eaff39ba..9809a856 100644 --- a/docs/installation.md +++ b/docs/installation.md @@ -45,6 +45,7 @@ vArmor allows you to configure its functionality during installation using the h | `--set removeAllSeccompProfiles.enabled=true` | Default: disabled. When enabled, all Seccomp profiles created by vArmor will be unloaded when the Agent exits. | `--set "manager.args={--webhookMatchLabel=KEY=VALUE}"` | The default value is: `sandbox.varmor.org/enable=true`. vArmor will only enable sandbox protection for Workloads that contain this label. You can disable this feature by using `--set 'manager.args={--webhookMatchLabel=}'`. | `--set behaviorModeling.enabled=true` | Default: disabled. Experimental feature. Currently, only the AppArmor/Seccomp enforcer supports the BehaviorModeling mode. Please refer to the [BehaviorModeling Mode](behavior_modeling.md) for more details. +| `--set "agent.args={--auditLogPaths=FILE_PATH\|FILE_PATH}"` | Default: `/var/log/audit/audit.log\|/var/log/kern.log`. vArmor sequentially searches audit log files and monitors the first valid file to consume AppArmor and Seccomp audit events for violation auditing and behavioral modeling. Please use a vertical bar to separate file paths. ## Upgrade diff --git a/docs/installation.zh_CN.md b/docs/installation.zh_CN.md index 309c5852..7dd6d6db 100644 --- a/docs/installation.zh_CN.md +++ b/docs/installation.zh_CN.md @@ -41,6 +41,7 @@ helm install varmor varmor-0.5.11.tgz \ | `--set removeAllSeccompProfiles.enabled=true` | 默认关闭；开启后，Agent 退出时，将会删除所有由 vArmor 创建的 Seccomp Profile。 | `--set "manager.args={--webhookMatchLabel=KEY=VALUE}"` | 默认值为：`sandbox.varmor.org/enable=true`。vArmor 只会对包含此 label 的 Workloads 开启沙箱防护。你可以使用 `--set 'manager.args={--webhookMatchLabel=}'` 关闭此特性。 | `--set behaviorModeling.enabled=true` | 默认关闭；此为实验功能，仅 AppArmor/Seccomp enforcer 支持 BehaviorModeling 模式。请参见 [The BehaviorModeling Mode](behavior_modeling.md)。 +| `--set "agent.args={--auditLogPaths=FILE_PATH\|FILE_PATH}"` | 默认值为：`/var/log/audit/audit.log\|/var/log/kern.log`。vArmor 会按顺序搜索审计日志文件，并监控第一个有效的文件来消费 AppArmor 和 Seccomp 的审计事件，用于违规审计和行为建模。请使用`|`分隔文件路径。 ## 更新 diff --git a/docs/interface_specification.md b/docs/interface_specification.md index def0ed37..f6bb8d25 100644 --- a/docs/interface_specification.md +++ b/docs/interface_specification.md @@ -19,7 +19,7 @@ English | [简体中文](interface_specification.zh_CN.md) | ||bpfRawRules
*[BpfRawRules](interface_specification.md#bpfrawrules)*|Optional. BpfRawRules is used to set custom BPF rules. | ||syscallRawRules
*[LinuxSyscall](https://pkg.go.dev/github.com/opencontainers/runtime-spec@v1.1.0/specs-go#LinuxSyscall) array*|Optional. SyscallRawRules is used to set the custom syscalls blocklist rules with Seccomp enforcer. | ||privileged
*bool*|Optional. Privileged is used to identify whether the policy is for the privileged container. If set to `nil` or `false`, vArmor will build AppArmor or BPF profiles on top of the **RuntimeDefault** mode. Otherwise, it will build AppArmor or BPF profiles on top of the **AlwaysAllow** mode. (Default: false)

Note: If set to `true`, vArmor will not build Seccomp profile for the target workloads. -| ||auditViolations
*bool*|Optional. AuditViolations determines whether to audit the actions that violate the mandatory access control rules. Currently, this feature supports AppArmor and BPF enforcers. Any detected violation will be logged to `/var/log/varmor/violations.log` file in the host. (Default: false) +| ||auditViolations
*bool*|Optional. AuditViolations determines whether to audit the actions that violate the mandatory access control rules. Currently, this feature supports AppArmor and BPF enforcers. Any detected violation will be logged to `/var/log/varmor/violations.log` file in the host. (Default: false) | |modelingOptions|duration
*int*|[Experimental] Duration is the duration in minutes to modeling. |updateExistingWorkloads
*bool*|-|-|Optional. UpdateExistingWorkloads is used to indicate whether to perform a rolling update on target existing workloads, thus enabling or disabling the protection of the target workloads when policies are created or deleted. (Default: false)

Note: vArmor only performs a rolling update on Deployment, StatefulSet, or DaemonSet type workloads. If `.spec.target.kind` is Pod, you need to rebuild the Pod yourself to enable or disable protection. | ||PLACEHOLDER_PLACEHOD| diff --git a/docs/interface_specification.zh_CN.md b/docs/interface_specification.zh_CN.md index 7127ade6..d2ceb837 100644 --- a/docs/interface_specification.zh_CN.md +++ b/docs/interface_specification.zh_CN.md @@ -18,7 +18,7 @@ | ||bpfRawRules
*[BpfRawRules](interface_specification.zh_CN.md#bpfrawrules)*|可选字段，用于支持用户设置自定义的 BPF 黑名单规则。 | ||syscallRawRules
*[LinuxSyscall](https://pkg.go.dev/github.com/opencontainers/runtime-spec@v1.1.0/specs-go#LinuxSyscall) array*|可选字段，用于支持用户使用 Seccomp enforcer 设置自定义的 Syscall 黑名单规则。 | ||privileged
*bool*|可选字段，若要对特权容器进行加固，请务必将此值设置为 true。若为 `false`，将在 **RuntimeDefault** 模式的基础上构造 AppArmor/BPF Profiles。若为 `ture`，则在 **AlwaysAllow** 模式的基础上构造 AppArmor/BPF Profiles。

注意：当为 `true` 时，vArmor 不会为目标构造 Seccomp Profiles。（默认值：false） -| ||auditViolations
*bool*|可选字段. 用于审计违反沙箱策略的行为。此特性当前支持 AppArmor 和 BPF enforcers，任何违反沙箱策略的行为都会被记录到宿主机的 `/var/log/varmor/violations.log` 文件中。（默认值：false） +| ||auditViolations
*bool*|可选字段. 用于审计违反沙箱策略的行为。此特性当前支持 AppArmor 和 BPF enforcers，任何违反沙箱策略的行为都会被记录到宿主机的 `/var/log/varmor/violations.log` 文件中。（默认值：false） | |modelingOptions|duration
*int*|动态建模的时间。（单位：分钟）[实验功能] |updateExistingWorkloads
*bool*|-|-|可选字段，用于指定是否对符合条件的工作负载进行滚动更新，从而在 Policy 创建或删除时，对目标工作负载开启或关闭防护。（默认值：false）

注意：vArmor 只会对 Deployment, StatefulSet, or DaemonSet 类型的工作负载进行滚动更新，如果 `.spec.target.kind` 为 Pod，需要您自行重建 Pod 来开启或关闭防护。 | ||PLACEHOLDER_PLACEHOLD| diff --git a/website/docs/getting_started/installation.md b/website/docs/getting_started/installation.md index 8669043e..a9b8bde2 100644 --- a/website/docs/getting_started/installation.md +++ b/website/docs/getting_started/installation.md @@ -48,6 +48,7 @@ vArmor allows you to configure its functionality during installation using the h | `--set removeAllSeccompProfiles.enabled=true` | Default: disabled. When enabled, all Seccomp profiles created by vArmor will be unloaded when the Agent exits. | `--set "manager.args={--webhookMatchLabel=KEY=VALUE}"` | The default value is: `sandbox.varmor.org/enable=true`. vArmor will only enable sandbox protection for Workloads that contain this label. You can disable this feature by using `--set 'manager.args={--webhookMatchLabel=}'`. | `--set behaviorModeling.enabled=true` | Default: disabled. Experimental feature. Currently, only the AppArmor/Seccomp enforcer supports the BehaviorModeling mode. Please refer to the [BehaviorModeling Mode](behavior_modeling.md) for more details. +| `--set "agent.args={--auditLogPaths=FILE_PATH\|FILE_PATH}"` | Default: `/var/log/audit/audit.log\|/var/log/kern.log`. vArmor sequentially searches audit log files and monitors the first valid file to consume AppArmor and Seccomp audit events for violation auditing and behavioral modeling. Please use a vertical bar to separate file paths. ## Upgrade You can use helm commands to upgrade, rollback, and perform other operations. diff --git a/website/docs/getting_started/interface_specification.md b/website/docs/getting_started/interface_specification.md index edc3fe49..e7da58ce 100644 --- a/website/docs/getting_started/interface_specification.md +++ b/website/docs/getting_started/interface_specification.md @@ -22,7 +22,7 @@ description: The interface specification of vArmor. | ||bpfRawRules
*[BpfRawRules](interface_instructions#bpfrawrules) array*|Optional. BpfRawRules is used to set custom BPF rules. | ||syscallRawRules
*[LinuxSyscall](https://pkg.go.dev/github.com/opencontainers/runtime-spec@v1.1.0/specs-go#LinuxSyscall) array*|Optional. SyscallRawRules is used to set the custom syscalls blocklist rules with Seccomp enforcer. Please refer to [this document](https://github.com/opencontainers/runtime-spec/blob/main/config-linux.md#seccomp) to create custom rules. | ||privileged
*bool*|Optional. Privileged is used to identify whether the policy is for the privileged container. If set to `nil` or `false`, vArmor will build AppArmor or BPF profiles on top of the **RuntimeDefault** mode. Otherwise, it will build AppArmor or BPF profiles on top of the **AlwaysAllow** mode. (Default: false)

Note: If set to `true`, vArmor will not build Seccomp profile for the target workloads. -| ||auditViolations
*bool*|Optional. AuditViolations determines whether to audit the actions that violate the mandatory access control rules. Currently, this feature supports only the AppArmor enforcer. Any detected violation will be logged to the system's audit file. If you are using syslog or rsyslog, the default log path is `/var/log/kern.log`. (Default: false) +| ||auditViolations
*bool*|Optional. AuditViolations determines whether to audit the actions that violate the mandatory access control rules. Currently, this feature supports AppArmor and BPF enforcers. Any detected violation will be logged to `/var/log/varmor/violations.log` file in the host. (Default: false) | |modelingOptions|duration
*int*|[Experimental] Duration is the duration in minutes to modeling. |updateExistingWorkloads
*bool*|-|-|Optional. UpdateExistingWorkloads is used to indicate whether to perform a rolling update on target existing workloads, thus enabling or disabling the protection of the target workloads when policies are created or deleted. (Default: false)

Note: vArmor only performs a rolling update on Deployment, StatefulSet, or DaemonSet type workloads. If `.spec.target.kind` is Pod, you need to rebuild the Pod yourself to enable or disable protection. | ||PLACEHOLDER_PLACEHOD| From 7365573b6423575dbc27ee736c4a32565a46e824 Mon Sep 17 00:00:00 2001 From: Danny__Wei Date: Fri, 8 Nov 2024 17:16:04 +0800 Subject: [PATCH 5/5] docs: Fix typo --- README.ja.md | 8 +-- README.md | 4 +- README.zh_CN.md | 4 +- docs/built_in_rules.md | 82 ++++++++++++------------- docs/built_in_rules.zh_CN.md | 82 ++++++++++++------------- docs/custom_rules.zh_CN.md | 8 +-- docs/installation.zh_CN.md | 4 +- docs/interface_specification.md | 58 ++++++++--------- docs/interface_specification.zh_CN.md | 58 ++++++++--------- docs/performance_specification.md | 2 +- docs/performance_specification.zh_CN.md | 10 +-- docs/usage_instructions.zh_CN.md | 10 +-- 12 files changed, 165 insertions(+), 165 deletions(-) diff --git a/README.ja.md b/README.ja.md index a27ee27a..ab6d1d3a 100644 --- a/README.ja.md +++ b/README.ja.md @@ -4,7 +4,7 @@ Logo -
+
![BHArsenalUSA2024](docs/img/BlackHat-Arsenal-USA-2024.svg) [![Go Report Card](https://goreportcard.com/badge/github.com/bytedance/vArmor)](https://goreportcard.com/report/github.com/bytedance/vArmor) @@ -42,8 +42,8 @@ vArmorは、ByteDanceのエンドポイントセキュリティ部門の**Elkeid |エンフォーサー|要件|推奨| |------------|--------------------------------------------|--------| -|AppArmor |1. Linux Kernel 4.15以上
2. AppArmor LSMが有効化されていること|GKE with Container-Optimized OS
AKS with Ubuntu 22.04 LTS
[VKE](https://www.volcengine.com/product/vke) with veLinux 1.0
Debian 10以上
Ubuntu 18.04.0 LTS以上
[veLinux 1.0](https://www.volcengine.com/docs/6396/74967)など| -|BPF |1. Linux Kernel 5.10以上 (x86_64)
2. containerd v1.6.0以上
3. BPF LSMが有効化されていること|EKS with Amazon Linux 2
GKE with Container-Optimized OS
[VKE](https://www.volcengine.com/product/vke) with veLinux 1.0 (with 5.10 kernel)
AKS with Ubuntu 22.04 LTS \*
ACK with Alibaba Cloud Linux 3 \*
OpenSUSE 15.4 \*
Debian 11 \*
Fedora 37
[veLinux 1.0 with 5.10 kernel](https://www.volcengine.com/docs/6396/74967)など

* *BPF LSMの手動有効化が必要です*| +|AppArmor |1. Linux Kernel 4.15以上
2. AppArmor LSMが有効化されていること|GKE with Container-Optimized OS
AKS with Ubuntu 22.04 LTS
[VKE](https://www.volcengine.com/product/vke) with veLinux 1.0
Debian 10以上
Ubuntu 18.04.0 LTS以上
[veLinux 1.0](https://www.volcengine.com/docs/6396/74967)など| +|BPF |1. Linux Kernel 5.10以上 (x86_64)
2. containerd v1.6.0以上
3. BPF LSMが有効化されていること|EKS with Amazon Linux 2
GKE with Container-Optimized OS
[VKE](https://www.volcengine.com/product/vke) with veLinux 1.0 (with 5.10 kernel)
AKS with Ubuntu 22.04 LTS \*
ACK with Alibaba Cloud Linux 3 \*
OpenSUSE 15.4 \*
Debian 11 \*
Fedora 37
[veLinux 1.0 with 5.10 kernel](https://www.volcengine.com/docs/6396/74967)など

* *BPF LSMの手動有効化が必要です*| |Seccomp |1. Kubernetes v1.19以上|すべてのLinuxディストリビューション| ## ポリシーモードと組み込みルール @@ -123,7 +123,7 @@ vArmorは、eBPFプログラムを管理および操作するために[cilium/eb vArmorは、[Nirmata](https://nirmata.com/)によって開発された[kyverno](https://github.com/kyverno/kyverno)の一部のコードを参照しています。 ## デモ -以下は、vArmorを使用してDeploymentを強化し、CVE-2021-22555に対抗するデモンストレーションです。（エクスプロイトは[cve-2021-22555](https://github.com/google/security-research/tree/master/pocs/linux/cve-2021-22555)から変更されています）
+以下は、vArmorを使用してDeploymentを強化し、CVE-2021-22555に対抗するデモンストレーションです。（エクスプロイトは[cve-2021-22555](https://github.com/google/security-research/tree/master/pocs/linux/cve-2021-22555)から変更されています）
![image](test/demos/CVE-2021-22555/demo.gif) ## 404Starlink diff --git a/README.md b/README.md index e1b0e36f..dc7dd95e 100644 --- a/README.md +++ b/README.md @@ -4,7 +4,7 @@ Logo -
+
![BHArsenalUSA2024](docs/img/BlackHat-Arsenal-USA-2024.svg) [![Go Report Card](https://goreportcard.com/badge/github.com/bytedance/vArmor)](https://goreportcard.com/report/github.com/bytedance/vArmor) @@ -74,7 +74,7 @@ vArmor references part of the code of [kyverno](https://github.com/kyverno/kyver ## Demo -Below is a demonstration of using vArmor to harden a Deployment and defend against CVE-2021-22555. (The exploit is modified from [cve-2021-22555](https://github.com/google/security-research/tree/master/pocs/linux/cve-2021-22555))
+Below is a demonstration of using vArmor to harden a Deployment and defend against CVE-2021-22555. (The exploit is modified from [cve-2021-22555](https://github.com/google/security-research/tree/master/pocs/linux/cve-2021-22555))
![image](test/demos/CVE-2021-22555/demo.gif) diff --git a/README.zh_CN.md b/README.zh_CN.md index 25d93683..560ef05d 100644 --- a/README.zh_CN.md +++ b/README.zh_CN.md @@ -4,7 +4,7 @@ Logo -
+
![BHArsenalUSA2024](docs/img/BlackHat-Arsenal-USA-2024.svg) [![Go Report Card](https://goreportcard.com/badge/github.com/bytedance/vArmor)](https://goreportcard.com/report/github.com/bytedance/vArmor) @@ -74,7 +74,7 @@ vArmor 在研发初期参考了 [Nirmata](https://nirmata.com/) 开发的 [kyver ## 演示 -下面是一个使用 vArmor 对 Deployment 进行加固，防御 CVE-2021-22555 攻击的演示（Exploit 修改自 [cve-2021-22555](https://github.com/google/security-research/tree/master/pocs/linux/cve-2021-22555)）。
+下面是一个使用 vArmor 对 Deployment 进行加固，防御 CVE-2021-22555 攻击的演示（Exploit 修改自 [cve-2021-22555](https://github.com/google/security-research/tree/master/pocs/linux/cve-2021-22555)）。
![image](test/demos/CVE-2021-22555/demo.zh_CN.gif) diff --git a/docs/built_in_rules.md b/docs/built_in_rules.md index e19339e6..2ffaac6a 100644 --- a/docs/built_in_rules.md +++ b/docs/built_in_rules.md @@ -10,55 +10,55 @@ The modes can be specified through the `spec.policy.mode` field of [VarmorPolicy |-----------|--------|---|-------|-----------| |AlwaysAllow|✔|✔|✔|No mandatory access control rules are imposed on container. |RuntimeDefault|✔|✔|✔|Basic protection is provided using the same default policy as the container runtime components (such as containerd's [cri-containerd.apparmor.d](https://github.com/containerd/containerd/blob/main/contrib/apparmor/template.go)). -|EnhanceProtect|✔|✔|✔|- It offers 5 types of [built-in rules](built_in_rules.md#the-built-in-rules) and custom interfaces to meet various protection requirements.
- Enhanced protection is based on the RuntimeDefault mode by default. (The `spec.policy.privileged` field is `nil` or `false`)
- Also supports enhanced protection on the basis of the AlwaysAllow mode. (The `spec.policy.privileged` field is `true`) -|BehaviorModeling|✔|🏗️|✔|- Utilize BPF and Audit technologies to perform behavior modeling on multiple workloads.
- The behavior model will be stored in the corresponding [ArmorProfileModel](../apis/varmor/v1beta1/armorprofilemodel_types.go) object.
- Dynamic switching mode is not supported.
- Please refer to the [BehaviorModeling Mode](behavior_modeling.md) for more details. +|EnhanceProtect|✔|✔|✔|- It offers 5 types of [built-in rules](built_in_rules.md#the-built-in-rules) and custom interfaces to meet various protection requirements.
- Enhanced protection is based on the RuntimeDefault mode by default. (The `spec.policy.privileged` field is `nil` or `false`)
- Also supports enhanced protection on the basis of the AlwaysAllow mode. (The `spec.policy.privileged` field is `true`) +|BehaviorModeling|✔|🏗️|✔|- Utilize BPF and Audit technologies to perform behavior modeling on multiple workloads.
- The behavior model will be stored in the corresponding [ArmorProfileModel](../apis/varmor/v1beta1/armorprofilemodel_types.go) object.
- Dynamic switching mode is not supported.
- Please refer to the [BehaviorModeling Mode](behavior_modeling.md) for more details. |DefenseInDepth|✔||✔|Protect the workloads based on the [ArmorProfileModel](../apis/varmor/v1beta1/armorprofilemodel_types.go) object. -Note:
- vArmor policy supports dynamic switching of running modes (limited to AlwaysAllow, EnhanceProtect, RuntimeDefault, DefenseInDepth) and updating sandbox rules without having to restart the workloads. However, when using the **Seccomp enforcer**, the workload must be restarted for changes to the **Seccomp Profile** to take effect.
- vArmor supports modifying policies to add new enforcers, but does not support removing enforcers that have been set. In addition, newly added enforcers only take effect for newly created Workloads. +Note:
- vArmor policy supports dynamic switching of running modes (limited to AlwaysAllow, EnhanceProtect, RuntimeDefault, DefenseInDepth) and updating sandbox rules without having to restart the workloads. However, when using the **Seccomp enforcer**, the workload must be restarted for changes to the **Seccomp Profile** to take effect.
- vArmor supports modifying policies to add new enforcers, but does not support removing enforcers that have been set. In addition, newly added enforcers only take effect for newly created Workloads. ## The Built-in Rules **vArmor** supports defining protection policies ([VarmorPolicy](usage_instructions.md#varmorpolicy)/[VarmorClusterPolicy](usage_instructions.md#varmorclusterpolicy)) using built-in rules and custom interfaces in **EnhanceProtect** mode. The currently supported built-in rules and categories are shown in the following table. You can try using the [policy advisor](../tools/policy-advisor/README.md) to generate a policy template with built-in rules. -Note:
- The built-in rules and syntax supported by different enforcers are still under development.
- There are some limitations in the rules and syntax supported by different enforcers. For example, the AppArmor enforcer does not support fine-grained network access control, and BPF does not support access control for specified executables.
+Note:
- The built-in rules and syntax supported by different enforcers are still under development.
- There are some limitations in the rules and syntax supported by different enforcers. For example, the AppArmor enforcer does not support fine-grained network access control, and BPF does not support access control for specified executables.
| Category | Subcategory | Rule Name & ID | Applicable Container | Description | Principle & Impact | Supported Enforcer | |----------|-------------|----------------|----------------------|-------------|--------------------|--------------------| -|**Hardening**|Securing Privileged Containers|Prohibit modifying procfs' core_pattern

`disallow-write-core-pattern`|Privileged|Attackers may attempt container escape by modifying the procfs core_pattern in a **privileged container** or, in a container (**w/ CAP_SYS_ADMIN**), unmounting specific mount points and then modifying the procfs core_pattern to execute a container escape.|Disallow writing to the procfs' core_pattern file.|AppArmor
BPF -| | |Prohibit mounting securityfs

`disallow-mount-securityfs`|Privileged|Attackers may attempt container escape in containers (**w/ CAP_SYS_ADMIN**) by mounting securityfs with read-write permissions and subsequently modifying it.|Disallow mounting of new security file systems.|AppArmor
BPF -| | |Prohibit remounting procfs

`disallow-mount-procfs`|Privileged|Attackers may attempt container escape in containers (**w/ CAP_SYS_ADMIN**) by remounting procfs with read-write permissions and subsequently modifying the core_pattern, among other things.|1. Disallow mounting of new proc file systems.

2. Prohibit using bind, rbind, move, remount options to remount `/proc**`.

3. When using BPF enforcer, it also prevents unmounting `/proc**`.|AppArmor
BPF -| | |Prohibit modifying cgroupfs' release_agent

`disallow-write-release-agent`|Privileged|Attackers may attempt container escape within **privileged container** by directly modifying the cgroupfs release_agent.|Disallow writing to the cgroupfs' release_agent file.|AppArmor
BPF -| | |Prohibit remounting cgroupfs

`disallow-mount-cgroupfs`|Privileged|Attackers may attempt to escape from containers (**w/ CAP_SYS_ADMIN**) by remounting cgroupfs with read-write permissions. Subsequently, they can modify release_agent and device access permissions, among other things.|1. Disallow mounting new cgroup file systems.

2. Prohibit using bind, rbind, move, remount options to remount `/sys/fs/cgroup**`.

3. Prohibit using rbind option to remount `/sys**`.

4. When using BPF enforcer, it also prevents unmounting `/sys**`.|AppArmor
BPF -| | |Prohibit debugging of disk devices

`disallow-debug-disk-device`|Privileged|Attackers may attempt to read and write host machine files by debugging host machine disk devices within a **privileged container**.

It is recommended to use this rule in conjunction with `disable_cap_mknod` to prevent attackers from bypassing the rule with mknod.|Dynamically acquire host disk devices and restrict container access them with read-write permissions.|AppArmor
BPF -| | |Prohibit mounting of host's disk devices

`disallow-mount-disk-device`|Privileged|Attackers may attempt to mount host machine disk devices within a **privileged container**, thereby gaining read-write access to host machine files.

It is recommended to use this rule in conjunction with `disable_cap_mknod` to prevent attackers from bypassing the rule with mknod.|Dynamically acquire host machine disk device files and prevent mounting within containers.|AppArmor
BPF -| | |Disable the mount system call

`disallow-mount`|Privileged|[MOUNT(2)](https://man7.org/linux/man-pages/man2/mount.2.html) is often used for privilege escalation, container escapes, and other attacks. Most microservices applications do not require mount operations. Therefore, it is recommended to use this rule to restrict container processes from using the `mount()` system call.

Note: The mount system call will be disabled by default if the `spec.policy.privileged` field is false.|Disable the mount system call.|AppArmor
BPF -| | |Disable the umount system call

`disallow-umount`|ALL|[UMOUNT(2)](https://man7.org/linux/man-pages/man2/umount.2.html) can be used to remove the attachment of topmost mount points(such as maskedPaths), leading to privilege escalation and information disclosure. Most microservices applications do not require umount operations. Therefore, it is recommended to use this rule to restrict container processes from using the `umount()` system call.|Disable the umount system call.|AppArmor
BPF -| | |Prohibit loading kernel modules

`disallow-insmod`|Privileged|Attackers may attempt to inject code into the kernel within a container (**w/ CAP_SYS_MODULE**) by executing kernel module loading command.|Disable CAP_SYS_MODULE|AppArmor
BPF -| | |Prohibit loading eBPF programs

`disallow-load-ebpf`|ALL|Attackers may load eBPF programs within a container (**w/ CAP_SYS_ADMIN & CAP_BPF**) to theft data or create rootkit.

Note: CAP_BPF was introduced starting from Linux 5.8.|Disable CAP_SYS_ADMIN & CAP_BPF|AppArmor
BPF -| | |Prohibit accessing process's root directory

`disallow-access-procfs-root`|ALL|This policy prohibits processes within containers from accessing the root directory of the process filesystem (i.e., /proc/[PID]/root), preventing attackers from exploiting shared PID namespaces to launch attacks.

Attackers may attempt to access the process filesystem outside the container by reading and writing to /proc/*/root in environments where the PID namespace is shared with the host or other containers. This could lead to information disclosure, privilege escalation, lateral movement, and other attacks.|Disable PTRACE_MODE_READ permission |AppArmor
BPF -| | |Prohibit accessing kernel exported symbol

`disallow-access-kallsyms`|ALL|Attackers may attempt to leak the base address of kernel modules from containers (**w/ CAP_SYSLOG**) by reading the kernel's exported symbol definitions file. This assists attackers in bypassing KASLR protection to exploit kernel vulnerabilities more easily.|Disallow reading /proc/kallsyms file|AppArmor
BPF -| |Disable Capabilities|Disable all capabilities

`disable-cap-all`|ALL|Disable all capabilities|-|AppArmor
BPF -| | |Disable all capabilities except for NET_BIND_SERVICE

`disable-cap-all-except-net-bind-service`|ALL|Disable all capabilities except for NET_BIND_SERVICE.

This rule complies with the [*Restricted Policy*](https://kubernetes.io/docs/concepts/security/pod-security-standards/#restricted) of the Pod Security Standards.|-|AppArmor
BPF -| | |Disable privileged capabilities

`disable-cap-privileged`|ALL|Disable all privileged capabilities (those that can directly lead to escapes or affect host availability). Only allow the [default capabilities](https://github.com/containerd/containerd/blob/release/1.7/oci/spec.go#L115).

This rule complies with the [*Baseline Policy*](https://kubernetes.io/docs/concepts/security/pod-security-standards/#restricted) of the Pod Security Standards, except for the net_raw capability.|-|AppArmor
BPF -| | |Disable specified capability

`disable-cap-XXXX`|ALL|Disable any specified capabilities, replacing XXXX with the values from 'capabilities(7),' for example, disable-cap-net-raw.|-|AppArmor
BPF -| |Blocking Exploit Vectors|Prohibit abusing user namespaces

`disallow-abuse-user-ns`|ALL|User namespaces can be used to enhance container isolation. However, it also increases the kernel's attack surface, making certain kernel vulnerabilities easier to exploit. Attackers can use a container to create a user namespace, gaining full privileges and thereby expanding the kernel's attack surface

Disallowing container processes from abusing CAP_SYS_ADMIN privileges via user namespaces can reduce the kernel's attack surface and block certain exploitation paths for kernel vulnerabilities.

This rule can be used to harden containers on systems where kernel.unprivileged_userns_clone=0 or user.max_user_namespaces=0 is not set.| Disable CAP_SYS_ADMIN |AppArmor
BPF -| | |Prohibit creating user namespace

`disallow-create-user-ns`|ALL|User namespaces can be used to enhance container isolation. However, it also increases the kernel's attack surface, making certain kernel vulnerabilities easier to exploit. Attackers can use a container to create a user namespace, gaining full privileges and thereby expanding the kernel's attack surface

Disallowing container processes from creating new user namespaces can reduce the kernel's attack surface and block certain exploitation paths for kernel vulnerabilities.

This rule can be used to harden containers on systems where kernel.unprivileged_userns_clone=0 or user.max_user_namespaces=0 is not set.| Disallow creating user namespace |Seccomp -|**Attack Protection**|Mitigating Information Leakage|Mitigating ServiceAccount token leakage.

`mitigate-sa-leak`|ALL|This rule prohibits container processes from reading sensitive Service Account-related information, including tokens, namespaces, and CA certificates. It helps prevent security risks arising from the leakage of Default ServiceAccount or misconfigured ServiceAccount. In the event that attackers gain access to a container through an RCE vulnerability, they often seek to further infiltrate by leaking ServiceAccount information.

In most user scenarios, there is no need for Pods to communicate with the API Server using ServiceAccounts. However, by default, Kubernetes still sets up default ServiceAccounts for Pods that do not require communication with the API Server.|Disallow reading ServiceAccount-related files.|AppArmor
BPF -| | |Mitigating host disk device number leakage

`mitigate-disk-device-number-leak`|ALL|Attackers may attempt to obtain host disk device numbers for subsequent container escape by reading the container process's mount information.|Disallow reading /proc/[PID]/mountinfo and /proc/partitions files|AppArmor
BPF -| | |Mitigating container overlayfs path leakage

`mitigate-overlayfs-leak`|ALL|Attackers may attempt to obtain the overlayfs path of the container's rootfs on the host by accessing the container process's mount information, which could be used for subsequent container escape.|Disallow reading /proc/mounts, /proc/[PID]/mounts, and /proc/[PID]/mountinfo files.

This rule may impact some functionality of the 'mount' command or syscall within containers|AppArmor
BPF -| | |Mitigating host IP leakage

`mitigate-host-ip-leak`|ALL|After gaining access to a container through an RCE vulnerability, attackers often attempt further network penetration attacks. Therefore, restricting attackers from obtaining sensitive information such as host IP, MAC, and network segments through this vector can increase the difficulty and cost of their network penetration activities.|Disallow reading ARP address resolution tables (/proc/net/arp, /proc/[PID]/net/arp, etc.)|AppArmor
BPF -| | |Disallow access to the metadata service

`disallow-metadata-service`|ALL|This rule prohibits container processes from accessing the cloud server's Instance Metadata Service, including two reserved local addresses: 100.96.0.96 and 169.254.169.254.

Attackers, upon gaining code execution privileges within a container, may attempt to access the cloud server's Metadata Service for information disclosure. In certain scenarios, attackers may obtain sensitive information, leading to privilege escalation and lateral movement.|Prohibit connections to Instance Metadata Services' IP addresses|BPF -| |Disable Sensitive Operations|Prohibit writing to the /etc directory

`disable-write-etc`|ALL|Attackers may attempt privilege escalation by modifying sensitive files in the /etc directory, such as altering /etc/bash.bashrc for watering hole attacks, editing /etc/passwd and /etc/shadow to add users for persistence, or modifying nginx.conf or /etc/ssh/ssh_config for persistence.|Disallow writing to the /etc directory|AppArmor
BPF -| | |Prohibit the execution of busybox command

`disable-busybox`|ALL|Some application services are packaged using base images like busybox or Alpine. This also provides attackers with a lot of convenience, as they can use busybox to execute commands and assist in their attacks.|Prohibit the execution of busybox.

If containerized services rely on busybox or related bash commands, enabling this policy may lead to runtime errors.|AppArmor
BPF -| | |Prohibit the creation of Unix shells

`disable-shell`|ALL|After gaining remote code execution privileges through an RCE vulnerability, attackers may use a reverse shell to gain arbitrary command execution capabilities within the container.

This rule prohibits container processes from creating new Unix shells, thus defending against reverse shell.|Prohibit the creation of Unix shells

Some base images may symlink sh to /bin/busybox. In this scenario, it's also necessary to prohibit the execution of busybox.|AppArmor
BPF -| | |Prohibit the execution of wget command

`disable-wget`|ALL|Attackers may use the wget command to download malicious programs for subsequent attacks, such as persistence, privilege escalation, network scanning, cryptocurrency mining, and more.

This rule limits file downloads by prohibiting the execution of the wget command.|Prohibit the execution of wget

Some base images may symlink wget to /bin/busybox. In this scenario, it's also necessary to prohibit the execution of busybox.|AppArmor
BPF -| | |Prohibit the execution of curl command

`disable-curl`|ALL|Attackers may use the curl command to initiate network access and download malicious programs from external sources for subsequent attacks, such as persistence, privilege escalation, network scanning, cryptocurrency mining, and more.

This rule limits network access by prohibiting the execution of the curl command.|Prohibit the execution of curl command.|AppArmor
BPF -| | |Prohibit the execution of chmod command

`disable-chmod`|ALL|When attackers gain control over a container through vulnerabilities, they typically attempt to download additional attack code or tools into the container for further attacks, such as privilege escalation, lateral movement, cryptocurrency mining, and more. In this attack chain, attackers often use the chmod command to modify file permissions for execution.|Prohibit the execution of chmod command.

Some base images may symlink wget to /bin/busybox. In this scenario, it's also necessary to prohibit the execution of busybox command.|AppArmor
BPF -| | |Prohibit setting the execute/search bit of a file

`disable-chmod-x-bit`|ALL|When attackers gain control over a container through vulnerabilities, they typically attempt to download additional attack code or tools into the container for further attacks, such as privilege escalation, lateral movement, cryptocurrency mining, and more. In this attack chain, attackers might use the chmod syscalls to modify file permissions for execution.|Prohibit setting the execute/search bit of a file with `chmod/fchmod/fchmodat/fchmodat2` syscalls|Seccomp -| | |Prohibit setting the SUID/SGID bit of a file

`disable-chmod-s-bit`|ALL|In some scenarios, attackers may attempt to invoke chmod syscalls to perform privilege elevation attacks by setting the file's s-bit (set-user-ID, set-group-ID).|Prohibit setting the set-user-ID/set-group-ID bit of a file with `chmod/fchmod/fchmodat/fchmodat2` syscalls|Seccomp -| | |Prohibit the execution of su/sudo command

`disable-su-sudo`|ALL|When processes within a container run as non-root users, attackers often need to escalate privileges to the root user for further attacks. The sudo/su commands are common local privilege escalation avenues.|Prohibit the execution of su/sudo command.

Some base images may symlink su to /bin/busybox. In this scenario, it's also necessary to prohibit the execution of busybox command.|AppArmor
BPF -| |Restrict Specific Executable|-|ALL|This rule extends the use cases of 'Mitigating Information Leakage' and 'Disabling Sensitive Operations', it allows user to apply restrictions only to specific executable programs within containers.

Restricting specified executable programs serves two purposes:
1). Preventing sandbox policies from affecting the execution of application services within containers.
2).Restricting specified executable programs within containers increases the cost and difficulty for attackers

For example, this feature can be used to restrict programs like busybox, bash, sh, curl within containers, preventing attackers from using them to execute sensitive operations. Meanwhile, the application services is unaffected by sandbox policies and can continue to access ServiceAccount tokens and perform other tasks normally.

*Note: Due to the implementation principles of BPF LSM, this feature cannot be provided by the BPF enforcer.*|Enable sandbox restrictions for specified executable programs.|AppArmor -|**Vulnerability Mitigation**|-|Mitigate cgroups & lxcfs escape

`cgroups-lxcfs-escape-mitigation`|ALL|If users mount the host's cgroupfs into a container or use lxcfs to provide a resource view for the container, there may be a risk of container escape in both scenarios. Attackers could manipulate cgroupfs from within the container to achieve container escape.

This rule can also be used to defend against [CVE-2022-0492](https://unit42.paloaltonetworks.com/cve-2022-0492-cgroups/) vulnerability exploitation.|AppArmor Enforcer prevents writing to：
/\*\*/release_agent,
/\*\*/devices/device.allow,
/\*\*/devices/\*\*/device.allow,
/\*\*/devices/cgroup.procs,
/\*\*/devices/\*\*/cgroup.procs,
/\*\*/devices/task,
/\*\*/devices/\*\*/task,

BPF Enforcer prevents writing to：
/\*\*/release_agent
/\*\*/devices.allow
/\*\*/cgroup.procs
/\*\*/devices/tasks
|AppArmor
BPF -| |-|Mitigate the ability to override runc to escape

`runc-override-mitigation`|ALL|The rule is designed to mitigate vulnerabilities such as [CVE-2019-5736](https://github.com/advisories/GHSA-gxmr-w5mj-v8hh) that exploit container escape by tampering with the host machine's runc.|Disallow writing to `/**/runc` files|AppArmor
BPF -| |-|Mitigate the 'Dirty Pipe' exploit to escape

`dirty-pipe-mitigation`|ALL|The rule is designed to defend against attacks exploiting the [CVE-2022-0847 (Dirty Pipe)](https://dirtypipe.cm4all.com/) vulnerability for container escape. You can use this rule to harden container, before upgrading or patching the kernel.

Note: While this rule may cause issues in some software packages, blocking the syscall usually does not have an effect on legitimate applications, since use of this syscall is relatively rare.| Disallow calling `splice` syscall|Seccomp +|**Hardening**|Securing Privileged Containers|Prohibit modifying procfs' core_pattern

`disallow-write-core-pattern`|Privileged|Attackers may attempt container escape by modifying the procfs core_pattern in a **privileged container** or, in a container (**w/ CAP_SYS_ADMIN**), unmounting specific mount points and then modifying the procfs core_pattern to execute a container escape.|Disallow writing to the procfs' core_pattern file.|AppArmor
BPF +| | |Prohibit mounting securityfs

`disallow-mount-securityfs`|Privileged|Attackers may attempt container escape in containers (**w/ CAP_SYS_ADMIN**) by mounting securityfs with read-write permissions and subsequently modifying it.|Disallow mounting of new security file systems.|AppArmor
BPF +| | |Prohibit remounting procfs

`disallow-mount-procfs`|Privileged|Attackers may attempt container escape in containers (**w/ CAP_SYS_ADMIN**) by remounting procfs with read-write permissions and subsequently modifying the core_pattern, among other things.|1. Disallow mounting of new proc file systems.

2. Prohibit using bind, rbind, move, remount options to remount `/proc**`.

3. When using BPF enforcer, it also prevents unmounting `/proc**`.|AppArmor
BPF +| | |Prohibit modifying cgroupfs' release_agent

`disallow-write-release-agent`|Privileged|Attackers may attempt container escape within **privileged container** by directly modifying the cgroupfs release_agent.|Disallow writing to the cgroupfs' release_agent file.|AppArmor
BPF +| | |Prohibit remounting cgroupfs

`disallow-mount-cgroupfs`|Privileged|Attackers may attempt to escape from containers (**w/ CAP_SYS_ADMIN**) by remounting cgroupfs with read-write permissions. Subsequently, they can modify release_agent and device access permissions, among other things.|1. Disallow mounting new cgroup file systems.

2. Prohibit using bind, rbind, move, remount options to remount `/sys/fs/cgroup**`.

3. Prohibit using rbind option to remount `/sys**`.

4. When using BPF enforcer, it also prevents unmounting `/sys**`.|AppArmor
BPF +| | |Prohibit debugging of disk devices

`disallow-debug-disk-device`|Privileged|Attackers may attempt to read and write host machine files by debugging host machine disk devices within a **privileged container**.

It is recommended to use this rule in conjunction with `disable_cap_mknod` to prevent attackers from bypassing the rule with mknod.|Dynamically acquire host disk devices and restrict container access them with read-write permissions.|AppArmor
BPF +| | |Prohibit mounting of host's disk devices

`disallow-mount-disk-device`|Privileged|Attackers may attempt to mount host machine disk devices within a **privileged container**, thereby gaining read-write access to host machine files.

It is recommended to use this rule in conjunction with `disable_cap_mknod` to prevent attackers from bypassing the rule with mknod.|Dynamically acquire host machine disk device files and prevent mounting within containers.|AppArmor
BPF +| | |Disable the mount system call

`disallow-mount`|Privileged|[MOUNT(2)](https://man7.org/linux/man-pages/man2/mount.2.html) is often used for privilege escalation, container escapes, and other attacks. Most microservices applications do not require mount operations. Therefore, it is recommended to use this rule to restrict container processes from using the `mount()` system call.

Note: The mount system call will be disabled by default if the `spec.policy.privileged` field is false.|Disable the mount system call.|AppArmor
BPF +| | |Disable the umount system call

`disallow-umount`|ALL|[UMOUNT(2)](https://man7.org/linux/man-pages/man2/umount.2.html) can be used to remove the attachment of topmost mount points(such as maskedPaths), leading to privilege escalation and information disclosure. Most microservices applications do not require umount operations. Therefore, it is recommended to use this rule to restrict container processes from using the `umount()` system call.|Disable the umount system call.|AppArmor
BPF +| | |Prohibit loading kernel modules

`disallow-insmod`|Privileged|Attackers may attempt to inject code into the kernel within a container (**w/ CAP_SYS_MODULE**) by executing kernel module loading command.|Disable CAP_SYS_MODULE|AppArmor
BPF +| | |Prohibit loading eBPF programs

`disallow-load-ebpf`|ALL|Attackers may load eBPF programs within a container (**w/ CAP_SYS_ADMIN & CAP_BPF**) to theft data or create rootkit.

Note: CAP_BPF was introduced starting from Linux 5.8.|Disable CAP_SYS_ADMIN & CAP_BPF|AppArmor
BPF +| | |Prohibit accessing process's root directory

`disallow-access-procfs-root`|ALL|This policy prohibits processes within containers from accessing the root directory of the process filesystem (i.e., /proc/[PID]/root), preventing attackers from exploiting shared PID namespaces to launch attacks.

Attackers may attempt to access the process filesystem outside the container by reading and writing to /proc/*/root in environments where the PID namespace is shared with the host or other containers. This could lead to information disclosure, privilege escalation, lateral movement, and other attacks.|Disable PTRACE_MODE_READ permission |AppArmor
BPF +| | |Prohibit accessing kernel exported symbol

`disallow-access-kallsyms`|ALL|Attackers may attempt to leak the base address of kernel modules from containers (**w/ CAP_SYSLOG**) by reading the kernel's exported symbol definitions file. This assists attackers in bypassing KASLR protection to exploit kernel vulnerabilities more easily.|Disallow reading /proc/kallsyms file|AppArmor
BPF +| |Disable Capabilities|Disable all capabilities

`disable-cap-all`|ALL|Disable all capabilities|-|AppArmor
BPF +| | |Disable all capabilities except for NET_BIND_SERVICE

`disable-cap-all-except-net-bind-service`|ALL|Disable all capabilities except for NET_BIND_SERVICE.

This rule complies with the [*Restricted Policy*](https://kubernetes.io/docs/concepts/security/pod-security-standards/#restricted) of the Pod Security Standards.|-|AppArmor
BPF +| | |Disable privileged capabilities

`disable-cap-privileged`|ALL|Disable all privileged capabilities (those that can directly lead to escapes or affect host availability). Only allow the [default capabilities](https://github.com/containerd/containerd/blob/release/1.7/oci/spec.go#L115).

This rule complies with the [*Baseline Policy*](https://kubernetes.io/docs/concepts/security/pod-security-standards/#restricted) of the Pod Security Standards, except for the net_raw capability.|-|AppArmor
BPF +| | |Disable specified capability

`disable-cap-XXXX`|ALL|Disable any specified capabilities, replacing XXXX with the values from 'capabilities(7),' for example, disable-cap-net-raw.|-|AppArmor
BPF +| |Blocking Exploit Vectors|Prohibit abusing user namespaces

`disallow-abuse-user-ns`|ALL|User namespaces can be used to enhance container isolation. However, it also increases the kernel's attack surface, making certain kernel vulnerabilities easier to exploit. Attackers can use a container to create a user namespace, gaining full privileges and thereby expanding the kernel's attack surface

Disallowing container processes from abusing CAP_SYS_ADMIN privileges via user namespaces can reduce the kernel's attack surface and block certain exploitation paths for kernel vulnerabilities.

This rule can be used to harden containers on systems where kernel.unprivileged_userns_clone=0 or user.max_user_namespaces=0 is not set.| Disable CAP_SYS_ADMIN |AppArmor
BPF +| | |Prohibit creating user namespace

`disallow-create-user-ns`|ALL|User namespaces can be used to enhance container isolation. However, it also increases the kernel's attack surface, making certain kernel vulnerabilities easier to exploit. Attackers can use a container to create a user namespace, gaining full privileges and thereby expanding the kernel's attack surface

Disallowing container processes from creating new user namespaces can reduce the kernel's attack surface and block certain exploitation paths for kernel vulnerabilities.

This rule can be used to harden containers on systems where kernel.unprivileged_userns_clone=0 or user.max_user_namespaces=0 is not set.| Disallow creating user namespace |Seccomp +|**Attack Protection**|Mitigating Information Leakage|Mitigating ServiceAccount token leakage.

`mitigate-sa-leak`|ALL|This rule prohibits container processes from reading sensitive Service Account-related information, including tokens, namespaces, and CA certificates. It helps prevent security risks arising from the leakage of Default ServiceAccount or misconfigured ServiceAccount. In the event that attackers gain access to a container through an RCE vulnerability, they often seek to further infiltrate by leaking ServiceAccount information.

In most user scenarios, there is no need for Pods to communicate with the API Server using ServiceAccounts. However, by default, Kubernetes still sets up default ServiceAccounts for Pods that do not require communication with the API Server.|Disallow reading ServiceAccount-related files.|AppArmor
BPF +| | |Mitigating host disk device number leakage

`mitigate-disk-device-number-leak`|ALL|Attackers may attempt to obtain host disk device numbers for subsequent container escape by reading the container process's mount information.|Disallow reading /proc/[PID]/mountinfo and /proc/partitions files|AppArmor
BPF +| | |Mitigating container overlayfs path leakage

`mitigate-overlayfs-leak`|ALL|Attackers may attempt to obtain the overlayfs path of the container's rootfs on the host by accessing the container process's mount information, which could be used for subsequent container escape.|Disallow reading /proc/mounts, /proc/[PID]/mounts, and /proc/[PID]/mountinfo files.

This rule may impact some functionality of the 'mount' command or syscall within containers|AppArmor
BPF +| | |Mitigating host IP leakage

`mitigate-host-ip-leak`|ALL|After gaining access to a container through an RCE vulnerability, attackers often attempt further network penetration attacks. Therefore, restricting attackers from obtaining sensitive information such as host IP, MAC, and network segments through this vector can increase the difficulty and cost of their network penetration activities.|Disallow reading ARP address resolution tables (/proc/net/arp, /proc/[PID]/net/arp, etc.)|AppArmor
BPF +| | |Disallow access to the metadata service

`disallow-metadata-service`|ALL|This rule prohibits container processes from accessing the cloud server's Instance Metadata Service, including two reserved local addresses: 100.96.0.96 and 169.254.169.254.

Attackers, upon gaining code execution privileges within a container, may attempt to access the cloud server's Metadata Service for information disclosure. In certain scenarios, attackers may obtain sensitive information, leading to privilege escalation and lateral movement.|Prohibit connections to Instance Metadata Services' IP addresses|BPF +| |Disable Sensitive Operations|Prohibit writing to the /etc directory

`disable-write-etc`|ALL|Attackers may attempt privilege escalation by modifying sensitive files in the /etc directory, such as altering /etc/bash.bashrc for watering hole attacks, editing /etc/passwd and /etc/shadow to add users for persistence, or modifying nginx.conf or /etc/ssh/ssh_config for persistence.|Disallow writing to the /etc directory|AppArmor
BPF +| | |Prohibit the execution of busybox command

`disable-busybox`|ALL|Some application services are packaged using base images like busybox or Alpine. This also provides attackers with a lot of convenience, as they can use busybox to execute commands and assist in their attacks.|Prohibit the execution of busybox.

If containerized services rely on busybox or related bash commands, enabling this policy may lead to runtime errors.|AppArmor
BPF +| | |Prohibit the creation of Unix shells

`disable-shell`|ALL|After gaining remote code execution privileges through an RCE vulnerability, attackers may use a reverse shell to gain arbitrary command execution capabilities within the container.

This rule prohibits container processes from creating new Unix shells, thus defending against reverse shell.|Prohibit the creation of Unix shells

Some base images may symlink sh to /bin/busybox. In this scenario, it's also necessary to prohibit the execution of busybox.|AppArmor
BPF +| | |Prohibit the execution of wget command

`disable-wget`|ALL|Attackers may use the wget command to download malicious programs for subsequent attacks, such as persistence, privilege escalation, network scanning, cryptocurrency mining, and more.

This rule limits file downloads by prohibiting the execution of the wget command.|Prohibit the execution of wget

Some base images may symlink wget to /bin/busybox. In this scenario, it's also necessary to prohibit the execution of busybox.|AppArmor
BPF +| | |Prohibit the execution of curl command

`disable-curl`|ALL|Attackers may use the curl command to initiate network access and download malicious programs from external sources for subsequent attacks, such as persistence, privilege escalation, network scanning, cryptocurrency mining, and more.

This rule limits network access by prohibiting the execution of the curl command.|Prohibit the execution of curl command.|AppArmor
BPF +| | |Prohibit the execution of chmod command

`disable-chmod`|ALL|When attackers gain control over a container through vulnerabilities, they typically attempt to download additional attack code or tools into the container for further attacks, such as privilege escalation, lateral movement, cryptocurrency mining, and more. In this attack chain, attackers often use the chmod command to modify file permissions for execution.|Prohibit the execution of chmod command.

Some base images may symlink wget to /bin/busybox. In this scenario, it's also necessary to prohibit the execution of busybox command.|AppArmor
BPF +| | |Prohibit setting the execute/search bit of a file

`disable-chmod-x-bit`|ALL|When attackers gain control over a container through vulnerabilities, they typically attempt to download additional attack code or tools into the container for further attacks, such as privilege escalation, lateral movement, cryptocurrency mining, and more. In this attack chain, attackers might use the chmod syscalls to modify file permissions for execution.|Prohibit setting the execute/search bit of a file with `chmod/fchmod/fchmodat/fchmodat2` syscalls|Seccomp +| | |Prohibit setting the SUID/SGID bit of a file

`disable-chmod-s-bit`|ALL|In some scenarios, attackers may attempt to invoke chmod syscalls to perform privilege elevation attacks by setting the file's s-bit (set-user-ID, set-group-ID).|Prohibit setting the set-user-ID/set-group-ID bit of a file with `chmod/fchmod/fchmodat/fchmodat2` syscalls|Seccomp +| | |Prohibit the execution of su/sudo command

`disable-su-sudo`|ALL|When processes within a container run as non-root users, attackers often need to escalate privileges to the root user for further attacks. The sudo/su commands are common local privilege escalation avenues.|Prohibit the execution of su/sudo command.

Some base images may symlink su to /bin/busybox. In this scenario, it's also necessary to prohibit the execution of busybox command.|AppArmor
BPF +| |Restrict Specific Executable|-|ALL|This rule extends the use cases of 'Mitigating Information Leakage' and 'Disabling Sensitive Operations', it allows user to apply restrictions only to specific executable programs within containers.

Restricting specified executable programs serves two purposes:
1). Preventing sandbox policies from affecting the execution of application services within containers.
2).Restricting specified executable programs within containers increases the cost and difficulty for attackers

For example, this feature can be used to restrict programs like busybox, bash, sh, curl within containers, preventing attackers from using them to execute sensitive operations. Meanwhile, the application services is unaffected by sandbox policies and can continue to access ServiceAccount tokens and perform other tasks normally.

*Note: Due to the implementation principles of BPF LSM, this feature cannot be provided by the BPF enforcer.*|Enable sandbox restrictions for specified executable programs.|AppArmor +|**Vulnerability Mitigation**|-|Mitigate cgroups & lxcfs escape

`cgroups-lxcfs-escape-mitigation`|ALL|If users mount the host's cgroupfs into a container or use lxcfs to provide a resource view for the container, there may be a risk of container escape in both scenarios. Attackers could manipulate cgroupfs from within the container to achieve container escape.

This rule can also be used to defend against [CVE-2022-0492](https://unit42.paloaltonetworks.com/cve-2022-0492-cgroups/) vulnerability exploitation.|AppArmor Enforcer prevents writing to：
/\*\*/release_agent,
/\*\*/devices/device.allow,
/\*\*/devices/\*\*/device.allow,
/\*\*/devices/cgroup.procs,
/\*\*/devices/\*\*/cgroup.procs,
/\*\*/devices/task,
/\*\*/devices/\*\*/task,

BPF Enforcer prevents writing to：
/\*\*/release_agent
/\*\*/devices.allow
/\*\*/cgroup.procs
/\*\*/devices/tasks
|AppArmor
BPF +| |-|Mitigate the ability to override runc to escape

`runc-override-mitigation`|ALL|The rule is designed to mitigate vulnerabilities such as [CVE-2019-5736](https://github.com/advisories/GHSA-gxmr-w5mj-v8hh) that exploit container escape by tampering with the host machine's runc.|Disallow writing to `/**/runc` files|AppArmor
BPF +| |-|Mitigate the 'Dirty Pipe' exploit to escape

`dirty-pipe-mitigation`|ALL|The rule is designed to defend against attacks exploiting the [CVE-2022-0847 (Dirty Pipe)](https://dirtypipe.cm4all.com/) vulnerability for container escape. You can use this rule to harden container, before upgrading or patching the kernel.

Note: While this rule may cause issues in some software packages, blocking the syscall usually does not have an effect on legitimate applications, since use of this syscall is relatively rare.| Disallow calling `splice` syscall|Seccomp |||THIS_IS_A_PLACEHOLDER_PLACEH| diff --git a/docs/built_in_rules.zh_CN.md b/docs/built_in_rules.zh_CN.md index c8ae23ff..850f125f 100644 --- a/docs/built_in_rules.zh_CN.md +++ b/docs/built_in_rules.zh_CN.md @@ -8,55 +8,55 @@ |------|--------|----|-------|---| |AlwaysAllow|✔|✔|✔|在容器启动时不对其施加任何强制访问控制 |RuntimeDefault|✔|✔|✔|使用与容器运行时组件相同的默认策略（如 containerd 的 [cri-containerd.apparmor.d](https://github.com/containerd/containerd/blob/main/contrib/apparmor/template.go)）进行基础防护 -|EnhanceProtect|✔|✔|✔|- 支持 5 类[内置规则](built_in_rules.zh_CN.md#内置规则)和自定义接口，以满足不同的防护需求。
- 默认在 RuntimeDefault 模式的基础上进行增强防护（当 `spec.policy.enhanceProtect.privileged` 为 `nil` 或 `false` 时）
- 支持在 AlwaysAllow 模式的基础上进行增强防护（当 `spec.policy.enhanceProtect.privileged` 为 `true`） -|BehaviorModeling|✔|🏗️|✔|- 利用 BPF & Audit 等技术同时对多个工作负载进行行为建模
- 行为模型保存在对应的 [ArmorProfileModel](../apis/varmor/v1beta1/armorprofilemodel_types.go) 对象中
- 不可切换防护模式
- 请参见 [The BehaviorModeling Mode](behavior_modeling.md) +|EnhanceProtect|✔|✔|✔|- 支持 5 类[内置规则](built_in_rules.zh_CN.md#内置规则)和自定义接口，以满足不同的防护需求。
- 默认在 RuntimeDefault 模式的基础上进行增强防护（当 `spec.policy.enhanceProtect.privileged` 为 `nil` 或 `false` 时）
- 支持在 AlwaysAllow 模式的基础上进行增强防护（当 `spec.policy.enhanceProtect.privileged` 为 `true`） +|BehaviorModeling|✔|🏗️|✔|- 利用 BPF & Audit 等技术同时对多个工作负载进行行为建模
- 行为模型保存在对应的 [ArmorProfileModel](../apis/varmor/v1beta1/armorprofilemodel_types.go) 对象中
- 不可切换防护模式
- 请参见 [The BehaviorModeling Mode](behavior_modeling.md) |DefenseInDepth|✔||✔|基于行为模型 [ArmorProfileModel](../apis/varmor/v1beta1/armorprofilemodel_types.go) 对工作负载进行防护 -注意：
- vArmor 策略支持动态切换运行模式（限 EnhanceProtect, RuntimeDefault, AlwaysAllow, DefenseInDepth）、更新沙箱规则，而无需重启工作负载。但当使用 Seccomp enforcer 时，需要重启工作负载来使 Seccomp Profile 的变更生效。
- vArmor 支持修改策略为其添加新的 enforcer，但不支持删除已经设置的 enforcer。除此之外，新添加的 enforcer 仅对新创建的 Workloads 生效。 +注意：
- vArmor 策略支持动态切换运行模式（限 EnhanceProtect, RuntimeDefault, AlwaysAllow, DefenseInDepth）、更新沙箱规则，而无需重启工作负载。但当使用 Seccomp enforcer 时，需要重启工作负载来使 Seccomp Profile 的变更生效。
- vArmor 支持修改策略为其添加新的 enforcer，但不支持删除已经设置的 enforcer。除此之外，新添加的 enforcer 仅对新创建的 Workloads 生效。 ## 内置规则 **vArmor** 支持使用在 **EnhanceProtect** 模式下使用内置规则和自定义接口来定义防护策略，当前支持的内置规则及其分类如下表所示。你可以尝试使用 [policy advisor](../tools/policy-advisor/README.md) 来生成策略模版，从而帮助创建最终的防护策略。 -注意：
- 不同 enforcer 所支持的内置策略与语法仍旧处于开发中。
- 不同 enforcer 所能支持的规则和语法会有所区别。例如 AppArmor enforcer 不支持细粒度的网络访问控制，BPF 不支持对指定的可执行程序进行访问控制等。
+注意：
- 不同 enforcer 所支持的内置策略与语法仍旧处于开发中。
- 不同 enforcer 所能支持的规则和语法会有所区别。例如 AppArmor enforcer 不支持细粒度的网络访问控制，BPF 不支持对指定的可执行程序进行访问控制等。
| 类别 | 子类 | 规则名称 & ID | 适用容器 | 说明 | 原理 & 影响 | 支持的 enforcer | |-----|-----|---------------------------------------------|---------|------|------------|----------------| -|**Hardening**|阻断特权容器的常见逃逸向量|禁止改写 procfs core_pattern

`disallow-write-core-pattern`|Privileged|攻击者可能会在特权容器（**Privileged Container**）中，通过改写 procfs core_pattern，来实施容器逃逸。或者在特权容器（**w/ CAP_SYS_ADMIN**）中，卸载特定挂载点后改写 procfs core_pattern，来实施容器逃逸。|禁止修改 procfs 的 core_pattern|AppArmor
BPF -| | |禁止挂载 securityfs

`disallow-mount-securityfs`|Privileged|攻击者可能会在特权容器（**w/ CAP_SYS_ADMIN**）中，以读写权限挂载新的 securityfs 并对其进行修改。|禁止挂载新的 securityfs|AppArmor
BPF -| | |禁止重新挂载 procfs

`disallow-mount-procfs`|Privileged|攻击者可能会在特权容器（**w/ CAP_SYS_ADMIN**）中，以读写权限重新挂载 procfs，然后再通过改写 core_pattern 等方式进行容器逃逸、修改系统配置。|1. 禁止挂载新的 procfs

2. 禁止使用 bind, rbind, move, remount 选项重新挂载 `/proc**`

3. 使用 BPF enforcer 时，还将禁止卸载 `/proc**`|AppArmor
BPF -| | |禁止改写 cgroupfs release_agent

`disallow-write-release-agent`|Privileged|攻击者可能会在特权容器（**Privileged Container**）中，通过改写 cgroupfs release_agent，来实施容器逃逸。|禁止修改 cgroupfs 的 release_agent|AppArmor
BPF -| | |禁止重新挂载 cgroupfs

`disallow-mount-cgroupfs`|Privileged|攻击者可能会在特权容器（**w/ CAP_SYS_ADMIN**）中，以读写权限重新挂载 cgroupfs。然后再通过改写 release_agent、设备访问权限等方式进行容器逃逸、修改系统配置。|1. 禁止挂载新的 cgroupfs

2. 禁止使用 bind, rbind, move, remount 选项重新挂载 `/sys/fs/cgroup**`

3. 禁止使用 rbind 选项重新挂载 `/sys**`

4. 使用 BPF enforcer 时，还将禁止卸载 `/sys**` |AppArmor
BPF -| | |禁止调试磁盘设备

`disallow-debug-disk-device`|Privileged|攻击者可能会在特权容器（**Privileged Container**）中，通过调试宿主机磁盘设备，从而实现宿主机文件的读写。

建议配合 `disable_cap_mknod` 使用，从而防止攻击者利用 mknod 创建新的设备文件，从而绕过此规则|动态获取宿主机磁盘设备文件，并禁止在容器内以读写权限访问|AppArmor
BPF -| | |禁止挂载宿主机磁盘设备并访问

`disallow-mount-disk-device`|Privileged|攻击者可能会在特权容器（**Privileged Container**）中，挂载宿主机磁盘设备，从而实现宿主机文件的读写。

建议配合 `disable_cap_mknod` 使用，从而防止攻击者利用 mknod 创建新的设备文件，从而绕过此规则|动态获取宿主机磁盘设备文件，并禁止在容器内挂载|AppArmor
BPF -| | |禁用 mount 系统调用

`disallow-mount`|Privileged|[MOUNT(2)](https://man7.org/linux/man-pages/man2/mount.2.html) 常被用于权限提升、容器逃逸等攻击。而几乎所有的微服务应用都无需 mount 操作，因此建议使用此规则限制容器内进程访问 mount 系统调用。

注：当 spec.policy.privileged 为 false 时，将默认禁用 mount 系统调用。|禁用 mount 系统调用|AppArmor
BPF -| | |禁用 umount 系统调用

`disallow-umount`|ALL|[UMOUNT(2)](https://man7.org/linux/man-pages/man2/umount.2.html) 可被用于卸载敏感的挂载点（例如 maskedPaths），从而导致权限提升、信息泄露。而几乎所有的微服务应用都无需 umount 操作，因此建议使用此规则限制容器内进程访问 umount 系统调用。|禁用 umount 系统调用|AppArmor
BPF -| | |禁止加载内核模块

`disallow-insmod`|Privileged|攻击者可能会在特权容器中（**w/ CAP_SYS_MODULE**），通过执行内核模块加载命令 insmod，向内核中注入代码。|禁用 CAP_SYS_MODULE|AppArmor
BPF -| | |禁止加载 ebpf Program

`disallow-load-ebpf`|ALL|攻击者可能会在特权容器中（**w/ CAP_SYS_ADMIN & CAP_BPF**），加载 ebpf Program 实现数据窃取和隐藏。

注：CAP_BPF 自 Linux 5.8 引入。|禁用 CAP_SYS_ADMIN, CAP_BPF|AppArmor
BPF -| | |禁止访问进程文件系统的根目录

`disallow-access-procfs-root`|ALL|本策略禁止容器内进程访问进程文件系统的根目录（即 /proc/[PID]/root），防止攻击者利用共享 pid ns 的进程进行攻击。

攻击者可能会在共享了宿主机 pid ns、与其他容器共享 pid ns 的容器环境中，通过读写 /proc/*/root 来访问容器外的进程文件系统，实现信息泄露、权限提升、横向移动等攻击。|禁用 PTRACE_MODE_READ 权限|AppArmor
BPF -| | |禁止读取内核符号文件

`disallow-access-kallsyms`|ALL|攻击者可能会在特权容器中（**w/ CAP_SYSLOG**），通过读取内核符号文件来获取内核模块地址。从而绕过 KASLR 防护，降低内核漏洞的难度与成本。|禁止读取 /proc/kallsyms 文件|AppArmor
BPF -| |禁用 capabilities|禁用所有 capabilities

`disable-cap-all`|ALL|禁用所有 capabilities|-|AppArmor
BPF -| | |禁用除 net_bind_service 外的 capabilities

`disable-cap-all-except-net-bind-service`|ALL|禁用除 net-bind-service 以外的 capabilities.

此规则符合 Pod Security Standards 的 [*Restricted Policy*](https://kubernetes.io/docs/concepts/security/pod-security-standards/#restricted) 要求。|-|AppArmor
BPF -| | |禁用特权 capability

`disable-cap-privileged`|ALL|禁用所有的特权 capabilities（可直接造成逃逸、影响宿主机可用性的 capabilities），仅允许运行时的[默认 capabilities](https://github.com/containerd/containerd/blob/release/1.7/oci/spec.go#L115)。

此规则符合 Pod Security Standards 的 [*Baseline Policy*](https://kubernetes.io/docs/concepts/security/pod-security-standards/#restricted) 要求，但 net_raw capability 除外。|-|AppArmor
BPF -| | |禁用任意 capability

`disable-cap-XXXX`|ALL|禁用任意指定的 capabilities，请将 XXXX 替换为 man capabilities 中的值，例如 disable-cap-net-raw|-|AppArmor
BPF -| |阻断部分内核漏洞利用向量|禁止滥用 User Namespace

`disallow-abuse-user-ns`|ALL|User Namespace 可以被用于增强容器隔离性。但它的出现同时也增大了内核的攻击面，或使得某些内核漏洞更容易被利用。攻击者可以在容器内，通过创建 User Namespace 来获取全部特权，从而扩大内核攻击面。

禁止容器进程通过 User Namesapce 滥用 CAP_SYS_ADMIN 特权可用于降低内核攻击面，阻断部分内核漏洞的利用路径。
在未设置 kernel.unprivileged_userns_clone=0 或 user.max_user_namespaces=0 的系统上，可通过此规则来为容器进行加固。|限制通过 User Namespace 滥用 CAP_SYS_ADMIN |AppArmor
BPF -| | |禁止创建 User Namespace

`disallow-create-user-ns`|ALL|User Namespace 可以被用于增强容器隔离性。但它的出现同时也增大了内核的攻击面，或使得某些内核漏洞更容易被利用。攻击者可以在容器内，通过创建 User Namespace 来获取全部特权，从而扩大内核攻击面。

禁止容器进程创建新的 User Namesapce 从而获取 CAP_SYS_ADMIN 特权可用于降低内核攻击面，阻断部分内核漏洞的利用路径。
在未设置 kernel.unprivileged_userns_clone=0 或 user.max_user_namespaces=0 的系统上，可通过此规则来为容器进行加固。|禁止创建 User Namespace|Seccomp -|**Attack Protection**|缓解信息泄露|缓解 ServiceAccount 泄露

`mitigate-sa-leak`|ALL|此规则禁止容器进程读取 ServiceAccount 相关的敏感信息，包括 token、namespace、ca 证书。避免 default SA 泄漏、错误配置的 SA 泄漏带来的安全风险，攻击者通过 RCE 漏洞获取 k8s 容器内的权限后，常倾向于通过泄漏其 SA 信息来进行进一步的渗透入侵活动。

在大部分用户场景中，并不需要使用 SA 与 API Server 进行通信。而默认情况下，k8s 会为不需要与 API Server 通信的 Pod 设置 default SA。|禁止 ServiceAccount 文件的读操作|AppArmor
BPF -| | |缓解宿主机磁盘设备号泄露

`mitigate-disk-device-number-leak`|ALL|此规则禁止容器进程读取 /proc/[PID]/mountinfo, /proc/partitions。

攻击者可能会通过读取容器进程的挂载信息来获取宿主机磁盘设备的设备号，从而用于后续的容器逃逸。|禁止 mountinfo, partitions 的读操作|AppArmor
BPF -| | |缓解容器 overlayfs 路径泄露

`mitigate-overlayfs-leak`|ALL|禁止读取 /proc/mounts、/proc/[PID]/mounts、/proc/[PID]/mountinfo 文件。

攻击者可能会通过获取容器进程的挂载信息来获取容器进程 rootfs 在宿主机中的 overlayfs 路径，从而用于后续的容器逃逸。|禁止 mounts, mountinfo 文件的读操作

此规则可能会影响容器内 mount 命令的部分功能|AppArmor
BPF -| | |缓解宿主机 IP 泄露

`mitigate-host-ip-leak`|ALL|此规则禁止容器进程读取 ARP 地址解析表（/proc/net/arp、/proc/[PID]/net/arp 等），从而获取宿主机 IP 和 Mac 地址等敏感信息

攻击者通过 RCE 漏洞获取 k8s 容器内的权限后，会尝试进一步的网络渗透攻击。因此，限制攻击者借此获取宿主机 IP、MAC 地址、网段等敏感信息，可增加攻击者进行网络渗透的难度和成本。|禁止 ARP 文件的读操作|AppArmor
BPF -| | |禁止访问云服务器的 metadata service

`disallow-metadata-service`|ALL|此规则禁止容器进程访问云服务器的 Instance Metadata Service。包含两个本地链接保留地址：100.96.0.96 和 169.254.169.254

攻击者获取容器内的代码执行权限后，会尝试访问云服务器的 Metadata Service 来进行信息泄露。在某些场景下，攻击者可能会获取敏感信息，从而进行权限提升、横向渗透。|禁止连接 Instance Metadata Services 的 IP 地址|BPF -| |禁止敏感操作|禁止写入 /etc 目录

`disable-write-etc`|ALL|攻击者可能会通过修改 /etc 目录中的敏感文件来实施权限提升，例如修改 /etc/bash.bashrc 等实施水坑攻击、修改 /etc/passwd 和 /etc/shadow 添加用户进行持久化、修改 nginx.conf 或 /etc/ssh/ssh_config 进行持久化等。|禁止写入 /etc 目录|AppArmor
BPF -| | |禁止执行 busybox 命令

`disable-busybox`|ALL|此规则禁止容器进程执行 busybox 命令。

某些应用服务会以 busybox, alpine 等作为基础镜像进行打包，而这些镜像一般会使用 busybox 工具箱作为基础命令行工具的可执行程序。这也给攻击者提供了很多便利，攻击者可以利用 busybox 执行命令辅助攻击。|禁止 busybox 执行

若容器内服务依赖 busybox 或相关 bash 命令，开启此策略会导致运行出错|AppArmor
BPF -| | |禁止创建 Unix Shell

`disable-shell`|ALL|此规则禁止容器进程创建新的 Unix shell，从而实施反弹 shell 等攻击手段。

攻击者通过 RCE 漏洞获取服务的远程代码执行权限后，通常会借助 reverse shell 获取容器内任意命令执行能力。|禁止 Unix Shell 执行

有些基础镜像会动态链接 sh 到 /bin/busybox，此情况下还需配合“禁止执行 busybox 命令”策略使用|AppArmor
BPF -| | |禁止通过 wget 命令下载文件

`disable-wget`|ALL|此规则通过禁止执行 wget 命令来限制文件下载。

攻击者通常会借助 wget 命令从外部下载攻击程序进行随后的攻击（驻留、权限提升、网络扫描、挖矿等）。|禁止 wget 执行

有些基础镜像会动态链接 wget 到 /bin/busybox，此情况下还需配合“禁止执行 busybox 命令”策略使用|AppArmor
BPF -| | |禁止通过 curl 命令下载文件

`disable-curl`|ALL|此规则禁止容器进程执行 curl 命令。

攻击者通常会借助 curl 命令发起网络访问、从外部下载攻击程序进行随后的攻击（驻留、权限提升、网络扫描、挖矿等）。|禁止 curl 执行|AppArmor
BPF -| | |禁止通过 chmod 修改文件权限

`disable-chmod`|ALL|此规则禁止容器进程执行 chmod 命令。

当攻击者通过漏洞获取容器内的控制权后，通常会尝试下载其他攻击代码、工具到容器内实施进一步的攻击（权限提升、横向渗透、挖矿等）。在这个攻击链路中，攻击者通常会利用 chmod 命令修改文件的执行权限。|禁止 chmod 执行

有些基础镜像会动态链接 chmod 到 /bin/busybox，此情况下还需配合“禁止执行 busybox 命令”策略使用

（TODO: BPF Enforcer 增加 path_chmod hook 点）|AppArmor
BPF -| | |禁止设置文件的可执行属性

`disable-chmod-x-bit`|ALL|此规则禁止容器进程通过 chmod 相关系统调用修改文件权限，创建可执行文件。

当攻击者通过漏洞获取容器内的控制权后，通常会尝试下载其他攻击代码、工具到容器内实施进一步的攻击（权限提升、横向渗透、挖矿等）。在这个攻击链路中，攻击者通常会调用 chmod 相关系统调用(chmod/fchmod/fchmodat/fchmodat2)，设置文件的可执行权限。|禁止通过 chmod 相关系统调用，设置文件的 execute/search 权限。|Seccomp -| | |禁止设置文件的 SUID/SGID 属性

`disable-chmod-s-bit`|ALL|此规则禁止容器进程通过 chmod 相关系统调用修改文件属性，设置文件的 s 标记位（set-user-ID, set-group-ID）。

在某些场景下，攻击者可能会尝试调用 chmod 系列的系统调用（chmod/fchmod/fchmodat/fchmodat2），通过设置文件的 s 标记位（set-user-ID, set-group-ID）来实施权限提升攻击。|禁止通过 chmod 相关系统调用，设置文件的 set-user-ID/set-group-ID 属性。|Seccomp -| | |禁止执行 sudo、su 命令

`disable-su-sudo`|ALL|此规则禁止容器进程执行 sudo/su 命令进行权限提升。

当容器内的进程以非 root 用户运行时，攻击者需要先提权至 root 用户进行后续攻击。而 sudo/su 命令是本地提权的常见途径之一。|禁止 sudo、su 执行

有些基础镜像会动态链接 su 到 /bin/busybox，此情况下还需配合“禁止执行 busybox 命令”策略使用|AppArmor
BPF -| |限制特定可执行文件|-|ALL|此规则对 “容器信息泄漏缓解” 和 “容器敏感命令限制” 两类策略的使用场景进行了扩充，使用户可以只对容器内的特定可执行文件及其子进程进行限制。

对指定的可执行文件进行限制，实现两个目的：
1). 避免沙箱策略影响容器内应用服务的正常执行
2). 对容器内指定可执行文件进行限制，增加攻击者成本和难度。

例如，可以利用此功能对容器中的 busybox、bash、sh、curl 进行限制，阻止攻击者利用它们来执行敏感操作。与此同时，应用服务的运行则不受沙箱策略的限制，可以正常执行读取 ServiceAccount token 等敏感操作。

注：受限于 BPF LSM 的实现原理，BPF enforcer 无法提供此功能|为特定可执行文件开启沙箱限制|AppArmor -|**Vulnerability Mitigation**|-|缓解 cgroups & lxcfs 逃逸

`cgroups-lxcfs-escape-mitigation`|ALL|若用户将宿主机的 cgroupfs 挂载进容器，或使用 lxcfs 为容器提供资源视图。在这两种场景下可能存在容器逃逸风险，攻击者可以在容器内改写 cgroupfs 实施容器逃逸。

此规则也可用于防御 [CVE-2022-0492](https://unit42.paloaltonetworks.com/cve-2022-0492-cgroups/) 漏洞利用。|AppArmor Enforcer 阻止在容器内修改：
/\*\*/release_agent,
/\*\*/devices/device.allow,
/\*\*/devices/\*\*/device.allow,
/\*\*/devices/cgroup.procs,
/\*\*/devices/\*\*/cgroup.procs,
/\*\*/devices/task,
/\*\*/devices/\*\*/task,

BPF Enforcer 阻止在容器内修改：
/\*\*/release_agent
/\*\*/devices.allow
/\*\*/cgroup.procs
/\*\*/devices/tasks
|AppArmor
BPF -| |-|缓解通过改写 runc 实现的容器逃逸

`runc-override-mitigation`|ALL|本策略用于缓解通过改写宿主机 runc 从而实现容器逃逸的漏洞，例如 [CVE-2019-5736](https://github.com/advisories/GHSA-gxmr-w5mj-v8hh)。|禁止改写 /**/runc 文件|AppArmor
BPF -| |-|缓解利用 Dirty Pipe 漏洞实现的容器逃逸

`dirty-pipe-mitigation`|ALL|本策略用于防御利用 [CVE-2022-0847 (Dirty Pipe)](https://dirtypipe.cm4all.com/) 漏洞进行容器逃逸的攻击，您可以使用此规则在升级内核前对容器进行加固。

注：尽管禁用 splice 系统调用可能会对一些软件包产生问题，但对大多数合法应用来说都不会产生影响，因为这个系统调用的使用相对罕见。|禁止调用 splice syscall|Seccomp +|**Hardening**|阻断特权容器的常见逃逸向量|禁止改写 procfs core_pattern

`disallow-write-core-pattern`|Privileged|攻击者可能会在特权容器（**Privileged Container**）中，通过改写 procfs core_pattern，来实施容器逃逸。或者在特权容器（**w/ CAP_SYS_ADMIN**）中，卸载特定挂载点后改写 procfs core_pattern，来实施容器逃逸。|禁止修改 procfs 的 core_pattern|AppArmor
BPF +| | |禁止挂载 securityfs

`disallow-mount-securityfs`|Privileged|攻击者可能会在特权容器（**w/ CAP_SYS_ADMIN**）中，以读写权限挂载新的 securityfs 并对其进行修改。|禁止挂载新的 securityfs|AppArmor
BPF +| | |禁止重新挂载 procfs

`disallow-mount-procfs`|Privileged|攻击者可能会在特权容器（**w/ CAP_SYS_ADMIN**）中，以读写权限重新挂载 procfs，然后再通过改写 core_pattern 等方式进行容器逃逸、修改系统配置。|1. 禁止挂载新的 procfs

2. 禁止使用 bind, rbind, move, remount 选项重新挂载 `/proc**`

3. 使用 BPF enforcer 时，还将禁止卸载 `/proc**`|AppArmor
BPF +| | |禁止改写 cgroupfs release_agent

`disallow-write-release-agent`|Privileged|攻击者可能会在特权容器（**Privileged Container**）中，通过改写 cgroupfs release_agent，来实施容器逃逸。|禁止修改 cgroupfs 的 release_agent|AppArmor
BPF +| | |禁止重新挂载 cgroupfs

`disallow-mount-cgroupfs`|Privileged|攻击者可能会在特权容器（**w/ CAP_SYS_ADMIN**）中，以读写权限重新挂载 cgroupfs。然后再通过改写 release_agent、设备访问权限等方式进行容器逃逸、修改系统配置。|1. 禁止挂载新的 cgroupfs

2. 禁止使用 bind, rbind, move, remount 选项重新挂载 `/sys/fs/cgroup**`

3. 禁止使用 rbind 选项重新挂载 `/sys**`

4. 使用 BPF enforcer 时，还将禁止卸载 `/sys**` |AppArmor
BPF +| | |禁止调试磁盘设备

`disallow-debug-disk-device`|Privileged|攻击者可能会在特权容器（**Privileged Container**）中，通过调试宿主机磁盘设备，从而实现宿主机文件的读写。

建议配合 `disable_cap_mknod` 使用，从而防止攻击者利用 mknod 创建新的设备文件，从而绕过此规则|动态获取宿主机磁盘设备文件，并禁止在容器内以读写权限访问|AppArmor
BPF +| | |禁止挂载宿主机磁盘设备并访问

`disallow-mount-disk-device`|Privileged|攻击者可能会在特权容器（**Privileged Container**）中，挂载宿主机磁盘设备，从而实现宿主机文件的读写。

建议配合 `disable_cap_mknod` 使用，从而防止攻击者利用 mknod 创建新的设备文件，从而绕过此规则|动态获取宿主机磁盘设备文件，并禁止在容器内挂载|AppArmor
BPF +| | |禁用 mount 系统调用

`disallow-mount`|Privileged|[MOUNT(2)](https://man7.org/linux/man-pages/man2/mount.2.html) 常被用于权限提升、容器逃逸等攻击。而几乎所有的微服务应用都无需 mount 操作，因此建议使用此规则限制容器内进程访问 mount 系统调用。

注：当 spec.policy.privileged 为 false 时，将默认禁用 mount 系统调用。|禁用 mount 系统调用|AppArmor
BPF +| | |禁用 umount 系统调用

`disallow-umount`|ALL|[UMOUNT(2)](https://man7.org/linux/man-pages/man2/umount.2.html) 可被用于卸载敏感的挂载点（例如 maskedPaths），从而导致权限提升、信息泄露。而几乎所有的微服务应用都无需 umount 操作，因此建议使用此规则限制容器内进程访问 umount 系统调用。|禁用 umount 系统调用|AppArmor
BPF +| | |禁止加载内核模块

`disallow-insmod`|Privileged|攻击者可能会在特权容器中（**w/ CAP_SYS_MODULE**），通过执行内核模块加载命令 insmod，向内核中注入代码。|禁用 CAP_SYS_MODULE|AppArmor
BPF +| | |禁止加载 ebpf Program

`disallow-load-ebpf`|ALL|攻击者可能会在特权容器中（**w/ CAP_SYS_ADMIN & CAP_BPF**），加载 ebpf Program 实现数据窃取和隐藏。

注：CAP_BPF 自 Linux 5.8 引入。|禁用 CAP_SYS_ADMIN, CAP_BPF|AppArmor
BPF +| | |禁止访问进程文件系统的根目录

`disallow-access-procfs-root`|ALL|本策略禁止容器内进程访问进程文件系统的根目录（即 /proc/[PID]/root），防止攻击者利用共享 pid ns 的进程进行攻击。

攻击者可能会在共享了宿主机 pid ns、与其他容器共享 pid ns 的容器环境中，通过读写 /proc/*/root 来访问容器外的进程文件系统，实现信息泄露、权限提升、横向移动等攻击。|禁用 PTRACE_MODE_READ 权限|AppArmor
BPF +| | |禁止读取内核符号文件

`disallow-access-kallsyms`|ALL|攻击者可能会在特权容器中（**w/ CAP_SYSLOG**），通过读取内核符号文件来获取内核模块地址。从而绕过 KASLR 防护，降低内核漏洞的难度与成本。|禁止读取 /proc/kallsyms 文件|AppArmor
BPF +| |禁用 capabilities|禁用所有 capabilities

`disable-cap-all`|ALL|禁用所有 capabilities|-|AppArmor
BPF +| | |禁用除 net_bind_service 外的 capabilities

`disable-cap-all-except-net-bind-service`|ALL|禁用除 net-bind-service 以外的 capabilities.

此规则符合 Pod Security Standards 的 [*Restricted Policy*](https://kubernetes.io/docs/concepts/security/pod-security-standards/#restricted) 要求。|-|AppArmor
BPF +| | |禁用特权 capability

`disable-cap-privileged`|ALL|禁用所有的特权 capabilities（可直接造成逃逸、影响宿主机可用性的 capabilities），仅允许运行时的[默认 capabilities](https://github.com/containerd/containerd/blob/release/1.7/oci/spec.go#L115)。

此规则符合 Pod Security Standards 的 [*Baseline Policy*](https://kubernetes.io/docs/concepts/security/pod-security-standards/#restricted) 要求，但 net_raw capability 除外。|-|AppArmor
BPF +| | |禁用任意 capability

`disable-cap-XXXX`|ALL|禁用任意指定的 capabilities，请将 XXXX 替换为 man capabilities 中的值，例如 disable-cap-net-raw|-|AppArmor
BPF +| |阻断部分内核漏洞利用向量|禁止滥用 User Namespace

`disallow-abuse-user-ns`|ALL|User Namespace 可以被用于增强容器隔离性。但它的出现同时也增大了内核的攻击面，或使得某些内核漏洞更容易被利用。攻击者可以在容器内，通过创建 User Namespace 来获取全部特权，从而扩大内核攻击面。

禁止容器进程通过 User Namesapce 滥用 CAP_SYS_ADMIN 特权可用于降低内核攻击面，阻断部分内核漏洞的利用路径。
在未设置 kernel.unprivileged_userns_clone=0 或 user.max_user_namespaces=0 的系统上，可通过此规则来为容器进行加固。|限制通过 User Namespace 滥用 CAP_SYS_ADMIN |AppArmor
BPF +| | |禁止创建 User Namespace

`disallow-create-user-ns`|ALL|User Namespace 可以被用于增强容器隔离性。但它的出现同时也增大了内核的攻击面，或使得某些内核漏洞更容易被利用。攻击者可以在容器内，通过创建 User Namespace 来获取全部特权，从而扩大内核攻击面。

禁止容器进程创建新的 User Namesapce 从而获取 CAP_SYS_ADMIN 特权可用于降低内核攻击面，阻断部分内核漏洞的利用路径。
在未设置 kernel.unprivileged_userns_clone=0 或 user.max_user_namespaces=0 的系统上，可通过此规则来为容器进行加固。|禁止创建 User Namespace|Seccomp +|**Attack Protection**|缓解信息泄露|缓解 ServiceAccount 泄露

`mitigate-sa-leak`|ALL|此规则禁止容器进程读取 ServiceAccount 相关的敏感信息，包括 token、namespace、ca 证书。避免 default SA 泄漏、错误配置的 SA 泄漏带来的安全风险，攻击者通过 RCE 漏洞获取 k8s 容器内的权限后，常倾向于通过泄漏其 SA 信息来进行进一步的渗透入侵活动。

在大部分用户场景中，并不需要使用 SA 与 API Server 进行通信。而默认情况下，k8s 会为不需要与 API Server 通信的 Pod 设置 default SA。|禁止 ServiceAccount 文件的读操作|AppArmor
BPF +| | |缓解宿主机磁盘设备号泄露

`mitigate-disk-device-number-leak`|ALL|此规则禁止容器进程读取 /proc/[PID]/mountinfo, /proc/partitions。

攻击者可能会通过读取容器进程的挂载信息来获取宿主机磁盘设备的设备号，从而用于后续的容器逃逸。|禁止 mountinfo, partitions 的读操作|AppArmor
BPF +| | |缓解容器 overlayfs 路径泄露

`mitigate-overlayfs-leak`|ALL|禁止读取 /proc/mounts、/proc/[PID]/mounts、/proc/[PID]/mountinfo 文件。

攻击者可能会通过获取容器进程的挂载信息来获取容器进程 rootfs 在宿主机中的 overlayfs 路径，从而用于后续的容器逃逸。|禁止 mounts, mountinfo 文件的读操作

此规则可能会影响容器内 mount 命令的部分功能|AppArmor
BPF +| | |缓解宿主机 IP 泄露

`mitigate-host-ip-leak`|ALL|此规则禁止容器进程读取 ARP 地址解析表（/proc/net/arp、/proc/[PID]/net/arp 等），从而获取宿主机 IP 和 Mac 地址等敏感信息

攻击者通过 RCE 漏洞获取 k8s 容器内的权限后，会尝试进一步的网络渗透攻击。因此，限制攻击者借此获取宿主机 IP、MAC 地址、网段等敏感信息，可增加攻击者进行网络渗透的难度和成本。|禁止 ARP 文件的读操作|AppArmor
BPF +| | |禁止访问云服务器的 metadata service

`disallow-metadata-service`|ALL|此规则禁止容器进程访问云服务器的 Instance Metadata Service。包含两个本地链接保留地址：100.96.0.96 和 169.254.169.254

攻击者获取容器内的代码执行权限后，会尝试访问云服务器的 Metadata Service 来进行信息泄露。在某些场景下，攻击者可能会获取敏感信息，从而进行权限提升、横向渗透。|禁止连接 Instance Metadata Services 的 IP 地址|BPF +| |禁止敏感操作|禁止写入 /etc 目录

`disable-write-etc`|ALL|攻击者可能会通过修改 /etc 目录中的敏感文件来实施权限提升，例如修改 /etc/bash.bashrc 等实施水坑攻击、修改 /etc/passwd 和 /etc/shadow 添加用户进行持久化、修改 nginx.conf 或 /etc/ssh/ssh_config 进行持久化等。|禁止写入 /etc 目录|AppArmor
BPF +| | |禁止执行 busybox 命令

`disable-busybox`|ALL|此规则禁止容器进程执行 busybox 命令。

某些应用服务会以 busybox, alpine 等作为基础镜像进行打包，而这些镜像一般会使用 busybox 工具箱作为基础命令行工具的可执行程序。这也给攻击者提供了很多便利，攻击者可以利用 busybox 执行命令辅助攻击。|禁止 busybox 执行

若容器内服务依赖 busybox 或相关 bash 命令，开启此策略会导致运行出错|AppArmor
BPF +| | |禁止创建 Unix Shell

`disable-shell`|ALL|此规则禁止容器进程创建新的 Unix shell，从而实施反弹 shell 等攻击手段。

攻击者通过 RCE 漏洞获取服务的远程代码执行权限后，通常会借助 reverse shell 获取容器内任意命令执行能力。|禁止 Unix Shell 执行

有些基础镜像会动态链接 sh 到 /bin/busybox，此情况下还需配合“禁止执行 busybox 命令”策略使用|AppArmor
BPF +| | |禁止通过 wget 命令下载文件

`disable-wget`|ALL|此规则通过禁止执行 wget 命令来限制文件下载。

攻击者通常会借助 wget 命令从外部下载攻击程序进行随后的攻击（驻留、权限提升、网络扫描、挖矿等）。|禁止 wget 执行

有些基础镜像会动态链接 wget 到 /bin/busybox，此情况下还需配合“禁止执行 busybox 命令”策略使用|AppArmor
BPF +| | |禁止通过 curl 命令下载文件

`disable-curl`|ALL|此规则禁止容器进程执行 curl 命令。

攻击者通常会借助 curl 命令发起网络访问、从外部下载攻击程序进行随后的攻击（驻留、权限提升、网络扫描、挖矿等）。|禁止 curl 执行|AppArmor
BPF +| | |禁止通过 chmod 修改文件权限

`disable-chmod`|ALL|此规则禁止容器进程执行 chmod 命令。

当攻击者通过漏洞获取容器内的控制权后，通常会尝试下载其他攻击代码、工具到容器内实施进一步的攻击（权限提升、横向渗透、挖矿等）。在这个攻击链路中，攻击者通常会利用 chmod 命令修改文件的执行权限。|禁止 chmod 执行

有些基础镜像会动态链接 chmod 到 /bin/busybox，此情况下还需配合“禁止执行 busybox 命令”策略使用

（TODO: BPF Enforcer 增加 path_chmod hook 点）|AppArmor
BPF +| | |禁止设置文件的可执行属性

`disable-chmod-x-bit`|ALL|此规则禁止容器进程通过 chmod 相关系统调用修改文件权限，创建可执行文件。

当攻击者通过漏洞获取容器内的控制权后，通常会尝试下载其他攻击代码、工具到容器内实施进一步的攻击（权限提升、横向渗透、挖矿等）。在这个攻击链路中，攻击者通常会调用 chmod 相关系统调用(chmod/fchmod/fchmodat/fchmodat2)，设置文件的可执行权限。|禁止通过 chmod 相关系统调用，设置文件的 execute/search 权限。|Seccomp +| | |禁止设置文件的 SUID/SGID 属性

`disable-chmod-s-bit`|ALL|此规则禁止容器进程通过 chmod 相关系统调用修改文件属性，设置文件的 s 标记位（set-user-ID, set-group-ID）。

在某些场景下，攻击者可能会尝试调用 chmod 系列的系统调用（chmod/fchmod/fchmodat/fchmodat2），通过设置文件的 s 标记位（set-user-ID, set-group-ID）来实施权限提升攻击。|禁止通过 chmod 相关系统调用，设置文件的 set-user-ID/set-group-ID 属性。|Seccomp +| | |禁止执行 sudo、su 命令

`disable-su-sudo`|ALL|此规则禁止容器进程执行 sudo/su 命令进行权限提升。

当容器内的进程以非 root 用户运行时，攻击者需要先提权至 root 用户进行后续攻击。而 sudo/su 命令是本地提权的常见途径之一。|禁止 sudo、su 执行

有些基础镜像会动态链接 su 到 /bin/busybox，此情况下还需配合“禁止执行 busybox 命令”策略使用|AppArmor
BPF +| |限制特定可执行文件|-|ALL|此规则对 “容器信息泄漏缓解” 和 “容器敏感命令限制” 两类策略的使用场景进行了扩充，使用户可以只对容器内的特定可执行文件及其子进程进行限制。

对指定的可执行文件进行限制，实现两个目的：
1). 避免沙箱策略影响容器内应用服务的正常执行
2). 对容器内指定可执行文件进行限制，增加攻击者成本和难度。

例如，可以利用此功能对容器中的 busybox、bash、sh、curl 进行限制，阻止攻击者利用它们来执行敏感操作。与此同时，应用服务的运行则不受沙箱策略的限制，可以正常执行读取 ServiceAccount token 等敏感操作。

注：受限于 BPF LSM 的实现原理，BPF enforcer 无法提供此功能|为特定可执行文件开启沙箱限制|AppArmor +|**Vulnerability Mitigation**|-|缓解 cgroups & lxcfs 逃逸

`cgroups-lxcfs-escape-mitigation`|ALL|若用户将宿主机的 cgroupfs 挂载进容器，或使用 lxcfs 为容器提供资源视图。在这两种场景下可能存在容器逃逸风险，攻击者可以在容器内改写 cgroupfs 实施容器逃逸。

此规则也可用于防御 [CVE-2022-0492](https://unit42.paloaltonetworks.com/cve-2022-0492-cgroups/) 漏洞利用。|AppArmor Enforcer 阻止在容器内修改：
/\*\*/release_agent,
/\*\*/devices/device.allow,
/\*\*/devices/\*\*/device.allow,
/\*\*/devices/cgroup.procs,
/\*\*/devices/\*\*/cgroup.procs,
/\*\*/devices/task,
/\*\*/devices/\*\*/task,

BPF Enforcer 阻止在容器内修改：
/\*\*/release_agent
/\*\*/devices.allow
/\*\*/cgroup.procs
/\*\*/devices/tasks
|AppArmor
BPF +| |-|缓解通过改写 runc 实现的容器逃逸

`runc-override-mitigation`|ALL|本策略用于缓解通过改写宿主机 runc 从而实现容器逃逸的漏洞，例如 [CVE-2019-5736](https://github.com/advisories/GHSA-gxmr-w5mj-v8hh)。|禁止改写 /**/runc 文件|AppArmor
BPF +| |-|缓解利用 Dirty Pipe 漏洞实现的容器逃逸

`dirty-pipe-mitigation`|ALL|本策略用于防御利用 [CVE-2022-0847 (Dirty Pipe)](https://dirtypipe.cm4all.com/) 漏洞进行容器逃逸的攻击，您可以使用此规则在升级内核前对容器进行加固。

注：尽管禁用 splice 系统调用可能会对一些软件包产生问题，但对大多数合法应用来说都不会产生影响，因为这个系统调用的使用相对罕见。|禁止调用 splice syscall|Seccomp |||THIS_IS_A_PLACEHOLDER_PLACEHOLDE| diff --git a/docs/custom_rules.zh_CN.md b/docs/custom_rules.zh_CN.md index 0c9b34ba..5f80a7a6 100644 --- a/docs/custom_rules.zh_CN.md +++ b/docs/custom_rules.zh_CN.md @@ -27,8 +27,8 @@ BPF enforcer 支持用户根据语法定制策略。每类规则的数量上限 | 权限 | 缩写 | 隐含权限 | 备注 | |-----|-----|---------|-----| - |read|r|-
rename
hard link|禁止读
禁止利用 rename **oldpath** newpath 绕过 oldpath 的读限制
禁止利用 ln **TARGET** LINK_NAME 绕过 TARGET 的读限制 - |write|w|-
append
rename
hard link
symbol link
chmod
chown|禁止写
禁止利用 O_APPEND flag 绕过 map_file_to_perms() 实现追加写操作
禁止利用 rename oldpath **newpath** 绕过 newpath 的写限制
禁止利用 ln TARGET **LINK_NAME** 绕过 LINK_NAME 的写限制
禁止利用创建软链接（符号链接）绕过目标文件的写限制
WIP
WIP + |read|r|-
rename
hard link|禁止读
禁止利用 rename **oldpath** newpath 绕过 oldpath 的读限制
禁止利用 ln **TARGET** LINK_NAME 绕过 TARGET 的读限制 + |write|w|-
append
rename
hard link
symbol link
chmod
chown|禁止写
禁止利用 O_APPEND flag 绕过 map_file_to_perms() 实现追加写操作
禁止利用 rename oldpath **newpath** 绕过 newpath 的写限制
禁止利用 ln TARGET **LINK_NAME** 绕过 LINK_NAME 的写限制
禁止利用创建软链接（符号链接）绕过目标文件的写限制
WIP
WIP |exec|x|-|禁止执行 |append|a|-|禁止追加写 @@ -38,8 +38,8 @@ BPF enforcer 支持用户根据语法定制策略。每类规则的数量上限 |通配符|语法|样例|备注| |-----|---|---|----| - |*|- 仅用于匹配叶子结点的文件名
- 匹配 dot 文件，但不匹配 . 和 .. 文件
- 仅支持单个 *，且不支持 \*\* 和 * 一起出现|- fi\* 代表匹配任意以 fi 开头的文件名
- *le 代表匹配任意以 le 结尾的文件名
- *.log 代表匹配任意以 .log 结尾的文件名|此通配符的行为可能会在后续版本中发生改变| - |\**|- 在多级目录中，匹配零个、一个、多个字符
- 匹配 dot 文件，但不匹配 . 和 .. 文件
- 仅支持单个 \*\*，且不支持 ** 和 * 一起出现|- /tmp/\*\*/33 代表匹配任意以 /tmp 开头，且以 /33 结尾的文件，包含 /tmp/33
- /tmp/\*\* 代表匹配任意以 /tmp 开头的文件、目录
- /tm** 代表匹配任意以 /tm 开头的文件、目录
- /t**/33 代表匹配任意以 /t 开头，以 /33 结尾的文件、目录 + |*|- 仅用于匹配叶子结点的文件名
- 匹配 dot 文件，但不匹配 . 和 .. 文件
- 仅支持单个 *，且不支持 \*\* 和 * 一起出现|- fi\* 代表匹配任意以 fi 开头的文件名
- *le 代表匹配任意以 le 结尾的文件名
- *.log 代表匹配任意以 .log 结尾的文件名|此通配符的行为可能会在后续版本中发生改变| + |\**|- 在多级目录中，匹配零个、一个、多个字符
- 匹配 dot 文件，但不匹配 . 和 .. 文件
- 仅支持单个 \*\*，且不支持 ** 和 * 一起出现|- /tmp/\*\*/33 代表匹配任意以 /tmp 开头，且以 /33 结尾的文件，包含 /tmp/33
- /tmp/\*\* 代表匹配任意以 /tmp 开头的文件、目录
- /tm** 代表匹配任意以 /tm 开头的文件、目录
- /t**/33 代表匹配任意以 /t 开头，以 /33 结尾的文件、目录 ### 网络地址匹配 * 当前 vArmor 支持对指定的 IP 地址、IP 地址块（CIDR 块）、端口进行外联访问控制 diff --git a/docs/installation.zh_CN.md b/docs/installation.zh_CN.md index 7dd6d6db..47d9510c 100644 --- a/docs/installation.zh_CN.md +++ b/docs/installation.zh_CN.md @@ -7,8 +7,8 @@ |强制访问控制器|要求|推荐| |------------|--------------------------------------------|--------| -|AppArmor |1. Linux Kernel 4.15 及以上版本
2. 系统需开启 AppArmor LSM|GKE with Container-Optimized OS
AKS with Ubuntu 22.04 LTS
[VKE](https://www.volcengine.com/product/vke) with veLinux 1.0
Debian 10 及以上版本
Ubuntu 18.04.0 LTS 及以上版本
[veLinux 1.0](https://www.volcengine.com/docs/6396/74967) 等 -|BPF |1. Linux Kernel 5.10 及以上版本 (x86_64)
2. containerd v1.6.0 及以上版本
3. 系统需开启 BPF LSM|EKS with Amazon Linux 2
GKE with Container-Optimized OS
[VKE](https://www.volcengine.com/product/vke) with veLinux 1.0 (with 5.10 kernel)
AKS with Ubuntu 22.04 LTS \*
ACK with Alibaba Cloud Linux 3 \*
OpenSUSE 15.4 \*
Debian 11 \*
Fedora 37
[veLinux 1.0 with 5.10 kernel](https://www.volcengine.com/docs/6396/74967) 等

* *需手动启用节点的 BPF LSM* +|AppArmor |1. Linux Kernel 4.15 及以上版本
2. 系统需开启 AppArmor LSM|GKE with Container-Optimized OS
AKS with Ubuntu 22.04 LTS
[VKE](https://www.volcengine.com/product/vke) with veLinux 1.0
Debian 10 及以上版本
Ubuntu 18.04.0 LTS 及以上版本
[veLinux 1.0](https://www.volcengine.com/docs/6396/74967) 等 +|BPF |1. Linux Kernel 5.10 及以上版本 (x86_64)
2. containerd v1.6.0 及以上版本
3. 系统需开启 BPF LSM|EKS with Amazon Linux 2
GKE with Container-Optimized OS
[VKE](https://www.volcengine.com/product/vke) with veLinux 1.0 (with 5.10 kernel)
AKS with Ubuntu 22.04 LTS \*
ACK with Alibaba Cloud Linux 3 \*
OpenSUSE 15.4 \*
Debian 11 \*
Fedora 37
[veLinux 1.0 with 5.10 kernel](https://www.volcengine.com/docs/6396/74967) 等

* *需手动启用节点的 BPF LSM* |Seccomp |1. Kubernetes v1.19 及以上版本|所有 Linux 发行版 ## 安装 diff --git a/docs/interface_specification.md b/docs/interface_specification.md index f6bb8d25..02f28683 100644 --- a/docs/interface_specification.md +++ b/docs/interface_specification.md @@ -6,45 +6,45 @@ English | [简体中文](interface_specification.zh_CN.md) | Field | Subfield | Subfield | Description | |-------|----------|----------|-------------| -|target|kind
*string*|-|Kind is used to specify the type of workloads for the protection targets.
Available values: Deployment, StatefulSet, DaemonSet, Pod -| |name
*string*|-|Optional. Name is used to specify a specific workload name. -| |containers
*string array*|-|Optional. Containers are used to specify the names of the protected containers. If it is empty, sandbox protection will be enabled for all containers within the workload (excluding initContainers and ephemeralContainers). -| |selector
*[LabelSelector](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.26/#labelselector-v1-meta)*|-|Optional. LabelSelector is used to match workloads that meet the specified conditions.
*Note: the type of workloads is determined by the KIND field.* -|policy|enforcer
*string*|-|Enforcer is used to specify which LSM to use for mandatory access control.
Available values: AppArmor, BPF, Seccomp, AppArmorBPF, AppArmorSeccomp, BPFSeccomp, AppArmorBPFSeccomp -| |mode
*string*|-|Used to specify the protection mode.
Available values: AlwaysAllow, RuntimeDefault, EnhanceProtect, BehaviorModeling, DefenseInDepth -| |enhanceProtect|hardeningRules
*string array*|Optional. HardeningRules are used to specify the built-in hardening rules. -| ||attackProtectionRules
*[AttackProtectionRules](interface_specification.md#attackprotectionrules) array*|Optional. AttackProtectionRules are used to specify the built-in attack protection rules. -| ||vulMitigationRules
*string array*|Optional. VulMitigationRules are used to specify the built-in vulnerability mitigation rules. -| ||appArmorRawRules
*string array*|Optional. AppArmorRawRules is used to set custom AppArmor rules, each rule must end with a comma. -| ||bpfRawRules
*[BpfRawRules](interface_specification.md#bpfrawrules)*|Optional. BpfRawRules is used to set custom BPF rules. -| ||syscallRawRules
*[LinuxSyscall](https://pkg.go.dev/github.com/opencontainers/runtime-spec@v1.1.0/specs-go#LinuxSyscall) array*|Optional. SyscallRawRules is used to set the custom syscalls blocklist rules with Seccomp enforcer. -| ||privileged
*bool*|Optional. Privileged is used to identify whether the policy is for the privileged container. If set to `nil` or `false`, vArmor will build AppArmor or BPF profiles on top of the **RuntimeDefault** mode. Otherwise, it will build AppArmor or BPF profiles on top of the **AlwaysAllow** mode. (Default: false)

Note: If set to `true`, vArmor will not build Seccomp profile for the target workloads. +|target|kind
*string*|-|Kind is used to specify the type of workloads for the protection targets.
Available values: Deployment, StatefulSet, DaemonSet, Pod +| |name
*string*|-|Optional. Name is used to specify a specific workload name. +| |containers
*string array*|-|Optional. Containers are used to specify the names of the protected containers. If it is empty, sandbox protection will be enabled for all containers within the workload (excluding initContainers and ephemeralContainers). +| |selector
*[LabelSelector](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.26/#labelselector-v1-meta)*|-|Optional. LabelSelector is used to match workloads that meet the specified conditions.
*Note: the type of workloads is determined by the KIND field.* +|policy|enforcer
*string*|-|Enforcer is used to specify which LSM to use for mandatory access control.
Available values: AppArmor, BPF, Seccomp, AppArmorBPF, AppArmorSeccomp, BPFSeccomp, AppArmorBPFSeccomp +| |mode
*string*|-|Used to specify the protection mode.
Available values: AlwaysAllow, RuntimeDefault, EnhanceProtect, BehaviorModeling, DefenseInDepth +| |enhanceProtect|hardeningRules
*string array*|Optional. HardeningRules are used to specify the built-in hardening rules. +| ||attackProtectionRules
*[AttackProtectionRules](interface_specification.md#attackprotectionrules) array*|Optional. AttackProtectionRules are used to specify the built-in attack protection rules. +| ||vulMitigationRules
*string array*|Optional. VulMitigationRules are used to specify the built-in vulnerability mitigation rules. +| ||appArmorRawRules
*string array*|Optional. AppArmorRawRules is used to set custom AppArmor rules, each rule must end with a comma. +| ||bpfRawRules
*[BpfRawRules](interface_specification.md#bpfrawrules)*|Optional. BpfRawRules is used to set custom BPF rules. +| ||syscallRawRules
*[LinuxSyscall](https://pkg.go.dev/github.com/opencontainers/runtime-spec@v1.1.0/specs-go#LinuxSyscall) array*|Optional. SyscallRawRules is used to set the custom syscalls blocklist rules with Seccomp enforcer. +| ||privileged
*bool*|Optional. Privileged is used to identify whether the policy is for the privileged container. If set to `nil` or `false`, vArmor will build AppArmor or BPF profiles on top of the **RuntimeDefault** mode. Otherwise, it will build AppArmor or BPF profiles on top of the **AlwaysAllow** mode. (Default: false)

Note: If set to `true`, vArmor will not build Seccomp profile for the target workloads. | ||auditViolations
*bool*|Optional. AuditViolations determines whether to audit the actions that violate the mandatory access control rules. Currently, this feature supports AppArmor and BPF enforcers. Any detected violation will be logged to `/var/log/varmor/violations.log` file in the host. (Default: false) -| |modelingOptions|duration
*int*|[Experimental] Duration is the duration in minutes to modeling. -|updateExistingWorkloads
*bool*|-|-|Optional. UpdateExistingWorkloads is used to indicate whether to perform a rolling update on target existing workloads, thus enabling or disabling the protection of the target workloads when policies are created or deleted. (Default: false)

Note: vArmor only performs a rolling update on Deployment, StatefulSet, or DaemonSet type workloads. If `.spec.target.kind` is Pod, you need to rebuild the Pod yourself to enable or disable protection. +| |modelingOptions|duration
*int*|[Experimental] Duration is the duration in minutes to modeling. +|updateExistingWorkloads
*bool*|-|-|Optional. UpdateExistingWorkloads is used to indicate whether to perform a rolling update on target existing workloads, thus enabling or disabling the protection of the target workloads when policies are created or deleted. (Default: false)

Note: vArmor only performs a rolling update on Deployment, StatefulSet, or DaemonSet type workloads. If `.spec.target.kind` is Pod, you need to rebuild the Pod yourself to enable or disable protection. | ||PLACEHOLDER_PLACEHOD| ## AttackProtectionRules | Field | Description | |-------|-------------| -|rules
*string array*|List of built-in attack protection rules to be used. -|targets
*string array*|Optional. Targets are used to specify the workloads to which the policy applies. They must be specified as full paths to executable files, and this feature is only effective when using AppArmor as the enforcer. +|rules
*string array*|List of built-in attack protection rules to be used. +|targets
*string array*|Optional. Targets are used to specify the workloads to which the policy applies. They must be specified as full paths to executable files, and this feature is only effective when using AppArmor as the enforcer. |PLACEHOLDER ## BpfRawRules | Field | Subfield | Description | |-------|----------|-------------| -|files
*FileRule array* |pattern
*string*|Any string (maximum length 128 bytes) that conforms to the policy syntax, used for matching file paths and filenames. -| |permissions
*string array*|Permissions are used to specify the file permissions to be disabled.
Available values: `read(r), write(w), append(a), exec(e)` -|processes
*FileRule array*|-|Same as above. -|network
*NetworkRule* |egresses
*[NetworkEgressRule](interface_specification.md#networkegressrule) array*|Optional. Egresses are the list of egress rules to be applied to restrict particular IPs and ports. -|ptrace
*PtraceRule* |strictMode
*bool*|Optional. If set to false, the processes in the same container will not be restricted. If set to true, even the processes in the same container will be restricted. (Default: false) -| |permissions
*string array*|Prohibited ptrace-related permissions. Available values: `trace, traceby, read, readby`.
- `trace`: Prohibiting process from tracing others.
- `read`: Prohibiting process from reading others.
- `traceby`: Prohibiting process from being traced by others, excluding host processes.
- `readby`: Prohibiting process from being read by others, excluding host processes. -|mounts
*MountRule array* |sourcePattern
*string*|Any string (maximum length 128 bytes) that conforms to the policy syntax, used for matching the source paramater of [MOUNT(2)](https://man7.org/linux/man-pages/man2/mount.2.html), the target paramater of [UMOUNT(2)](https://man7.org/linux/man-pages/man2/umount.2.html), and the from_pathname paramater of MOVE_MOUNT(2). -| |fstype
*string*|Any string (maximum length 16 bytes), used for matching the type of filesystem. `'*'` represents matching any filesystem. -| |flags
*string array*|Prohibited mount flags. They are similar to AppArmor's [MOUNT FLAGS](https://manpages.ubuntu.com/manpages/focal/man5/apparmor.d.5.html), `'all'` represents matching all mount flags.
Available values: `all, ro(r, read-only), rw(w), suid, nosuid, dev, nodev, exec, noexec, sync, async, mand, nomand, dirsync, atime, noatime, diratime, nodiratime, silent, loud, relatime, norelatime, iversion, noiversion, strictatime, nostrictatime, remount, bind(B), move(M), rbind(R), make-unbindable, make-private(private), make-slave(slave), make-shared(shared), make-runbindable, make-rprivate, make-rslave, make-rshared, umount` +|files
*FileRule array* |pattern
*string*|Any string (maximum length 128 bytes) that conforms to the policy syntax, used for matching file paths and filenames. +| |permissions
*string array*|Permissions are used to specify the file permissions to be disabled.
Available values: `read(r), write(w), append(a), exec(e)` +|processes
*FileRule array*|-|Same as above. +|network
*NetworkRule* |egresses
*[NetworkEgressRule](interface_specification.md#networkegressrule) array*|Optional. Egresses are the list of egress rules to be applied to restrict particular IPs and ports. +|ptrace
*PtraceRule* |strictMode
*bool*|Optional. If set to false, the processes in the same container will not be restricted. If set to true, even the processes in the same container will be restricted. (Default: false) +| |permissions
*string array*|Prohibited ptrace-related permissions. Available values: `trace, traceby, read, readby`.
- `trace`: Prohibiting process from tracing others.
- `read`: Prohibiting process from reading others.
- `traceby`: Prohibiting process from being traced by others, excluding host processes.
- `readby`: Prohibiting process from being read by others, excluding host processes. +|mounts
*MountRule array* |sourcePattern
*string*|Any string (maximum length 128 bytes) that conforms to the policy syntax, used for matching the source paramater of [MOUNT(2)](https://man7.org/linux/man-pages/man2/mount.2.html), the target paramater of [UMOUNT(2)](https://man7.org/linux/man-pages/man2/umount.2.html), and the from_pathname paramater of MOVE_MOUNT(2). +| |fstype
*string*|Any string (maximum length 16 bytes), used for matching the type of filesystem. `'*'` represents matching any filesystem. +| |flags
*string array*|Prohibited mount flags. They are similar to AppArmor's [MOUNT FLAGS](https://manpages.ubuntu.com/manpages/focal/man5/apparmor.d.5.html), `'all'` represents matching all mount flags.
Available values: `all, ro(r, read-only), rw(w), suid, nosuid, dev, nodev, exec, noexec, sync, async, mand, nomand, dirsync, atime, noatime, diratime, nodiratime, silent, loud, relatime, norelatime, iversion, noiversion, strictatime, nostrictatime, remount, bind(B), move(M), rbind(R), make-unbindable, make-private(private), make-slave(slave), make-shared(shared), make-runbindable, make-rprivate, make-rslave, make-rshared, umount` |PLACEHOLDER_|PLACEHOLDER_PLACEHOD| @@ -52,7 +52,7 @@ English | [简体中文](interface_specification.zh_CN.md) | Field | Description | |-------|-------------| -|ipBlock
*string*|Optional. IPBlock defines policy on a particular IPBlock with CIDR. If this field is set then neither of the IP field can be. For example:
* 192.168.1.1/24 represents IP addresses within the range of 192.168.1.0 to 192.168.1.255.
* 2001:db8::/32 represents IP addresses within the range of 2001:db8:: to 2001:db8:ffff:ffff:ffff:ffff:ffff:ffff -|ip
*string*|Optional. IP defines policy on a particular IP. If this field is set then neither of the IPBlock field can be. -|port
*int*|Optional. Port defines policy on a particular port. If this field is zero or missing, this rule matches all ports.
Available values: `1 to 65535` +|ipBlock
*string*|Optional. IPBlock defines policy on a particular IPBlock with CIDR. If this field is set then neither of the IP field can be. For example:
* 192.168.1.1/24 represents IP addresses within the range of 192.168.1.0 to 192.168.1.255.
* 2001:db8::/32 represents IP addresses within the range of 2001:db8:: to 2001:db8:ffff:ffff:ffff:ffff:ffff:ffff +|ip
*string*|Optional. IP defines policy on a particular IP. If this field is set then neither of the IPBlock field can be. +|port
*int*|Optional. Port defines policy on a particular port. If this field is zero or missing, this rule matches all ports.
Available values: `1 to 65535` |PLACEHOLDER| diff --git a/docs/interface_specification.zh_CN.md b/docs/interface_specification.zh_CN.md index d2ceb837..64780044 100644 --- a/docs/interface_specification.zh_CN.md +++ b/docs/interface_specification.zh_CN.md @@ -5,52 +5,52 @@ |字段|子字段|子字段|描述| |---|-----|-----|---| -|target|kind
*string*|-|用于指定防护目标的 Workloads 类型。
可用值: Deployment, StatefulSet, DaemonSet, Pod。 -| |name
*string*|-|可选字段，用于指定防护目标的对象名称。 -| |containers
*string array*|-|可选字段，用于指定防护目标的容器名，如果为空默认对 Workloads 中的所有容器开启沙箱防护。（注：不含 initContainers, ephemeralContainers） -| |selector
*[LabelSelector](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.26/#labelselector-v1-meta)*|-|可选字段，用于根据标签选择器识别防护目标，并开启沙箱防护。 -|policy|enforcer
*string*|-|指定要使用的 LSM。
可用值: AppArmor, BPF, Seccomp, AppArmorBPF, AppArmorSeccomp, BPFSeccomp, AppArmorBPFSeccomp -| |mode
*string*|-|用于指定防护模式。
可用值：AlwaysAllow, RuntimeDefault, EnhanceProtect, BehaviorModeling, DefenseInDepth -| |enhanceProtect|hardeningRules
*string array*|可选字段，用于指定要使用的内置加固规则。 -| ||attackProtectionRules
*[AttackProtectionRules](interface_specification.zh_CN.md#attackprotectionrules) array*|可选字段，用于指定要使用的内置规则。 -| ||vulMitigationRules
*string array*|可选字段，用于指定要使用的内置规则。 -| ||appArmorRawRules
*string array*|可选字段，用于设置自定义的 AppArmor 黑名单规则。 -| ||bpfRawRules
*[BpfRawRules](interface_specification.zh_CN.md#bpfrawrules)*|可选字段，用于支持用户设置自定义的 BPF 黑名单规则。 -| ||syscallRawRules
*[LinuxSyscall](https://pkg.go.dev/github.com/opencontainers/runtime-spec@v1.1.0/specs-go#LinuxSyscall) array*|可选字段，用于支持用户使用 Seccomp enforcer 设置自定义的 Syscall 黑名单规则。 -| ||privileged
*bool*|可选字段，若要对特权容器进行加固，请务必将此值设置为 true。若为 `false`，将在 **RuntimeDefault** 模式的基础上构造 AppArmor/BPF Profiles。若为 `ture`，则在 **AlwaysAllow** 模式的基础上构造 AppArmor/BPF Profiles。

注意：当为 `true` 时，vArmor 不会为目标构造 Seccomp Profiles。（默认值：false） +|target|kind
*string*|-|用于指定防护目标的 Workloads 类型。
可用值: Deployment, StatefulSet, DaemonSet, Pod。 +| |name
*string*|-|可选字段，用于指定防护目标的对象名称。 +| |containers
*string array*|-|可选字段，用于指定防护目标的容器名，如果为空默认对 Workloads 中的所有容器开启沙箱防护。（注：不含 initContainers, ephemeralContainers） +| |selector
*[LabelSelector](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.26/#labelselector-v1-meta)*|-|可选字段，用于根据标签选择器识别防护目标，并开启沙箱防护。 +|policy|enforcer
*string*|-|指定要使用的 LSM。
可用值: AppArmor, BPF, Seccomp, AppArmorBPF, AppArmorSeccomp, BPFSeccomp, AppArmorBPFSeccomp +| |mode
*string*|-|用于指定防护模式。
可用值：AlwaysAllow, RuntimeDefault, EnhanceProtect, BehaviorModeling, DefenseInDepth +| |enhanceProtect|hardeningRules
*string array*|可选字段，用于指定要使用的内置加固规则。 +| ||attackProtectionRules
*[AttackProtectionRules](interface_specification.zh_CN.md#attackprotectionrules) array*|可选字段，用于指定要使用的内置规则。 +| ||vulMitigationRules
*string array*|可选字段，用于指定要使用的内置规则。 +| ||appArmorRawRules
*string array*|可选字段，用于设置自定义的 AppArmor 黑名单规则。 +| ||bpfRawRules
*[BpfRawRules](interface_specification.zh_CN.md#bpfrawrules)*|可选字段，用于支持用户设置自定义的 BPF 黑名单规则。 +| ||syscallRawRules
*[LinuxSyscall](https://pkg.go.dev/github.com/opencontainers/runtime-spec@v1.1.0/specs-go#LinuxSyscall) array*|可选字段，用于支持用户使用 Seccomp enforcer 设置自定义的 Syscall 黑名单规则。 +| ||privileged
*bool*|可选字段，若要对特权容器进行加固，请务必将此值设置为 true。若为 `false`，将在 **RuntimeDefault** 模式的基础上构造 AppArmor/BPF Profiles。若为 `ture`，则在 **AlwaysAllow** 模式的基础上构造 AppArmor/BPF Profiles。

注意：当为 `true` 时，vArmor 不会为目标构造 Seccomp Profiles。（默认值：false） | ||auditViolations
*bool*|可选字段. 用于审计违反沙箱策略的行为。此特性当前支持 AppArmor 和 BPF enforcers，任何违反沙箱策略的行为都会被记录到宿主机的 `/var/log/varmor/violations.log` 文件中。（默认值：false） -| |modelingOptions|duration
*int*|动态建模的时间。（单位：分钟）[实验功能] -|updateExistingWorkloads
*bool*|-|-|可选字段，用于指定是否对符合条件的工作负载进行滚动更新，从而在 Policy 创建或删除时，对目标工作负载开启或关闭防护。（默认值：false）

注意：vArmor 只会对 Deployment, StatefulSet, or DaemonSet 类型的工作负载进行滚动更新，如果 `.spec.target.kind` 为 Pod，需要您自行重建 Pod 来开启或关闭防护。 +| |modelingOptions|duration
*int*|动态建模的时间。（单位：分钟）[实验功能] +|updateExistingWorkloads
*bool*|-|-|可选字段，用于指定是否对符合条件的工作负载进行滚动更新，从而在 Policy 创建或删除时，对目标工作负载开启或关闭防护。（默认值：false）

注意：vArmor 只会对 Deployment, StatefulSet, or DaemonSet 类型的工作负载进行滚动更新，如果 `.spec.target.kind` 为 Pod，需要您自行重建 Pod 来开启或关闭防护。 | ||PLACEHOLDER_PLACEHOLD| ## AttackProtectionRules |字段|描述| |---|----| -|rules
*string array*|要使用的内置规则列表。 -|targets
*string array*|可选字段，仅对指定的可执行文件列表开启 Rules 中的内置规则，此功能仅支持 AppArmor enforcer。 +|rules
*string array*|要使用的内置规则列表。 +|targets
*string array*|可选字段，仅对指定的可执行文件列表开启 Rules 中的内置规则，此功能仅支持 AppArmor enforcer。 |PLACEHOLDER| ## BpfRawRules |字段|子字段|描述| |---|-----|---| -|files
*FileRule array* |pattern
*string*|任意符合策略语法的文件路径字符串（最大长度 128 bytes），用于匹配文件路径、文件名称。 -| |permissions
*string array*|禁止使用的权限，其中 write 权限隐式包含 append, rename, hard link, symbol link 权限。
可用值：`read(r), write(w), append(a), exec(e)` -|processes
*FileRule array*|-|同上 -|network
*NetworkRule* |egresses
*[NetworkEgressRule](interface_specification.zh_CN.md#networkegressrule) array*|对外联请求进行访问控制。 -|ptrace
*PtraceRule* |strictMode
*bool*|可选字段，如果设置为 false，同一容器内的进程将不受限制。如果将设置为 true，即使是同一容器内的进程也将受到限制。（默认值：false） -| |permissions
*string array*|禁止使用的权限，可用值: `trace, read, traceby, readby`
- `trace`: 禁止进程跟踪其他进程
- `read`: 禁止进程读取其他进程
- `traceby`: 禁止进程被其他进程跟踪，宿主机进程除外
- `readby`: 禁止进程被其他进程读取，宿主机进程除外 -|mounts
*MountRule array* |sourcePattern
*string*|任意符合策略语法的文件路径字符串（最大长度 128 bytes），用于匹配 [MOUNT(2)](https://man7.org/linux/man-pages/man2/mount.2.html) 的 source，[UMOUNT(2)](https://man7.org/linux/man-pages/man2/umount.2.html) 的 target，以及 MOVE_MOUNT(2) 的 from_pathname。 -| |fstype
*string*|任意字符串（最大长度 16 bytes），用于匹配文件系统类型，`*` 代表匹配任意文件系统。 -| |flags
*string array*|禁止使用的 mount flags，它们与 AppArmor 的 [MOUNT FLAGS](https://manpages.ubuntu.com/manpages/focal/man5/apparmor.d.5.html) 类似，其中 `all` 代表匹配所有 flags。
可用值：`all, ro(r, read-only), rw(w), suid, nosuid, dev, nodev, exec, noexec, sync, async, mand, nomand, dirsync, atime, noatime, diratime, nodiratime, silent, loud, relatime, norelatime, iversion, noiversion, strictatime, nostrictatime, remount, bind(B), move(M), rbind(R), make-unbindable, make-private(private), make-slave(slave), make-shared(shared), make-runbindable, make-rprivate, make-rslave, make-rshared, umount` +|files
*FileRule array* |pattern
*string*|任意符合策略语法的文件路径字符串（最大长度 128 bytes），用于匹配文件路径、文件名称。 +| |permissions
*string array*|禁止使用的权限，其中 write 权限隐式包含 append, rename, hard link, symbol link 权限。
可用值：`read(r), write(w), append(a), exec(e)` +|processes
*FileRule array*|-|同上 +|network
*NetworkRule* |egresses
*[NetworkEgressRule](interface_specification.zh_CN.md#networkegressrule) array*|对外联请求进行访问控制。 +|ptrace
*PtraceRule* |strictMode
*bool*|可选字段，如果设置为 false，同一容器内的进程将不受限制。如果将设置为 true，即使是同一容器内的进程也将受到限制。（默认值：false） +| |permissions
*string array*|禁止使用的权限，可用值: `trace, read, traceby, readby`
- `trace`: 禁止进程跟踪其他进程
- `read`: 禁止进程读取其他进程
- `traceby`: 禁止进程被其他进程跟踪，宿主机进程除外
- `readby`: 禁止进程被其他进程读取，宿主机进程除外 +|mounts
*MountRule array* |sourcePattern
*string*|任意符合策略语法的文件路径字符串（最大长度 128 bytes），用于匹配 [MOUNT(2)](https://man7.org/linux/man-pages/man2/mount.2.html) 的 source，[UMOUNT(2)](https://man7.org/linux/man-pages/man2/umount.2.html) 的 target，以及 MOVE_MOUNT(2) 的 from_pathname。 +| |fstype
*string*|任意字符串（最大长度 16 bytes），用于匹配文件系统类型，`*` 代表匹配任意文件系统。 +| |flags
*string array*|禁止使用的 mount flags，它们与 AppArmor 的 [MOUNT FLAGS](https://manpages.ubuntu.com/manpages/focal/man5/apparmor.d.5.html) 类似，其中 `all` 代表匹配所有 flags。
可用值：`all, ro(r, read-only), rw(w), suid, nosuid, dev, nodev, exec, noexec, sync, async, mand, nomand, dirsync, atime, noatime, diratime, nodiratime, silent, loud, relatime, norelatime, iversion, noiversion, strictatime, nostrictatime, remount, bind(B), move(M), rbind(R), make-unbindable, make-private(private), make-slave(slave), make-shared(shared), make-runbindable, make-rprivate, make-rslave, make-rshared, umount` |PLACEHOLDER_|PLACEHOLDER_PLACEHOD| ## NetworkEgressRule |字段|描述| |---|----| -|ipBlock
*string*|可选字段，可使用任意标准的 CIDR，支持 IPv6。用于对指定 CIDR 范围内的 IP 地址进行外联限制，例如
* 192.168.1.1/24 代表 192.168.1.0 ~ 192.168.1.255 范围内的 IP 地址。
* 2001:db8::/32 代表 2001:db8:: ~ 2001:db8:ffff:ffff:ffff:ffff:ffff:ffff 范围内的 IP 地址。
（注：同一个 NetworkEgressRule 中，IPBlock 和 IP 字段互斥，不能同时出现） -|ip
*string*|可选字段，任意标准的 IP 地址，支持 IPv6，用于对特定的 IP 地址进行外联限制。 -|port
*int*|可选字段，用于对指定的端口进行外联限制，当为空时，默认对（匹配 IP 地址的）所有端口进行外联限制。否则仅对特定端口进行控制。
可用值：`1~65535` +|ipBlock
*string*|可选字段，可使用任意标准的 CIDR，支持 IPv6。用于对指定 CIDR 范围内的 IP 地址进行外联限制，例如
* 192.168.1.1/24 代表 192.168.1.0 ~ 192.168.1.255 范围内的 IP 地址。
* 2001:db8::/32 代表 2001:db8:: ~ 2001:db8:ffff:ffff:ffff:ffff:ffff:ffff 范围内的 IP 地址。
（注：同一个 NetworkEgressRule 中，IPBlock 和 IP 字段互斥，不能同时出现） +|ip
*string*|可选字段，任意标准的 IP 地址，支持 IPv6，用于对特定的 IP 地址进行外联限制。 +|port
*int*|可选字段，用于对指定的端口进行外联限制，当为空时，默认对（匹配 IP 地址的）所有端口进行外联限制。否则仅对特定端口进行控制。
可用值：`1~65535` |PLACEHOLDER| diff --git a/docs/performance_specification.md b/docs/performance_specification.md index f8e46e6f..bf4be16b 100644 --- a/docs/performance_specification.md +++ b/docs/performance_specification.md @@ -20,7 +20,7 @@ vArmor user-space components use the resource quotas as shown in the table below | Version | Manager CPU | Manager Memory | Agent CPU | Agent Memory | | ------- |:-----------:|:--------------:|:-----------:|:-----------------------------------------------------------------------------------------:| -| v0.5.11 | 200m / 100m | 300Mi / 200Mi | 200m / 100m | 100Mi / 40Mi (The BPF enforcer is disabled)
200Mi /100Mi (The BPF enforcer is enabled) | +| v0.5.11 | 200m / 100m | 300Mi / 200Mi | 200m / 100m | 100Mi / 40Mi (The BPF enforcer is disabled)
200Mi /100Mi (The BPF enforcer is enabled) | Explanation: diff --git a/docs/performance_specification.zh_CN.md b/docs/performance_specification.zh_CN.md index 44621172..c3449046 100644 --- a/docs/performance_specification.zh_CN.md +++ b/docs/performance_specification.zh_CN.md @@ -8,10 +8,10 @@ vArmor 的用户态组件和内核态组件对性能的影响因素如下表所 | 因素 | 说明 | | --- | ---- | | 集群规模 | 集群规模越大，Manager 管理 Agent 所消耗的 CPU 和 内存越多 | -| VarmorPolicy 数量和操作频率 | 大量创建 VarmorPolicy CR 时，Manager 会消耗更多的 CPU 和内存进行响应
频繁创建/修改/删除 VarmorPolicy CR 时，Manager 和 Agent 会消耗更多的 CPU 和内存进行响应 | -| AppArmor LSM | 开启 AppArmor LSM 为进程引入的基础开销
Profile 中的规则越多，对目标进程的性能影响越大| -| BPF LSM | 开启 BPF LSM 为进程引入的基础开销
Profile 中的规则越多，对目标进程的性能影响越大 | -| Seccomp | 开启 Seccomp 为进程引入的基础开销
Profile 中的规则越多，对目标进程的性能影响越大 | +| VarmorPolicy 数量和操作频率 | 大量创建 VarmorPolicy CR 时，Manager 会消耗更多的 CPU 和内存进行响应
频繁创建/修改/删除 VarmorPolicy CR 时，Manager 和 Agent 会消耗更多的 CPU 和内存进行响应 | +| AppArmor LSM | 开启 AppArmor LSM 为进程引入的基础开销
Profile 中的规则越多，对目标进程的性能影响越大| +| BPF LSM | 开启 BPF LSM 为进程引入的基础开销
Profile 中的规则越多，对目标进程的性能影响越大 | +| Seccomp | 开启 Seccomp 为进程引入的基础开销
Profile 中的规则越多，对目标进程的性能影响越大 | ## 资源占用 @@ -19,7 +19,7 @@ vArmor 用户态组件默认使用下表所示的值进行资源申请 | Version | Manager CPU | Manager Memory | Agent CPU | Agent Memory | | ------- |:-----------:|:--------------:|:-----------:|:--------------------------------------------------------------------:| -| v0.5.11 | 200m / 100m | 300Mi / 200Mi | 200m / 100m | 100Mi / 40Mi (关闭 BPF enforcer 时)
200Mi /100Mi (开启 BPF enforcer 时) | +| v0.5.11 | 200m / 100m | 300Mi / 200Mi | 200m / 100m | 100Mi / 40Mi (关闭 BPF enforcer 时)
200Mi /100Mi (开启 BPF enforcer 时) | 说明： diff --git a/docs/usage_instructions.zh_CN.md b/docs/usage_instructions.zh_CN.md index b42005f4..40d04ff5 100644 --- a/docs/usage_instructions.zh_CN.md +++ b/docs/usage_instructions.zh_CN.md @@ -37,10 +37,10 @@ vArmor 支持在创建或删除 VarmorPolicy/VarmorClusterPolicy 对象时，对 | |Modeling|正在对目标应用行为建模 | |Completed|已完成目标应用的行为建模 | |Error|处理出错，请查看 Conditions 相关信息获取错误原因 - |Conditions|Type=Created
Status=True|VarmorPolicy 的创建事件已经被 controller 响应，且处理成功 - | |Type=Created
Status=False
Reason=XXX
Message=YYY|VarmorPolicy 的创建事件已经被 controller 响应，但处理失败。包含失败的原因及错误信息 - | |Type=Updated
Status=True|VarmorPolicy 的更新事件已经被 controller 响应，且处理成功 - | |Type=Updated
Status=False
Reason=XXX
Message=YYY|VarmorPolicy 的更新事件已经被 controller 响应，但处理失败。包含失败的原因及错误信息 + |Conditions|Type=Created
Status=True|VarmorPolicy 的创建事件已经被 controller 响应，且处理成功 + | |Type=Created
Status=False
Reason=XXX
Message=YYY|VarmorPolicy 的创建事件已经被 controller 响应，但处理失败。包含失败的原因及错误信息 + | |Type=Updated
Status=True|VarmorPolicy 的更新事件已经被 controller 响应，且处理成功 + | |Type=Updated
Status=False
Reason=XXX
Message=YYY|VarmorPolicy 的更新事件已经被 controller 响应，但处理失败。包含失败的原因及错误信息 |Ready|True|Profile 已经被所有的 Agents 处理和加载 | |False|Profile 还未被所有的 Agents 处理和加载 @@ -60,7 +60,7 @@ vArmor 支持在创建或删除 VarmorPolicy/VarmorClusterPolicy 对象时，对 |---|--|---| |DesiredNumberLoaded|int|期望处理并响应的 Agent 数量 |CurrentNumberLoaded|int|已经处理并响应的 Agent 数量 - |Conditions|type=Read
Status=False
NodeName=XXX
Message=YYY|处理失败的节点，以及错误信息 + |Conditions|type=Read
Status=False
NodeName=XXX
Message=YYY|处理失败的节点，以及错误信息 ## 示例