Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

KubeArmor: Inconsistent Log Generation for Blocked Processes with Default Posture Block #1843

Open
yeranosyanvahan opened this issue Aug 15, 2024 · 1 comment
Open

KubeArmor: Inconsistent Log Generation for Blocked Processes with Default Posture Block #1843

yeranosyanvahan opened this issue Aug 15, 2024 · 1 comment
Labels
bug Something isn't working

Comments

@yeranosyanvahan
Copy link

Description:

There is an issue with KubeArmor version 1.4.0 where logs are not generated for blocked processes when a namespace is configured with a default block posture. Logs are only generated after explicitly adding an Allow policy for the entrypoint process.

Steps to Reproduce:

  1. Install KubeArmor 1.4.0 in a Kubernetes cluster. (details of the system below)
  2. Apply the following block posture annotations on a namespace: 
    apiVersion: v1
kind: Namespace
metadata:
  name: test-wordpress-block
  annotations:
    kubearmor-visibility: process,file,network
    kubearmor-file-posture: block
    kubearmor-network-posture: block
    kubearmor-capabilities-posture: block
  3. Deploy a pod within the namespace (e.g., a Bitnami WordPress container).
apiVersion: helm.cattle.io/v1
kind: HelmChart
metadata:
  name: wordpress-testblock-release
spec:
  chart: oci://registry-1.docker.io/bitnamicharts/wordpress
  targetNamespace: test-wordpress-block
  version: 23.1.1
  set:
    mariadb.enabled: "false"
    service.type: ClusterIP
    serviceAccount.create: "false"
#    global.storageClass: host-storageclass
  valuesContent: |-
    replicaCount: 1
    wordpressSkipInstall: false
    persistence:
      enabled: true
      storageClass: local-path
      size: 900Mi
    podLabels:
      test-kubarmor-policy: test-wordpress-block
    startupProbe:
      enabled: true
      initialDelaySeconds: 600
      periodSeconds: 10
      timeoutSeconds: 5
      failureThreshold: 9
      successThreshold: 1
  1. Observe that no logs are generated for blocked processes by default.
    pod logs
/bin/bash: /opt/bitnami/scripts/wordpress/entrypoint.sh: Permission denied

Byt

root@machine:~# karmor logs --namespace test-wordpress-block
local port to be used for port forwarding kubearmor-relay-5b5458dfd8-99r8g: 32768
Created a gRPC client (localhost:32768)
Checked the liveness of the gRPC server
Started to watch alerts
  1. Add an Allow policy for the entrypoint process: 
    apiVersion: security.kubearmor.com/v1
kind: KubeArmorPolicy
metadata:
  name: test-wordpress-block
  namespace: test-wordpress-block
spec:
  action: Allow
  message: "Permissive Allow test-wordpress-block Policy"
  selector:
    matchLabels:
      test-kubarmor-policy: test-wordpress-block
  process:
    matchPaths:
    - path: /opt/bitnami/apache/bin/httpd
    - path: /opt/bitnami/scripts/wordpress/entrypoint.sh
  2. Observe that logs start to be generated for blocked processes only after the Allow policy is added.
== Alert / 2024-08-13 16:42:20.234088 ==
ClusterName: default
HostName: machine
NamespaceName: test-wordpress-block
PodName: wordpress-testblock-release-74cc44cc9-wdzhr
ContainerName: 5dc3977894375ab65d87112821295505a0ca664c48e63bee248bf40e0d161091
ContainerID: 5dc3977894375ab65d87112821295505a0ca664c48e63bee248bf40e0d161091
Type: MatchedPolicy
PolicyName: DefaultPosture
Source: /opt/bitnami/scripts/wordpress/entrypoint.sh /opt/bitnami/scripts/apache/run.sh
Resource: /opt/bitnami/scripts/wordpress/entrypoint.sh
Operation: File
Action: Block
Data: syscall=SYS_OPENAT fd=-100 flags=O_RDONLY
Enforcer: eBPF Monitor
Result: Permission denied
Cwd: /
HostPID: 7535
HostPPID: 6746
Owner: map[Name:wordpress-testblock-release Namespace:test-wordpress-block Ref:Deployment]
PID: 1
PPID: 0
ParentProcessName: /var/lib/rancher/k3s/data/ad0d9298586ea865d9e35bf77eff7a64ab4d2b2fc0430eefb226e6c04b8b9bba/bin/containerd-shim-runc-v2
ProcessName: /usr/bin/bash
UID: 1001

** NOTE: This is the permission denied for a File, not a process, so we need to enable that as well

apiVersion: security.kubearmor.com/v1
kind: KubeArmorPolicy
metadata:
  name: test-wordpress-block
  namespace: test-wordpress-block
spec:
  action: Allow
  message: "Permissive Allow test-wordpress-block Policy"
  selector:
    matchLabels:
      test-kubarmor-policy: test-wordpress-block
  process:
    matchPaths:
    - path: /opt/bitnami/apache/bin/httpd
    - path: /opt/bitnami/scripts/wordpress/entrypoint.sh
  file:
    matchPaths:
    - path: /opt/bitnami/scripts/wordpress/entrypoint.sh

Now, kubearmor works as expected, because entrypoint is permitted

