[[["易于理解","easyToUnderstand","thumb-up"],["解决了我的问题","solvedMyProblem","thumb-up"],["其他","otherUp","thumb-up"]],[["很难理解","hardToUnderstand","thumb-down"],["信息或示例代码不正确","incorrectInformationOrSampleCode","thumb-down"],["没有我需要的信息/示例","missingTheInformationSamplesINeed","thumb-down"],["翻译问题","translationIssue","thumb-down"],["其他","otherDown","thumb-down"]],["最后更新时间 (UTC):2025-09-04。"],[[["\u003cp\u003eService account keys are a security risk comparable to passwords, as they allow authentication without the need for usernames or additional verification steps.\u003c/p\u003e\n"],["\u003cp\u003eCommon threats associated with service account keys include credential leakage, privilege escalation, information disclosure, and non-repudiation, all of which can be exploited by malicious actors.\u003c/p\u003e\n"],["\u003cp\u003eBest practices to protect service account keys involve reducing the number of keys, avoiding storage in temporary locations, refraining from sharing them between users, and never embedding them in source code repositories or program binaries.\u003c/p\u003e\n"],["\u003cp\u003eRegularly rotating service account keys, in addition to using expiry times for temporary access, helps mitigate the risks associated with leaked or stolen keys.\u003c/p\u003e\n"],["\u003cp\u003eFor applications, using a dedicated service account key per machine can improve traceability and help determine the origin of suspicious activity, aiding in security incident responses.\u003c/p\u003e\n"]]],[],null,["# Secure service account keys\n\nUnlike normal users, service accounts don't have passwords. Instead, service\naccounts use ECDSA key pairs for authentication. Because the private key of the\nRSA key pair lets you authenticate as the service account, having access to the\nprivate key is similar to knowing a user's password. The private key is known\nas a service account key. Service account keys are a security risk if not\nmanaged carefully.\n\nMain threats related to service account keys are as follows:\n\n- **Credential leakage**: Service account keys might inadvertently end up in\n places where they are not supposed to be stored. A bad actor can use a leaked\n service account key to authenticate and gain access to your environment.\n\n- **Privilege escalation**: If a bad actor gets access to a poorly secured\n service account key, they might be able to use the key to escalate their\n privileges.\n\n- **Information disclosure**: Service account keys might inadvertently disclose\n confidential data.\n\n- **Non-repudiation**: By authenticating using a service account key and\n letting the service account carry out operations on their behalf, a bad actor\n might conceal their identity and actions.\n\nThis page presents best practices for managing, using, and securing service\naccount keys.\n\nProtect against credential leakage\n----------------------------------\n\nLike a username and password, service account keys are a form of credential.\nIf a user can access a valid service account key, they can use the key to\nauthenticate and access the resources the respective service account has\naccess to.\n\nBad actors might find service account keys more valuable than a leaked\npassword. For example, attempting to sign in by using a leaked password is\nunlikely to succeed if the user account has been configured to use two step\nverification and login challenges. In contrast, authenticating with a leaked\nservice account key is likely to succeed as service accounts are not subject to\nany additional sign-in verifications.\n\nBad actors might look for service account keys in the following ways:\n\n- Source code repositories of open source projects.\n- Public data dumps of breached services.\n\nIn addition to public locations, bad actors might look for service account keys in private locations they've compromised. Examples include:\n\n- Email inboxes\n- File shares\n- Backup storage\n- Temporary file system directories\n\nAn effective way to lower the risk of leaking service account keys is to reduce\nthe number of keys in circulation and to disincentivize the creation of new\nkeys. The following sections describe how you can limit the number of service\naccount keys in circulation, and what other measures can help you limit the\nrisk of leaking service accounts.\n\n### Avoid leaving service account keys in temporary locations\n\nWhen you create a service account key, immediately move the key to the location\nwhere you want to store it. Ensure you're not accidentally leaving a copy in\nthe download folder or the recycle bin of your computer.\n\n### Don't pass service account keys between users\n\nWhen you deploy an application that requires a service account key, you might\nnot have the permission to create a service account key yourself. Instead, you\nmight have to request a different person to create a service account key for\nyou.\n\n### Don't submit service account keys to source code repositories\n\nService account keys are credentials, and must be protected from unauthorized\naccess. If you submit a service account key to a source code repository, there\nis an increased risk that the key becomes accessible to unauthorized users and\nbad actors:\n\n- Bad actors might scan the source code of public source repositories for\n leaked keys.\n\n- In the future, you might decide to turn a private source repository into a\n public repository, without checking it for keys first.\n\n- Other team members might store copies of the source code on their workstation.\n\nWhen you work on code that uses a service account key, always store the service\naccount key separate from the source code to reduce the risk of accidentally\nsubmitting the key to the source repository. In many cases, you can further\nreduce this risk by not using service account keys at all during development\nand using your personal credentials instead of service account keys instead.\n\n### Don't embed service account keys in program binaries\n\nService account keys are strings that match a certain pattern, and they can be\nidentified even if embedded in other files or binaries. If a bad actor has\naccess to the binary, they can extract any service account keys that are\nembedded in the binary.\n\nProgram binaries for server-side applications might be hosted in artifact\nrepositories or they might be copied to developer workstations for debugging\npurposes. Keeping service account keys separate from the program binaries helps\nensure that a user who can access the binary does not implicitly get access to\nservice account credentials.\n\n- For client-side applications such as tools, desktop programs, or mobile apps, don't use service accounts.\n- For server-side applications, don't embed service account keys into the binary. Instead, keep the keys separate from the application binary.\n\n### Rotate service account keys to reduce security risk caused by leaked keys\n\nAlthough you can reduce the probability of accidentally leaking a service\naccount key, it can be difficult to eliminate the risk completely.\n\nKey rotation is the process of replacing your existing keys with new keys and\nthen invalidating the replaced keys. We recommend that you routinely rotate all\nkeys that you manage, including your service account keys.\n\nRotating service account keys can help reduce the risk posed by leaked or\nstolen keys. If a key is leaked, it might take bad actors days or weeks to\ndiscover the key. If you regularly rotate your service account keys, there's a\nhigher chance that the leaked keys will be invalid by the time a bad actor gets\nthem.\n\n### Use expiry times to let keys expire automatically\n\nBy default, service account keys that you create have an expiry time of one\nyear and stay valid until you delete them. You can also set your own expiry\ntime. Setting an expiry time for service account keys can limit your security\nrisk by reducing the lifetime of the persistent credential. However, there are\nother risks associated with setting expiry times; for example, setting an\nexpiry time can cause workloads to fail when their keys expire.\n\nUse expiry times when you need temporary access to a system that requires a\nservice account key. For example, use expiry times when you're doing the\nfollowing:\n\n- Developing code in a non-production environment for an application that can only authenticate with service account keys.\n- Using a third-party tool that can only authenticate with service account keys.\n\nAvoid using expiry times for these scenarios:\n\n- Production workloads. In production, an expired service account key could cause an accidental outage. Instead, use keys that don't expire, and manage their lifecycle with key rotation.\n- Non-production workloads that need permanent access, such as a continuous integration (CI) pipeline.\n- Key-rotation systems that prevent a key from being used after a specified amount of time.\n\nTo limit the validity of service account keys, you can configure an expiry time\nfor newly created keys in your project, folder, or organization. The expiry\ntime does not apply to existing keys.\n\nHaving an established process for rotating service account keys also helps you\nact quickly if you suspect that a service account key has been compromised.\n\n### Use a dedicated key for each machine that runs an application\n\nTo help you narrow down the potential sources of suspicious activity, create\nindividual keys for each copy of the application. That way, you can use the\n`serviceAccountKeyName` field that many services add to audit log records to\ndistinguish which machine an activity originated from."]]