#kubernetes

This is release 1.4 of the rpms for Red Hat Service Interconnect. Red Hat Service Interconnect 1.4 introduces a service network, linking TCP and HTTP services across the hybrid cloud. A service network enables communication between services running in different network locations or sites. It allows geographically distributed services to connect as if they were all running in the same site. Red Hat Product Security has rated this update as having a security impact of Moderate. A Common Vulnerability Scoring System (CVSS) base score, which gives a detailed severity rating, is available for each vulnerability from the CVE link(s) in the References section.This content is licensed under the Creative Commons Attribution 4.0 International License (https://creativecommons.org/licenses/by/4.0/). If you distribute this content, or a modified version of it, you must provide attribution to Red Hat Inc. and provide a link to the original. Related CVEs: * CVE-2022-2879: A flaw was found in the gol...

As the world's leading provider of enterprise-ready open source software, Red Hat is uniquely positioned to help prepare the widely varying users of its embedded platform cryptography for the transition to a post-quantum world. In fact, the US Government calls it "imperative" in a recent National Security Memorandum: [Becoming quantum-ready is] imperative across all sectors of the United States economy, from government to critical infrastructure, commercial services to cloud providers, and everywhere else that vulnerable public-key cryptography is used — NSM-10 Part of Red Hat's

Peer-pods is a new Red Hat OpenShift feature that enables an OpenShift sandboxed container (OSC) running on a bare-metal deployment to run on OpenShift in a public cloud and on VMware. It's not uncommon to want to run OpenShift in a virtual machine instead of on the bare-metal nodes. While it's possible to run a virtual machine inside a virtual machine, it demands a whole new subset of support concerns when you do it in production. In this article, I'll demonstrate how to solve this problem, using a combination of peer-pods and libvirt. By the end of this tutorial, you'll know how to create a

### Summary Pipelines do not validate child UIDs, which means that a user that has access to create TaskRuns can create their own Tasks that the Pipelines controller will accept as the child Task. We should add UID to PipelineRun status and validate that child Run status/results only come from Runs matching the same UID. ### Details While we [store and validate the PipelineRun's (api version, kind, name, uid) in the child Run's OwnerReference](https://github.com/tektoncd/pipeline/blob/2d38f5fa840291395178422d34b36b1bc739e2a2/pkg/reconciler/pipelinerun/pipelinerun.go#L1358-L1372), we only store (api version, kind, name) in the [ChildStatusReference](https://pkg.go.dev/github.com/tektoncd/pipeline/pkg/apis/pipeline/v1beta1#ChildStatusReference) . This means that if a client had access to create TaskRuns on a cluster, they could create a child TaskRun for a pipeline with the same name + owner reference, and the Pipeline controller picks it up as if it was the original TaskRun. This is...

Tekton Pipelines project provides k8s-style resources for declaring CI/CD-style pipelines. Starting in version 0.35.0, pipelines do not validate child UIDs, which means that a user that has access to create TaskRuns can create their own Tasks that the Pipelines controller will accept as the child Task. While the software stores and validates the PipelineRun's (api version, kind, name, uid) in the child Run's OwnerReference, it only store (api version, kind, name) in the ChildStatusReference. This means that if a client had access to create TaskRuns on a cluster, they could create a child TaskRun for a pipeline with the same name + owner reference, and the Pipeline controller picks it up as if it was the original TaskRun. This is problematic since it can let users modify the config of Pipelines at runtime, which violates SLSA L2 Service Generated / Non-falsifiable requirements. This issue can be used to trick the Pipeline controller into associating unrelated Runs to the Pipeline, feedi...

Red Hat Security Advisory 2023-3925-01 - Red Hat OpenShift Container Platform is Red Hat's cloud computing Kubernetes application platform solution designed for on-premise or private cloud deployments. This advisory contains the container images for Red Hat OpenShift Container Platform 4.12.23.

Red Hat Security Advisory 2023-3924-01 - Red Hat OpenShift Container Platform is Red Hat's cloud computing Kubernetes application platform solution designed for on-premise or private cloud deployments. This advisory contains the RPM packages for Red Hat OpenShift Container Platform 4.12.23.

Arbitrary code execution in Apache Airflow CNCF Kubernetes provider version 5.0.0 allows user to change xcom sidecar image and resources via Airflow connection. In order to exploit this weakness, a user would already need elevated permissions (Op or Admin) to change the connection object in this manner. Operators should upgrade to provider version 7.0.0 which has removed the vulnerability.

authentik is an open-source Identity Provider. Prior to versions 2023.4.3 and 2023.5.5, authentik does not verify the source of the X-Forwarded-For and X-Real-IP headers, both in the Python code and the go code. Only authentik setups that are directly accessible by users without a reverse proxy are susceptible to this. Possible spoofing of IP addresses in logs, downstream applications proxied by (built in) outpost, IP bypassing in custom flows if used. This poses a possible security risk when someone has flows or policies that check the user's IP address, e.g. when they want to ignore the user's 2 factor authentication when the user is connected to the company network. A second security risk is that the IP addresses in the logfiles and user sessions are not reliable anymore. Anybody can spoof this address and one cannot verify that the user has logged in from the IP address that is in their account's log. A third risk is that this header is passed on to the proxied application behind ...

Red Hat OpenShift Container Platform release 4.12.23 is now available with updates to packages and images that fix several bugs and add enhancements. This release includes a security update for Red Hat OpenShift Container Platform 4.12. Red Hat Product Security has rated this update as having a security impact of Moderate. A Common Vulnerability Scoring System (CVSS) base score, which gives a detailed severity rating, is available for each vulnerability from the CVE link(s) in the References section.This content is licensed under the Creative Commons Attribution 4.0 International License (https://creativecommons.org/licenses/by/4.0/). If you distribute this content, or a modified version of it, you must provide attribution to Red Hat Inc. and provide a link to the original. Related CVEs: * CVE-2023-3089: A compliance problem was found in the Red Hat OpenShift Container Platform. Red Hat discovered that, when FIPS mode was enabled, not all of the cryptographic modules in use were FIPS-...