{
	"id": "cc4c2b63-470b-4f72-8ca4-59a96ab1ba7b",
	"created_at": "2026-04-06T01:32:21.884315Z",
	"updated_at": "2026-04-10T03:21:25.283001Z",
	"deleted_at": null,
	"sha1_hash": "790d64f50f0bd1ae59f969231e02f93cf12fad23",
	"title": "Controlling Access to the Kubernetes API",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 143275,
	"plain_text": "Controlling Access to the Kubernetes API\r\nBy Authorization\r\nArchived: 2026-04-06 00:49:01 UTC\r\nThis page provides an overview of controlling access to the Kubernetes API.\r\nUsers access the Kubernetes API using kubectl , client libraries, or by making REST requests. Both human users\r\nand Kubernetes service accounts can be authorized for API access. When a request reaches the API, it goes\r\nthrough several stages, illustrated in the following diagram:\r\nTransport security\r\nBy default, the Kubernetes API server listens on port 6443 on the first non-localhost network interface, protected\r\nby TLS. In a typical production Kubernetes cluster, the API serves on port 443. The port can be changed with the\r\n--secure-port , and the listening IP address with the --bind-address flag.\r\nThe API server presents a certificate. This certificate may be signed using a private certificate authority (CA), or\r\nbased on a public key infrastructure linked to a generally recognized CA. The certificate and corresponding\r\nprivate key can be set by using the --tls-cert-file and --tls-private-key-file flags.\r\nIf your cluster uses a private certificate authority, you need a copy of that CA certificate configured into your\r\n~/.kube/config on the client, so that you can trust the connection and be confident it was not intercepted.\r\nYour client can present a TLS client certificate at this stage.\r\nhttps://kubernetes.io/docs/concepts/security/controlling-access/\r\nPage 1 of 4\n\nAuthentication\r\nOnce TLS is established, the HTTP request moves to the Authentication step. This is shown as step 1 in the\r\ndiagram. The cluster creation script or cluster admin configures the API server to run one or more Authenticator\r\nmodules. Authenticators are described in more detail in Authentication.\r\nThe input to the authentication step is the entire HTTP request; however, it typically examines the headers and/or\r\nclient certificate.\r\nAuthentication modules include client certificates, password, and plain tokens, bootstrap tokens, and JSON Web\r\nTokens (used for service accounts).\r\nMultiple authentication modules can be specified, in which case each one is tried in sequence, until one of them\r\nsucceeds.\r\nIf the request cannot be authenticated, it is rejected with HTTP status code 401. Otherwise, the user is\r\nauthenticated as a specific username , and the user name is available to subsequent steps to use in their decisions.\r\nSome authenticators also provide the group memberships of the user, while other authenticators do not.\r\nWhile Kubernetes uses usernames for access control decisions and in request logging, it does not have a User\r\nobject nor does it store usernames or other information about users in its API.\r\nAfter the request is authenticated as coming from a specific user, the request must be authorized. This is shown as\r\nstep 2 in the diagram.\r\nA request must include the username of the requester, the requested action, and the object affected by the action.\r\nThe request is authorized if an existing policy declares that the user has permissions to complete the requested\r\naction.\r\nFor example, if Bob has the policy below, then he can read pods only in the namespace projectCaribou :\r\n{\r\n \"apiVersion\": \"abac.authorization.kubernetes.io/v1beta1\",\r\n \"kind\": \"Policy\",\r\n \"spec\": {\r\n \"user\": \"bob\",\r\n \"namespace\": \"projectCaribou\",\r\n \"resource\": \"pods\",\r\n \"readonly\": true\r\n }\r\n}\r\nIf Bob makes the following request, the request is authorized because he is allowed to read objects in the\r\nprojectCaribou namespace:\r\nhttps://kubernetes.io/docs/concepts/security/controlling-access/\r\nPage 2 of 4\n\n{\r\n \"apiVersion\": \"authorization.k8s.io/v1beta1\",\r\n \"kind\": \"SubjectAccessReview\",\r\n \"spec\": {\r\n \"resourceAttributes\": {\r\n \"namespace\": \"projectCaribou\",\r\n \"verb\": \"get\",\r\n \"group\": \"unicorn.example.org\",\r\n \"resource\": \"pods\"\r\n }\r\n }\r\n}\r\nIf Bob makes a request to write ( create or update ) to the objects in the projectCaribou namespace, his\r\nauthorization is denied. If Bob makes a request to read ( get ) objects in a different namespace such as\r\nprojectFish , then his authorization is denied.\r\nKubernetes authorization requires that you use common REST attributes to interact with existing organization-wide or cloud-provider-wide access control systems. It is important to use REST formatting because these control\r\nsystems might interact with other APIs besides the Kubernetes API.\r\nKubernetes supports multiple authorization modules, such as ABAC mode, RBAC Mode, and Webhook mode.\r\nWhen an administrator creates a cluster, they configure the authorization modules that should be used in the API\r\nserver. If more than one authorization modules are configured, Kubernetes checks each module, and if any module\r\nauthorizes the request, then the request can proceed. If all of the modules deny the request, then the request is\r\ndenied (HTTP status code 403).\r\nTo learn more about Kubernetes authorization, including details about creating policies using the supported\r\nauthorization modules, see Authorization.\r\nAdmission control\r\nAdmission Control modules are software modules that can modify or reject requests. In addition to the attributes\r\navailable to Authorization modules, Admission Control modules can access the contents of the object that is being\r\ncreated or modified.\r\nAdmission controllers act on requests that create, modify, delete, or connect to (proxy) an object. Admission\r\ncontrollers do not act on requests that merely read objects. When multiple admission controllers are configured,\r\nthey are called in order.\r\nThis is shown as step 3 in the diagram.\r\nUnlike Authentication and Authorization modules, if any admission controller module rejects, then the request is\r\nimmediately rejected.\r\nIn addition to rejecting objects, admission controllers can also set complex defaults for fields.\r\nhttps://kubernetes.io/docs/concepts/security/controlling-access/\r\nPage 3 of 4\n\nThe available Admission Control modules are described in Admission Controllers.\r\nOnce a request passes all admission controllers, it is validated using the validation routines for the corresponding\r\nAPI object, and then written to the object store (shown as step 4).\r\nAuditing\r\nKubernetes auditing provides a security-relevant, chronological set of records documenting the sequence of\r\nactions in a cluster. The cluster audits the activities generated by users, by applications that use the Kubernetes\r\nAPI, and by the control plane itself.\r\nFor more information, see Auditing.\r\nWhat's next\r\nRead more documentation on authentication, authorization and API access control:\r\nAuthenticating\r\nAuthenticating with Bootstrap Tokens\r\nAdmission Controllers\r\nDynamic Admission Control\r\nAuthorization\r\nRole Based Access Control\r\nAttribute Based Access Control\r\nNode Authorization\r\nWebhook Authorization\r\nCertificate Signing Requests\r\nincluding CSR approval and certificate signing\r\nService accounts\r\nDeveloper guide\r\nAdministration\r\nYou can learn about:\r\nhow Pods can use Secrets to obtain API credentials.\r\nSource: https://kubernetes.io/docs/concepts/security/controlling-access/\r\nhttps://kubernetes.io/docs/concepts/security/controlling-access/\r\nPage 4 of 4",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"MITRE"
	],
	"references": [
		"https://kubernetes.io/docs/concepts/security/controlling-access/"
	],
	"report_names": [
		"controlling-access"
	],
	"threat_actors": [],
	"ts_created_at": 1775439141,
	"ts_updated_at": 1775791285,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/790d64f50f0bd1ae59f969231e02f93cf12fad23.pdf",
		"text": "https://archive.orkl.eu/790d64f50f0bd1ae59f969231e02f93cf12fad23.txt",
		"img": "https://archive.orkl.eu/790d64f50f0bd1ae59f969231e02f93cf12fad23.jpg"
	}
}