#kubernetes

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 ...

Cybersecurity researchers have disclosed a security flaw impacting Microsoft Azure Kubernetes Services that, if successfully exploited, could allow an attacker to escalate their privileges and access credentials for services used by the cluster. "An attacker with command execution in a Pod running within an affected Azure Kubernetes Services cluster could download the configuration used to

One of the key components of a container-based architecture is security.There are many facets to it (just have a look at the list of topics in the official OpenShift documentation here), but some of the most basic requirements are authentication and authorization. In this article, I explain how authentication and authorization work in Kubernetes and Red Hat OpenShift. I cover interactions between the different layers of a Kubernetes ecosystem, including the infrastructure layer, Kubernetes layer, and the containerized applications layer.What is authentication and authorization?In simple terms,

Confidential containers are containers deployed within a Trusted Execution Environment (TEE), which allows you to protect your application code and secrets when deployed in untrusted environments. In our previous articles, we introduced the Red Hat OpenShift confidential containers (CoCo) solution and relevant use cases. We demonstrated how components of the CoCo solution, spread across trusted and untrusted environments, including confidential virtual machine (CVM), guest components, TEEs, Confidential compute attestation operator, Trustee agents, and more, work together as part of the soluti