{"_kubernetes_io":{"feed_refresh_job":"https://testgrid.k8s.io/sig-security-cve-feed#auto-refreshing-official-cve-feed","updated_at":"2025-12-26T00:15:22Z"},"authors":[{"name":"Kubernetes Community...

This page shows you how to run a single-instance stateful application in Kubernetes using a PersistentVolume and a Deployment. The application is MySQL. Objectives Create a PersistentVolume referencing a disk in your environment. Create a MySQL Deployment. Expose MySQL to other pods in the cluster at a known DNS name. Before you begin You need to have a Kubernetes cluster, and the kubectl command-line tool must be configured to communicate with your cluster.

A security context defines privilege and access control settings for a Pod or Container. Security context settings include, but are not limited to: Discretionary Access Control: Permission to access an object, like a file, is based on user ID (UID) and group ID (GID). Security Enhanced Linux (SELinux): Objects are assigned security labels. Running as privileged or unprivileged. Linux Capabilities: Give a process some privileges, but not all the privileges of the root user.

Use kubectl patch to update Kubernetes API objects in place. Do a strategic merge patch or a JSON merge patch.

FEATURE STATE: Kubernetes v1.26 [stable] Windows HostProcess containers enable you to run containerized workloads on a Windows host. These containers operate as normal processes but have access to the host network namespace, storage, and devices when given the appropriate user privileges. HostProcess containers can be used to deploy network plugins, storage configurations, device plugins, kube-proxy, and other components to Windows nodes without the need for dedicated proxies or the direct installation of host services.

This page provides an overview of authentication in Kubernetes, with a focus on authentication to the Kubernetes API. Users in Kubernetes All Kubernetes clusters have two categories of users: service accounts managed by Kubernetes, and normal users. It is assumed that a cluster-independent service manages normal users in the following ways: an administrator distributing private keys a user store like Keystone or Google Accounts a file with a list of usernames and passwords In this regard, Kubernetes does not have objects which represent normal user accounts.

Overview A kubelet's HTTPS endpoint exposes APIs which give access to data of varying sensitivity, and allow you to perform operations with varying levels of power on the node and within containers. This document describes how to authenticate and authorize access to the kubelet's HTTPS endpoint. Kubelet authentication By default, requests to the kubelet's HTTPS endpoint that are not rejected by other configured authentication methods are treated as anonymous requests, and given a username of system:anonymous and a group of system:unauthenticated.

A ServiceAccount provides an identity for processes that run in a Pod. A process inside a Pod can use the identity of its associated service account to authenticate to the cluster's API server. For an introduction to service accounts, read configure service accounts. This task guide explains some of the concepts behind ServiceAccounts. The guide also explains how to obtain or revoke tokens that represent ServiceAccounts, and how to (optionally) bind a ServiceAccount's validity to the lifetime of an API object.

FEATURE STATE: Kubernetes v1.22 [stable](enabled by default) Kubernetes supports multiple appliers collaborating to manage the fields of a single object. Server-Side Apply provides an optional mechanism for your cluster's control plane to track changes to an object's fields. At the level of a specific resource, Server-Side Apply records and tracks information about control over the fields of that object. Server-Side Apply helps users and controllers manage their resources through declarative configuration.

This document details the deprecation policy for various facets of the system. Kubernetes is a large system with many components and many contributors. As with any such software, the feature set naturally evolves over time, and sometimes a feature may need to be removed. This could include an API, a flag, or even an entire feature. To avoid breaking existing users, Kubernetes follows a deprecation policy for aspects of the system that are slated to be removed.