{
	"id": "5e098503-3881-4070-901f-20913ca8a164",
	"created_at": "2026-04-06T03:36:35.827506Z",
	"updated_at": "2026-04-10T03:20:31.714848Z",
	"deleted_at": null,
	"sha1_hash": "8397f26b1b5bd16b54882cb9d9cade3078006c18",
	"title": "Service Accounts",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 97670,
	"plain_text": "Service Accounts\r\nArchived: 2026-04-06 03:17:34 UTC\r\nLearn about ServiceAccount objects in Kubernetes.\r\nThis page introduces the ServiceAccount object in Kubernetes, providing information about how service accounts\r\nwork, use cases, limitations, alternatives, and links to resources for additional guidance.\r\nWhat are service accounts?\r\nA service account is a type of non-human account that, in Kubernetes, provides a distinct identity in a Kubernetes\r\ncluster. Application Pods, system components, and entities inside and outside the cluster can use a specific\r\nServiceAccount's credentials to identify as that ServiceAccount. This identity is useful in various situations,\r\nincluding authenticating to the API server or implementing identity-based security policies.\r\nService accounts exist as ServiceAccount objects in the API server. Service accounts have the following\r\nproperties:\r\nNamespaced: Each service account is bound to a Kubernetes namespace. Every namespace gets a\r\ndefault ServiceAccount upon creation.\r\nLightweight: Service accounts exist in the cluster and are defined in the Kubernetes API. You can quickly\r\ncreate service accounts to enable specific tasks.\r\nPortable: A configuration bundle for a complex containerized workload might include service account\r\ndefinitions for the system's components. The lightweight nature of service accounts and the namespaced\r\nidentities make the configurations portable.\r\nService accounts are different from user accounts, which are authenticated human users in the cluster. By default,\r\nuser accounts don't exist in the Kubernetes API server; instead, the API server treats user identities as opaque data.\r\nYou can authenticate as a user account using multiple methods. Some Kubernetes distributions might add custom\r\nextension APIs to represent user accounts in the API server.\r\nDescription ServiceAccount User or group\r\nLocation\r\nKubernetes API (ServiceAccount\r\nobject)\r\nExternal\r\nAccess\r\ncontrol\r\nKubernetes RBAC or other\r\nauthorization mechanisms\r\nKubernetes RBAC or other identity and access\r\nmanagement mechanisms\r\nIntended use Workloads, automation People\r\nDefault service accounts\r\nhttps://kubernetes.io/docs/concepts/security/service-accounts/\r\nPage 1 of 7\n\nWhen you create a cluster, Kubernetes automatically creates a ServiceAccount object named default for every\r\nnamespace in your cluster. The default service accounts in each namespace get no permissions by default other\r\nthan the default API discovery permissions that Kubernetes grants to all authenticated principals if role-based\r\naccess control (RBAC) is enabled. If you delete the default ServiceAccount object in a namespace, the control\r\nplane replaces it with a new one.\r\nIf you deploy a Pod in a namespace, and you don't manually assign a ServiceAccount to the Pod, Kubernetes\r\nassigns the default ServiceAccount for that namespace to the Pod.\r\nUse cases for Kubernetes service accounts\r\nAs a general guideline, you can use service accounts to provide identities in the following scenarios:\r\nYour Pods need to communicate with the Kubernetes API server, for example in situations such as the\r\nfollowing:\r\nProviding read-only access to sensitive information stored in Secrets.\r\nGranting cross-namespace access, such as allowing a Pod in namespace example to read, list, and\r\nwatch for Lease objects in the kube-node-lease namespace.\r\nYour Pods need to communicate with an external service. For example, a workload Pod requires an identity\r\nfor a commercially available cloud API, and the commercial provider allows configuring a suitable trust\r\nrelationship.\r\nAuthenticating to a private image registry using an imagePullSecret .\r\nAn external service needs to communicate with the Kubernetes API server. For example, authenticating to\r\nthe cluster as part of a CI/CD pipeline.\r\nYou use third-party security software in your cluster that relies on the ServiceAccount identity of different\r\nPods to group those Pods into different contexts.\r\nHow to use service accounts\r\nTo use a Kubernetes service account, you do the following:\r\n1. Create a ServiceAccount object using a Kubernetes client like kubectl or a manifest that defines the\r\nobject.\r\n2. Grant permissions to the ServiceAccount object using an authorization mechanism such as RBAC.\r\n3. Assign the ServiceAccount object to Pods during Pod creation.\r\nIf you're using the identity from an external service, retrieve the ServiceAccount token and use it from that\r\nservice instead.\r\nFor instructions, refer to Configure Service Accounts for Pods.\r\nGrant permissions to a ServiceAccount\r\nhttps://kubernetes.io/docs/concepts/security/service-accounts/\r\nPage 2 of 7\n\nYou can use the built-in Kubernetes role-based access control (RBAC) mechanism to grant the minimum\r\npermissions required by each service account. You create a role, which grants access, and then bind the role to\r\nyour ServiceAccount. RBAC lets you define a minimum set of permissions so that the service account\r\npermissions follow the principle of least privilege. Pods that use that service account don't get more permissions\r\nthan are required to function correctly.\r\nFor instructions, refer to ServiceAccount permissions.\r\nCross-namespace access using a ServiceAccount\r\nYou can use RBAC to allow service accounts in one namespace to perform actions on resources in a different\r\nnamespace in the cluster. For example, consider a scenario where you have a service account and Pod in the dev\r\nnamespace and you want your Pod to see Jobs running in the maintenance namespace. You could create a Role\r\nobject that grants permissions to list Job objects. Then, you'd create a RoleBinding object in the maintenance\r\nnamespace to bind the Role to the ServiceAccount object. Now, Pods in the dev namespace can list Job objects\r\nin the maintenance namespace using that service account.\r\nAssign a ServiceAccount to a Pod\r\nTo assign a ServiceAccount to a Pod, you set the spec.serviceAccountName field in the Pod specification.\r\nKubernetes then automatically provides the credentials for that ServiceAccount to the Pod. In v1.22 and later,\r\nKubernetes gets a short-lived, automatically rotating token using the TokenRequest API and mounts the token\r\nas a projected volume.\r\nBy default, Kubernetes provides the Pod with the credentials for an assigned ServiceAccount, whether that is the\r\ndefault ServiceAccount or a custom ServiceAccount that you specify.\r\nTo prevent Kubernetes from automatically injecting credentials for a specified ServiceAccount or the default\r\nServiceAccount, set the automountServiceAccountToken field in your Pod specification to false .\r\nIn versions earlier than 1.22, Kubernetes provides a long-lived, static token to the Pod as a Secret.\r\nManually retrieve ServiceAccount credentials\r\nIf you need the credentials for a ServiceAccount to mount in a non-standard location, or for an audience that isn't\r\nthe API server, use one of the following methods:\r\nTokenRequest API (recommended): Request a short-lived service account token from within your own\r\napplication code. The token expires automatically and can rotate upon expiration. If you have a legacy\r\napplication that is not aware of Kubernetes, you could use a sidecar container within the same pod to fetch\r\nthese tokens and make them available to the application workload.\r\nToken Volume Projection (also recommended): In Kubernetes v1.20 and later, use the Pod specification to\r\ntell the kubelet to add the service account token to the Pod as a projected volume. Projected tokens expire\r\nautomatically, and the kubelet rotates the token before it expires.\r\nhttps://kubernetes.io/docs/concepts/security/service-accounts/\r\nPage 3 of 7\n\nService Account Token Secrets (not recommended): You can mount service account tokens as Kubernetes\r\nSecrets in Pods. These tokens don't expire and don't rotate. In versions prior to v1.24, a permanent token\r\nwas automatically created for each service account. This method is not recommended anymore, especially\r\nat scale, because of the risks associated with static, long-lived credentials. The\r\nLegacyServiceAccountTokenNoAutoGeneration feature gate (which was enabled by default from\r\nKubernetes v1.24 to v1.26), prevented Kubernetes from automatically creating these tokens for\r\nServiceAccounts. The feature gate is removed in v1.27, because it was elevated to GA status; you can still\r\ncreate indefinite service account tokens manually, but should take into account the security implications.\r\nNote:\r\nFor applications running outside your Kubernetes cluster, you might be considering creating a long-lived\r\nServiceAccount token that is stored in a Secret. This allows authentication, but the Kubernetes project\r\nrecommends you avoid this approach. Long-lived bearer tokens represent a security risk as, once disclosed, the\r\ntoken can be misused. Instead, consider using an alternative. For example, your external application can\r\nauthenticate using a well-protected private key and a certificate, or using a custom mechanism such as an\r\nauthentication webhook that you implement yourself.\r\nYou can also use TokenRequest to obtain short-lived tokens for your external application.\r\nRestricting access to Secrets (deprecated)\r\nFEATURE STATE: Kubernetes v1.32 [deprecated]\r\nNote:\r\nkubernetes.io/enforce-mountable-secrets is deprecated since Kubernetes v1.32. Use separate namespaces to\r\nisolate access to mounted secrets.\r\nKubernetes provides an annotation called kubernetes.io/enforce-mountable-secrets that you can add to your\r\nServiceAccounts. When this annotation is applied, the ServiceAccount's secrets can only be mounted on specified\r\ntypes of resources, enhancing the security posture of your cluster.\r\nYou can add the annotation to a ServiceAccount using a manifest:\r\napiVersion: v1\r\nkind: ServiceAccount\r\nmetadata:\r\n annotations:\r\n kubernetes.io/enforce-mountable-secrets: \"true\"\r\n name: my-serviceaccount\r\n namespace: my-namespace\r\nWhen this annotation is set to \"true\", the Kubernetes control plane ensures that the Secrets from this\r\nServiceAccount are subject to certain mounting restrictions.\r\nhttps://kubernetes.io/docs/concepts/security/service-accounts/\r\nPage 4 of 7\n\n1. The name of each Secret that is mounted as a volume in a Pod must appear in the secrets field of the\r\nPod's ServiceAccount.\r\n2. The name of each Secret referenced using envFrom in a Pod must also appear in the secrets field of the\r\nPod's ServiceAccount.\r\n3. The name of each Secret referenced using imagePullSecrets in a Pod must also appear in the secrets\r\nfield of the Pod's ServiceAccount.\r\nBy understanding and enforcing these restrictions, cluster administrators can maintain a tighter security profile\r\nand ensure that secrets are accessed only by the appropriate resources.\r\nAuthenticating service account credentials\r\nServiceAccounts use signed JSON Web Tokens (JWTs) to authenticate to the Kubernetes API server, and to any\r\nother system where a trust relationship exists. Depending on how the token was issued (either time-limited using a\r\nTokenRequest or using a legacy mechanism with a Secret), a ServiceAccount token might also have an expiry\r\ntime, an audience, and a time after which the token starts being valid. When a client that is acting as a\r\nServiceAccount tries to communicate with the Kubernetes API server, the client includes an Authorization:\r\nBearer \u003ctoken\u003e header with the HTTP request. The API server checks the validity of that bearer token as\r\nfollows:\r\n1. Checks the token signature.\r\n2. Checks whether the token has expired.\r\n3. Checks whether object references in the token claims are currently valid.\r\n4. Checks whether the token is currently valid.\r\n5. Checks the audience claims.\r\nThe TokenRequest API produces bound tokens for a ServiceAccount. This binding is linked to the lifetime of the\r\nclient, such as a Pod, that is acting as that ServiceAccount. See Token Volume Projection for an example of a\r\nbound pod service account token's JWT schema and payload.\r\nFor tokens issued using the TokenRequest API, the API server also checks that the specific object reference that\r\nis using the ServiceAccount still exists, matching by the unique ID of that object. For legacy tokens that are\r\nmounted as Secrets in Pods, the API server checks the token against the Secret.\r\nFor more information about the authentication process, refer to Authentication.\r\nAuthenticating service account credentials in your own code\r\nIf you have services of your own that need to validate Kubernetes service account credentials, you can use the\r\nfollowing methods:\r\nTokenReview API (recommended)\r\nOIDC discovery\r\nThe Kubernetes project recommends that you use the TokenReview API, because this method invalidates tokens\r\nthat are bound to API objects such as Secrets, ServiceAccounts, Pods or Nodes when those objects are deleted. For\r\nhttps://kubernetes.io/docs/concepts/security/service-accounts/\r\nPage 5 of 7\n\nexample, if you delete the Pod that contains a projected ServiceAccount token, the cluster invalidates that token\r\nimmediately and a TokenReview immediately fails. If you use OIDC validation instead, your clients continue to\r\ntreat the token as valid until the token reaches its expiration timestamp.\r\nYour application should always define the audience that it accepts, and should check that the token's audiences\r\nmatch the audiences that the application expects. This helps to minimize the scope of the token so that it can only\r\nbe used in your application and nowhere else.\r\nAlternatives\r\nIssue your own tokens using another mechanism, and then use Webhook Token Authentication to validate\r\nbearer tokens using your own validation service.\r\nProvide your own identities to Pods.\r\nUse the SPIFFE CSI driver plugin to provide SPIFFE SVIDs as X.509 certificate pairs to Pods.\r\n🛇 This item links to a third party project or product that is not part of Kubernetes itself. More\r\ninformation\r\nUse a service mesh such as Istio to provide certificates to Pods.\r\nAuthenticate from outside the cluster to the API server without using service account tokens:\r\nConfigure the API server to accept OpenID Connect (OIDC) tokens from your identity provider.\r\nUse service accounts or user accounts created using an external Identity and Access Management\r\n(IAM) service, such as from a cloud provider, to authenticate to your cluster.\r\nUse the CertificateSigningRequest API with client certificates.\r\nConfigure the kubelet to retrieve credentials from an image registry.\r\nUse a Device Plugin to access a virtual Trusted Platform Module (TPM), which then allows authentication\r\nusing a private key.\r\nWhat's next\r\nLearn how to manage your ServiceAccounts as a cluster administrator.\r\nLearn how to assign a ServiceAccount to a Pod.\r\nRead the ServiceAccount API reference.\r\nLast modified November 19, 2024 at 10:53 PM PST: Address comments (3b8c927a3b)\r\nItems on this page refer to third party products or projects that provide functionality required by Kubernetes. The\r\nKubernetes project authors aren't responsible for those third-party products or projects. See the CNCF website\r\nguidelines for more details.\r\nYou should read the content guide before proposing a change that adds an extra third-party link.\r\nhttps://kubernetes.io/docs/concepts/security/service-accounts/\r\nPage 6 of 7\n\nSource: https://kubernetes.io/docs/concepts/security/service-accounts/\r\nhttps://kubernetes.io/docs/concepts/security/service-accounts/\r\nPage 7 of 7",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"MITRE"
	],
	"references": [
		"https://kubernetes.io/docs/concepts/security/service-accounts/"
	],
	"report_names": [
		"service-accounts"
	],
	"threat_actors": [],
	"ts_created_at": 1775446595,
	"ts_updated_at": 1775791231,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/8397f26b1b5bd16b54882cb9d9cade3078006c18.pdf",
		"text": "https://archive.orkl.eu/8397f26b1b5bd16b54882cb9d9cade3078006c18.txt",
		"img": "https://archive.orkl.eu/8397f26b1b5bd16b54882cb9d9cade3078006c18.jpg"
	}
}