Expected Behavior:

KubeArmor should generate logs for blocked entrypoint process when a default block posture is applied to a namespace.

Actual Behavior:

  • No logs are generated for blocked processes when only the default block posture is applied.
  • Logs are generated only after adding an Allow policy for the entrypoint process.

Environment:

  • KubeArmor Version: 1.4.0
  • Kubernetes Version: v1.28.11+k3s2
  • Operating System: Debian GNU/Linux 11 (bullseye)
  • Container Runtime: containerd://1.7.17-k3s1.28
  • Kernel Version: 5.10.0-32-amd64
@yeranosyanvahan yeranosyanvahan added the bug Something isn't working label Aug 15, 2024
@yeranosyanvahan
Copy link
Author

Full kubernetes yaml file

apiVersion: v1
kind: Namespace
metadata:
  name: kubearmor-operator
  labels:
    project: infra
    group: operator
---
apiVersion: helm.cattle.io/v1
kind: HelmChart
metadata:
  name: operator-kubearmor-release
spec:
  repo: https://kubearmor.github.io/charts
  chart: kubearmor-operator
  targetNamespace: kubearmor-operator
  version: 1.4.0
--- #kubectl apply -f https://raw.githubusercontent.com/kubearmor/KubeArmor/main/pkg/KubeArmorOperator/config/samples/sample-config.yml
apiVersion: operator.kubearmor.com/v1
kind: KubeArmorConfig
metadata:
  labels:
    app.kubernetes.io/name: kubearmorconfig
    app.kubernetes.io/instance: kubearmorconfig-sample
    app.kubernetes.io/part-of: kubearmoroperator
    app.kubernetes.io/managed-by: kustomize
    app.kubernetes.io/created-by: kubearmoroperator
  name: kubearmorconfig-default
  namespace: kubearmor-operator
spec:
  defaultCapabilitiesPosture: audit
  defaultFilePosture: audit
  defaultNetworkPosture: audit
  defaultVisibility: process,network
  enableStdOutLogs: false
  enableStdOutAlerts: false
  enableStdOutMsgs: false
  seccompEnabled: false
  alertThrottling: false
  maxAlertPerSec: 10
  throttleSec: 30
  kubearmorImage:
    image: kubearmor/kubearmor:stable
    imagePullPolicy: Always
  kubearmorInitImage:
    image: kubearmor/kubearmor-init:stable
    imagePullPolicy: Always
  kubearmorRelayImage:
    image: kubearmor/kubearmor-relay-server
    imagePullPolicy: Always
  kubearmorControllerImage:
    image: kubearmor/kubearmor-controller
    imagePullPolicy: Always


---
apiVersion: v1
kind: Namespace
metadata:
  name: test-wordpress-block
  annotations:
    kubearmor-visibility: process,file,network
    kubearmor-file-posture: block
    kubearmor-network-posture: block
    kubearmor-capabilities-posture: block
  labels:
    project: block
    group: wordpress
---
apiVersion: helm.cattle.io/v1
kind: HelmChart
metadata:
  name: wordpress-testblock-release
spec:
  chart: oci://registry-1.docker.io/bitnamicharts/wordpress
  targetNamespace: test-wordpress-block
  version: 23.1.1
  set:
    mariadb.enabled: "false"
    service.type: ClusterIP
    serviceAccount.create: "false"
#    global.storageClass: host-storageclass
  valuesContent: |-
    replicaCount: 1
    wordpressSkipInstall: false
    persistence:
      enabled: true
      storageClass: local-path
      size: 900Mi
    podLabels:
      test-kubarmor-policy: test-wordpress-block
    startupProbe:
      enabled: true
      initialDelaySeconds: 600
      periodSeconds: 10
      timeoutSeconds: 5
      failureThreshold: 9
      successThreshold: 1
---
apiVersion: v1
kind: Namespace
metadata:
  name: test-wordpress-block
  annotations:
    kubearmor-visibility: process,file,network
    kubearmor-file-posture: block
    kubearmor-network-posture: block
    kubearmor-capabilities-posture: block
  labels:
    project: block
    group: wordpress
---
apiVersion: security.kubearmor.com/v1
kind: KubeArmorPolicy
metadata:
  name: test-wordpress-block-nolog
  namespace: test-wordpress-block
spec:
  action: Allow
  message: "Doesn't generate any logs because entrypoint is blocked"
  selector:
    matchLabels:
      test-kubarmor-policy: test-wordpress-block
  process:
    matchPaths:
    - path: /opt/bitnami/apache/bin/httpd
---
apiVersion: security.kubearmor.com/v1
kind: KubeArmorPolicy
metadata:
  name: test-wordpress-block-worksgreat
  namespace: test-wordpress-block
spec:
  action: Allow
  message: "Generates logs because entrypoint is permitted"
  selector:
    matchLabels:
      test-kubarmor-policy: test-wordpress-block
  process:
    matchPaths:
    - path: /opt/bitnami/apache/bin/httpd
    - path: /opt/bitnami/scripts/wordpress/entrypoint.sh
  file:
    matchDirectories:
    - dir: /opt/bitnami/scripts/wordpress/entrypoint.sh
```

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
bug Something isn't working
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
1 participant
@yeranosyanvahan