{
	"id": "23dae93f-75c3-4c3d-973d-97e2d249fd42",
	"created_at": "2026-04-06T00:12:24.47196Z",
	"updated_at": "2026-04-10T03:21:11.183346Z",
	"deleted_at": null,
	"sha1_hash": "4ae2f3ef9e743a967476b2e483ffeccecd9ccc0c",
	"title": "Authorization",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 127598,
	"plain_text": "Authorization\r\nBy Request attributes used in authorization\r\nArchived: 2026-04-05 14:34:58 UTC\r\nDetails of Kubernetes authorization mechanisms and supported authorization modes.\r\nKubernetes authorization takes place following authentication. Usually, a client making a request must be\r\nauthenticated (logged in) before its request can be allowed; however, Kubernetes also allows anonymous requests\r\nin some circumstances.\r\nFor an overview of how authorization fits into the wider context of API access control, read Controlling Access to\r\nthe Kubernetes API.\r\nAuthorization verdicts\r\nKubernetes authorization of API requests takes place within the API server. The API server evaluates all of the\r\nrequest attributes against all policies, potentially also consulting external services, and then allows or denies the\r\nrequest.\r\nAll parts of an API request must be allowed by some authorization mechanism in order to proceed. In other words:\r\naccess is denied by default.\r\nNote:\r\nAccess controls and policies that depend on specific fields of specific kinds of objects are handled by admission\r\ncontrollers.\r\nKubernetes admission control happens after authorization has completed (and, therefore, only when the\r\nauthorization decision was to allow the request).\r\nWhen multiple authorization modules are configured, each is checked in sequence. If any authorizer approves or\r\ndenies a request, that decision is immediately returned and no other authorizer is consulted. If all modules have no\r\nopinion on the request, then the request is denied. An overall deny verdict means that the API server rejects the\r\nrequest and responds with an HTTP 403 (Forbidden) status.\r\nKubernetes reviews only the following API request attributes:\r\nuser - The user string provided during authentication.\r\ngroup - The list of group names to which the authenticated user belongs.\r\nextra - A map of arbitrary string keys to string values, provided by the authentication layer.\r\nAPI - Indicates whether the request is for an API resource.\r\nRequest path - Path to miscellaneous non-resource endpoints like /api or /healthz .\r\nhttps://kubernetes.io/docs/reference/access-authn-authz/authorization/\r\nPage 1 of 10\n\nAPI request verb - API verbs like get , list , create , update , patch , watch , delete , and\r\ndeletecollection are used for resource requests. To determine the request verb for a resource API\r\nendpoint, see request verbs and authorization.\r\nHTTP request verb - Lowercased HTTP methods like get , post , put , and delete are used for\r\nnon-resource requests.\r\nResource - The ID or name of the resource that is being accessed (for resource requests only) -- For\r\nresource requests using get , update , patch , and delete verbs, you must provide the resource name.\r\nSubresource - The subresource that is being accessed (for resource requests only).\r\nNamespace - The namespace of the object that is being accessed (for namespaced resource requests only).\r\nAPI group - The API Group being accessed (for resource requests only). An empty string designates the\r\ncore API group.\r\nRequest verbs and authorization\r\nNon-resource requests\r\nRequests to endpoints other than /api/v1/... or /apis/\u003cgroup\u003e/\u003cversion\u003e/... are considered non-resource\r\nrequests, and use the lower-cased HTTP method of the request as the verb. For example, making a GET request\r\nusing HTTP to endpoints such as /api or /healthz would use get as the verb.\r\nResource requests\r\nTo determine the request verb for a resource API endpoint, Kubernetes maps the HTTP verb used and considers\r\nwhether or not the request acts on an individual resource or on a collection of resources:\r\nHTTP\r\nverb\r\nrequest verb\r\nPOST create\r\nGET ,\r\nHEAD\r\nget (for individual resources), list (for collections, including full object content), watch (for\r\nwatching an individual resource or collection of resources)\r\nPUT update\r\nPATCH patch\r\nDELETE delete (for individual resources), deletecollection (for collections)\r\nCaution:\r\n+The get, list and watch verbs can all return the full details of a resource. In terms of access to the returned data\r\nthey are equivalent. For example, list on secrets will reveal the data attributes of any returned resources.\r\nKubernetes sometimes checks authorization for additional permissions using specialized verbs. For example:\r\nhttps://kubernetes.io/docs/reference/access-authn-authz/authorization/\r\nPage 2 of 10\n\nSpecial cases of authentication\r\nimpersonate verb on users , groups , and serviceaccounts in the core API group, and the\r\nuserextras in the authentication.k8s.io API group.\r\nAuthorization of CertificateSigningRequests\r\napprove verb for CertificateSigningRequests, and update for revisions to existing approvals\r\nRBAC\r\nbind and escalate verbs on roles and clusterroles resources in the\r\nrbac.authorization.k8s.io API group.\r\nAuthorization context\r\nKubernetes expects attributes that are common to REST API requests. This means that Kubernetes authorization\r\nworks with existing organization-wide or cloud-provider-wide access control systems which may handle other\r\nAPIs besides the Kubernetes API.\r\nAuthorization modes\r\nThe Kubernetes API server may authorize a request using one of several authorization modes:\r\nAlwaysAllow\r\nThis mode allows all requests, which brings security risks. Use this authorization mode only if you do not\r\nrequire authorization for your API requests (for example, for testing).\r\nAlwaysDeny\r\nThis mode blocks all requests. Use this authorization mode only for testing.\r\nABAC (attribute-based access control)\r\nKubernetes ABAC mode defines an access control paradigm whereby access rights are granted to users\r\nthrough the use of policies which combine attributes together. The policies can use any type of attributes\r\n(user attributes, resource attributes, object, environment attributes, etc).\r\nRBAC (role-based access control)\r\nKubernetes RBAC is a method of regulating access to computer or network resources based on the roles of\r\nindividual users within an enterprise. In this context, access is the ability of an individual user to perform a\r\nspecific task, such as view, create, or modify a file.\r\nIn this mode, Kubernetes uses the rbac.authorization.k8s.io API group to drive authorization\r\ndecisions, allowing you to dynamically configure permission policies through the Kubernetes API.\r\nNode\r\nA special-purpose authorization mode that grants permissions to kubelets based on the pods they are\r\nscheduled to run. To learn more about the Node authorization mode, see Node Authorization.\r\nWebhook\r\nKubernetes webhook mode for authorization makes a synchronous HTTP callout, blocking the request until\r\nthe remote HTTP service responds to the query.You can write your own software to handle the callout, or\r\nuse solutions from the ecosystem.\r\nThe system:masters group\r\nhttps://kubernetes.io/docs/reference/access-authn-authz/authorization/\r\nPage 3 of 10\n\nThe system:masters group is a built-in Kubernetes group that grants unrestricted access to the API server. Any\r\nuser assigned to this group has full cluster administrator privileges, bypassing any authorization restrictions\r\nimposed by the RBAC or Webhook mechanisms. Avoid adding users to this group. If you do need to grant a user\r\ncluster-admin rights, you can create a ClusterRoleBinding to the built-in cluster-admin ClusterRole.\r\nAuthorization mode configuration\r\nYou can configure the Kubernetes API server's authorizer chain using either a configuration file only or command\r\nline arguments.\r\nYou have to pick one of the two configuration approaches; setting both --authorization-config path and\r\nconfiguring an authorization webhook using the --authorization-mode and --authorization-webhook-*\r\ncommand line arguments is not allowed. If you try this, the API server reports an error message during startup,\r\nthen exits immediately.\r\nConfiguring the API Server using an authorization config file\r\nFEATURE STATE: Kubernetes v1.32 [stable] (enabled by default)\r\nKubernetes lets you configure authorization chains that can include multiple webhooks. The authorization items in\r\nthat chain can have well-defined parameters that validate requests in a particular order, offering you fine-grained\r\ncontrol, such as explicit Deny on failures.\r\nThe configuration file approach even allows you to specify CEL rules to pre-filter requests before they are\r\ndispatched to webhooks, helping you to prevent unnecessary invocations. The API server also automatically\r\nreloads the authorizer chain when the configuration file is modified.\r\nYou specify the path to the authorization configuration using the --authorization-config command line\r\nargument.\r\nIf you want to use command line arguments instead of a configuration file, that's also a valid and supported\r\napproach. Some authorization capabilities (for example: multiple webhooks, webhook failure policy, and pre-filter\r\nrules) are only available if you use an authorization configuration file.\r\nExample configuration\r\n---\r\n#\r\n# DO NOT USE THE CONFIG AS IS. THIS IS AN EXAMPLE.\r\n#\r\napiVersion: apiserver.config.k8s.io/v1\r\nkind: AuthorizationConfiguration\r\nauthorizers:\r\n - type: Webhook\r\n # Name used to describe the authorizer\r\n # This is explicitly used in monitoring machinery for metrics\r\nhttps://kubernetes.io/docs/reference/access-authn-authz/authorization/\r\nPage 4 of 10\n\n# Note:\r\n # - Validation for this field is similar to how K8s labels are validated today.\r\n # Required, with no default\r\n name: webhook\r\n webhook:\r\n # The duration to cache 'authorized' responses from the webhook\r\n # authorizer.\r\n # Same as setting `--authorization-webhook-cache-authorized-ttl` flag\r\n # Default: 5m0s\r\n authorizedTTL: 30s\r\n # If set to false, 'authorized' responses from the webhook are not cached\r\n # and the specified authorizedTTL is ignored/has no effect.\r\n # Same as setting `--authorization-webhook-cache-authorized-ttl` flag to `0`.\r\n # Note: Setting authorizedTTL to `0` results in its default value being used.\r\n # Default: true\r\n cacheAuthorizedRequests: true\r\n # The duration to cache 'unauthorized' responses from the webhook\r\n # authorizer.\r\n # Same as setting `--authorization-webhook-cache-unauthorized-ttl` flag\r\n # Default: 30s\r\n unauthorizedTTL: 30s\r\n # If set to false, 'unauthorized' responses from the webhook are not cached\r\n # and the specified unauthorizedTTL is ignored/has no effect.\r\n # Same as setting `--authorization-webhook-cache-unauthorized-ttl` flag to `0`.\r\n # Note: Setting unauthorizedTTL to `0` results in its default value being used.\r\n # Default: true\r\n cacheUnauthorizedRequests: true\r\n # Timeout for the webhook request\r\n # Maximum allowed is 30s.\r\n # Required, with no default.\r\n timeout: 3s\r\n # The API version of the authorization.k8s.io SubjectAccessReview to\r\n # send to and expect from the webhook.\r\n # Same as setting `--authorization-webhook-version` flag\r\n # Required, with no default\r\n # Valid values: v1beta1, v1\r\n subjectAccessReviewVersion: v1\r\n # MatchConditionSubjectAccessReviewVersion specifies the SubjectAccessReview\r\n # version the CEL expressions are evaluated against\r\n # Valid values: v1\r\n # Required, no default value\r\n matchConditionSubjectAccessReviewVersion: v1\r\n # Controls the authorization decision when a webhook request fails to\r\n # complete or returns a malformed response or errors evaluating\r\n # matchConditions.\r\n # Valid values:\r\n # - NoOpinion: continue to subsequent authorizers to see if one of\r\nhttps://kubernetes.io/docs/reference/access-authn-authz/authorization/\r\nPage 5 of 10\n\n# them allows the request\r\n # - Deny: reject the request without consulting subsequent authorizers\r\n # Required, with no default.\r\n failurePolicy: Deny\r\n connectionInfo:\r\n # Controls how the webhook should communicate with the server.\r\n # Valid values:\r\n # - KubeConfigFile: use the file specified in kubeConfigFile to locate the\r\n # server.\r\n # - InClusterConfig: use the in-cluster configuration to call the\r\n # SubjectAccessReview API hosted by kube-apiserver. This mode is not\r\n # allowed for kube-apiserver.\r\n type: KubeConfigFile\r\n # Path to KubeConfigFile for connection info\r\n # Required, if connectionInfo.Type is KubeConfigFile\r\n kubeConfigFile: /kube-system-authz-webhook.yaml\r\n # matchConditions is a list of conditions that must be met for a request to be sent to this\r\n # webhook. An empty list of matchConditions matches all requests.\r\n # There are a maximum of 64 match conditions allowed.\r\n #\r\n # The exact matching logic is (in order):\r\n # 1. If at least one matchCondition evaluates to FALSE, then the webhook is skipped.\r\n # 2. If ALL matchConditions evaluate to TRUE, then the webhook is called.\r\n # 3. If at least one matchCondition evaluates to an error (but none are FALSE):\r\n # - If failurePolicy=Deny, then the webhook rejects the request\r\n # - If failurePolicy=NoOpinion, then the error is ignored and the webhook is skipped\r\n matchConditions:\r\n # expression represents the expression which will be evaluated by CEL. Must evaluate to bool.\r\n # CEL expressions have access to the contents of the SubjectAccessReview in v1 version.\r\n # If version specified by subjectAccessReviewVersion in the request variable is v1beta1,\r\n # the contents would be converted to the v1 version before evaluating the CEL expression.\r\n #\r\n # Documentation on CEL: https://kubernetes.io/docs/reference/using-api/cel/\r\n #\r\n # only send resource requests to the webhook\r\n - expression: has(request.resourceAttributes)\r\n # only intercept requests to kube-system\r\n - expression: request.resourceAttributes.namespace == 'kube-system'\r\n # don't intercept requests from kube-system service accounts\r\n - expression: \"!('system:serviceaccounts:kube-system' in request.groups)\"\r\n - type: Node\r\n name: node\r\n - type: RBAC\r\n name: rbac\r\n - type: Webhook\r\n name: in-cluster-authorizer\r\n webhook:\r\nhttps://kubernetes.io/docs/reference/access-authn-authz/authorization/\r\nPage 6 of 10\n\nauthorizedTTL: 5m\r\n unauthorizedTTL: 30s\r\n timeout: 3s\r\n subjectAccessReviewVersion: v1\r\n failurePolicy: NoOpinion\r\n connectionInfo:\r\n type: InClusterConfig\r\nWhen configuring the authorizer chain using a configuration file, make sure all the control plane nodes have the\r\nsame file contents. Take a note of the API server configuration when upgrading / downgrading your clusters. For\r\nexample, if upgrading from Kubernetes 1.34 to Kubernetes 1.35, you would need to make sure the config file is in\r\na format that Kubernetes 1.35 can understand, before you upgrade the cluster. If you downgrade to 1.34, you\r\nwould need to set the configuration appropriately.\r\nAuthorization configuration and reloads\r\nKubernetes reloads the authorization configuration file when the API server observes a change to the file, and also\r\non a 60 second schedule if no change events were observed.\r\nNote:\r\nYou must ensure that all non-webhook authorizer types remain unchanged in the file on reload.\r\nA reload must not add or remove Node or RBAC authorizers (they can be reordered, but cannot be added or\r\nremoved).\r\nCommand line authorization mode configuration\r\nYou can use the following modes:\r\n--authorization-mode=ABAC (Attribute-based access control mode)\r\n--authorization-mode=RBAC (Role-based access control mode)\r\n--authorization-mode=Node (Node authorizer)\r\n--authorization-mode=Webhook (Webhook authorization mode)\r\n--authorization-mode=AlwaysAllow (always allows requests; carries security risks)\r\n--authorization-mode=AlwaysDeny (always denies requests)\r\nYou can choose more than one authorization mode; for example: --authorization-mode=Node,RBAC,Webhook\r\nKubernetes checks authorization modules based on the order that you specify them on the API server's command\r\nline, so an earlier module has higher priority to allow or deny a request.\r\nYou cannot combine the --authorization-mode command line argument with the --authorization-config\r\ncommand line argument used for configuring authorization using a local file.\r\nFor more information on command line arguments to the API server, read the kube-apiserver reference.\r\nhttps://kubernetes.io/docs/reference/access-authn-authz/authorization/\r\nPage 7 of 10\n\nPrivilege escalation via workload creation or edits\r\nUsers who can create/edit pods in a namespace, either directly or through an object that enables indirect workload\r\nmanagement, may be able to escalate their privileges in that namespace. The potential routes to privilege\r\nescalation include Kubernetes API extensions and their associated controllers.\r\nCaution:\r\nAs a cluster administrator, use caution when granting access to create or edit workloads. Some details of how\r\nthese can be misused are documented in escalation paths.\r\nEscalation paths\r\nThere are different ways that an attacker or untrustworthy user could gain additional privilege within a namespace,\r\nif you allow them to run arbitrary Pods in that namespace:\r\nMounting arbitrary Secrets in that namespace\r\nCan be used to access confidential information meant for other workloads\r\nCan be used to obtain a more privileged ServiceAccount's service account token\r\nUsing arbitrary ServiceAccounts in that namespace\r\nCan perform Kubernetes API actions as another workload (impersonation)\r\nCan perform any privileged actions that ServiceAccount has\r\nMounting or using ConfigMaps meant for other workloads in that namespace\r\nCan be used to obtain information meant for other workloads, such as database host names.\r\nMounting volumes meant for other workloads in that namespace\r\nCan be used to obtain information meant for other workloads, and change it.\r\nCaution:\r\nAs a system administrator, you should be cautious when deploying CustomResourceDefinitions that let users\r\nmake changes to the above areas. These may open privilege escalations paths. Consider the consequences of this\r\nkind of change when deciding on your authorization controls.\r\nChecking API access\r\nkubectl provides the auth can-i subcommand for quickly querying the API authorization layer. The\r\ncommand uses the SelfSubjectAccessReview API to determine if the current user can perform a given action,\r\nand works regardless of the authorization mode used.\r\nkubectl auth can-i create deployments --namespace dev\r\nThe output is similar to this:\r\nhttps://kubernetes.io/docs/reference/access-authn-authz/authorization/\r\nPage 8 of 10\n\nyes\r\nkubectl auth can-i create deployments --namespace prod\r\nThe output is similar to this:\r\nno\r\nAdministrators can combine this with user impersonation to determine what action other users can perform.\r\nkubectl auth can-i list secrets --namespace dev --as dave\r\nThe output is similar to this:\r\nno\r\nSimilarly, to check whether a ServiceAccount named dev-sa in Namespace dev can list Pods in the\r\nNamespace target :\r\nkubectl auth can-i list pods \\\r\n --namespace target \\\r\n --as system:serviceaccount:dev:dev-sa\r\nThe output is similar to this:\r\nyes\r\nSelfSubjectAccessReview is part of the authorization.k8s.io API group, which exposes the API server\r\nauthorization to external services. Other resources in this group include:\r\nSubjectAccessReview\r\nAccess review for any user, not only the current one. Useful for delegating authorization decisions to the\r\nAPI server. For example, the kubelet and extension API servers use this to determine user access to their\r\nown APIs.\r\nLocalSubjectAccessReview\r\nLike SubjectAccessReview but restricted to a specific namespace.\r\nSelfSubjectRulesReview\r\nA review which returns the set of actions a user can perform within a namespace. Useful for users to\r\nquickly summarize their own access, or for UIs to hide/show actions.\r\nhttps://kubernetes.io/docs/reference/access-authn-authz/authorization/\r\nPage 9 of 10\n\nThese APIs can be queried by creating normal Kubernetes resources, where the response status field of the\r\nreturned object is the result of the query. For example:\r\nkubectl create -f - -o yaml \u003c\u003c EOF\r\napiVersion: authorization.k8s.io/v1\r\nkind: SelfSubjectAccessReview\r\nspec:\r\n resourceAttributes:\r\n group: apps\r\n resource: deployments\r\n verb: create\r\n namespace: dev\r\nEOF\r\nThe generated SelfSubjectAccessReview is similar to:\r\napiVersion: authorization.k8s.io/v1\r\nkind: SelfSubjectAccessReview\r\nmetadata:\r\n creationTimestamp: null\r\nspec:\r\n resourceAttributes:\r\n group: apps\r\n resource: deployments\r\n namespace: dev\r\n verb: create\r\nstatus:\r\n allowed: true\r\n denied: false\r\nWhat's next\r\nTo learn more about Authentication, see Authentication.\r\nFor an overview, read Controlling Access to the Kubernetes API.\r\nTo learn more about Admission Control, see Using Admission Controllers.\r\nRead more about Common Expression Language in Kubernetes.\r\nSource: https://kubernetes.io/docs/reference/access-authn-authz/authorization/\r\nhttps://kubernetes.io/docs/reference/access-authn-authz/authorization/\r\nPage 10 of 10",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"MITRE"
	],
	"references": [
		"https://kubernetes.io/docs/reference/access-authn-authz/authorization/"
	],
	"report_names": [
		"authorization"
	],
	"threat_actors": [],
	"ts_created_at": 1775434344,
	"ts_updated_at": 1775791271,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/4ae2f3ef9e743a967476b2e483ffeccecd9ccc0c.pdf",
		"text": "https://archive.orkl.eu/4ae2f3ef9e743a967476b2e483ffeccecd9ccc0c.txt",
		"img": "https://archive.orkl.eu/4ae2f3ef9e743a967476b2e483ffeccecd9ccc0c.jpg"
	}
}