#kubernetes

Red Hat OpenShift sandboxed containers, built on Kata Containers, now provide the additional capability to run confidential containers (CoCo). Confidential Containers are containers deployed within an isolated hardware enclave protecting data and code from privileged users such as cloud or cluster administrators. The CNCF Confidential Containers project is the foundation for the OpenShift CoCo solution. You can read more about the CNCF CoCo project in our previous blog What is the Confidential Containers project?Confidential Containers are available from OpenShift sandboxed containers release

Red Hat Summit, the premier open source event, reached new heights this past May by ascending to the Mile High City of Denver Colorado. The mix of Red Hat customers, enthusiasts and members of the open source community made for an ideal location for the latest OpenShift Commons Gathering. Similar to other OpenShift Commons Gathering events, it occurred as a day-0 event prior to the actual start of Red Hat Summit. But, what made this event extra special was that it also coincided with the first ever Community Day that brought together the communities driving Red Hat OpenShift, Red Hat Enterpris

Red Hat Security Advisory 2024-5446-03 - Red Hat OpenShift Container Platform release 4.13.48 is now available with updates to packages and images that fix several bugs and add enhancements. Issues addressed include a memory exhaustion vulnerability.

Red Hat Security Advisory 2024-5444-03 - Red Hat OpenShift Container Platform release 4.13.48 is now available with updates to packages and images that fix several bugs and add enhancements. Issues addressed include code execution and memory exhaustion vulnerabilities.

Red Hat Security Advisory 2024-5442-03 - Red Hat OpenShift Container Platform release 4.15.28 is now available with updates to packages and images that fix several bugs and add enhancements. Issues addressed include a memory exhaustion vulnerability.

Red Hat Security Advisory 2024-5439-03 - Red Hat OpenShift Container Platform release 4.15.28 is now available with updates to packages and images that fix several bugs and add enhancements. Issues addressed include a memory exhaustion vulnerability.

Red Hat Security Advisory 2024-5436-03 - Red Hat OpenShift Container Platform release 4.14.35 is now available with updates to packages and images that fix several bugs and add enhancements. Issues addressed include a memory exhaustion vulnerability.

Red Hat Security Advisory 2024-5433-03 - Red Hat OpenShift Container Platform release 4.14.35 is now available with updates to packages and images that fix several bugs and add enhancements. Issues addressed include denial of service and memory exhaustion vulnerabilities.

### Details The kanister has a deployment called default-kanister-operator, which is bound with a ClusterRole called edit via ClusterRoleBinding(https://github.com/kanisterio/kanister/blob/master/helm/kanister-operator/templates/rbac.yaml#L49). The "edit" ClusterRole is one of Kubernetes default-created ClusterRole, and it have create/patch/udpate verbs of daemonset resources, create verb of serviceaccount/token resources, and impersonate verb of serviceaccounts resources. If a malicious user can access the worker node which has this component, he/she can: For the create/patch/update verbs of daemonset resources, the malicious user can abuse it to create or modify a set of Pods to mount a high-privilege service account (e.g., the cluster-admin service account). After that, he/she can abuse the high-privilege SA token of created Pod to take over the whole cluster. For the create verb of serviceaccount/token resources, a malicious user can abuse this permission to generate new Service ...

# Attack Vector Then, let me briefly explain the reasons for the errors mentioned above: 1. The 'kubectl edit' command was used to patch the namespace, but this operation requires both 'get' and 'patch' permissions, hence the error. One should use methods like 'curl' to directly send a PATCH request; 2. The webhook does not intercept patch operations on 'kube-system' because 'kube-system' does not have an ownerReference. # Below are my detailed reproduction steps 1. Create a test cluster `kind create cluster --image=kindest/node:v1.24.15 --name=k8s` 2. Install the capsule `helm install capsule projectcapsule/capsule -n capsule-system --create-namespace` 3. Create a tenant ``` kubectl create -f - << EOF apiVersion: capsule.clastix.io/v1beta2 kind: Tenant metadata: name: tenant1 spec: owners: - name: alice kind: User EOF ``` 4. Create user alice ``` ./create-user.sh alice tenant1 capsule.clastix.io export KUBECONFIG=alice-tenant1.kubeconfig ``` 5. Patch kube-system (The first ...