Your applicationso that the users aren't directly involved. A service account can have zero or more pairs of service account keys, which are used to authenticate to Google. When treating the service account as an identity, you can grant a role to a service account, enabling it to access a resource such as a project. When treating a service account as a resource, you can grant permission to a user to access that service account. You can grant the Owner, Editor, Viewer, or role to a user to access the service account. Granting access to service accounts Granting access to a service account to access a resource is similar google play service account action required granting access to any other identity. For example, if you have an application running on Google Compute Engine and you want the application to only have access to create objects in Google Cloud Storage. You can create a service account for the application and grant it the role. The following diagram illustrates this example: Learn about. The way you would solve this problem is by creating a service account to start and stop the job. In this scenario, the service is the resource. Note: Users with the Service Account User and Compute Instance Admin roles can indirectly access all resources the service account has access to, as well as create, modify, and delete Compute Engine instances. Therefore, be cautious when granting these roles to users. You can use a service account from the virtual machines on google play service account action required external cloud to push the data to Google Cloud Platform. Keeping track of service accounts Over time, as you create more and more service accounts, you might lose track of which service account is used for what purpose. The display name of a service account is a good way to capture additional information about the service account, such as the purpose of the service account or a contact person for the account. For new service accounts, you can populate the display name when creating the service account. For existing service accounts use the method to modify the display name. Deleting and recreating service accounts It is possible to delete a service account and then create a new service account with the same name. If you reuse the name of a deleted service account, it may result in unexpected behavior. When you delete a service account, its role bindings are not immediately deleted. If you create a new service account with the same name as a recently deleted service account, the old bindings may still exist; however, they will not apply to the new service account even though both accounts have the same email address. Therefore, any role bindings that existed for a deleted service account do not apply to a new service account that uses the same email address. To avoid confusion, we suggest using unique service account names. You must remove the role bindings first before re-adding them. Simply granting the role again will silently fail by granting the role to the old, deleted service account. Granting minimum permissions to service accounts You should only grant the service account the minimum set of permissions required to achieve their goal. When granting permissions to users to access a service account, keep in mind that the user can access all the resources for which the service account has permissions. Users with to update the App Engine and Compute Engine instances such as or can effectively run code as the service accounts used to run these instances, and indirectly gain access to all the resources for which the service accounts has access. Similarly, to a Compute Engine instance may also provide the ability to execute code as that instance. These keys are used by Cloud Platform services such as App Engine and Compute Engine. They cannot be downloaded, and are automatically rotated and used for signing for a maximum of two weeks. The rotation process is probabilistic; usage of the new key will gradually ramp up and down over the key's lifetime. We recommend caching the public key set for a service account for at most 24 hours to ensure that you always have access to the current key set. These keys are created, downloadable, and managed by users. They expire 10 years from creation. Always discourage developers from checking keys into the source code or leaving them in Downloads directory. You can rotate a key by creating a new key, switching applications to use the new key and then deleting the google play service account action required key. Use the and methods together to automate the rotation. Using service accounts with Compute Engine Compute Engine instances need to run as service accounts to have access to other Cloud Platform resources. If you delete the service accounts, the instances may start failing their operations. Users who are for a service account can indirectly access all the resources the service account has access to. Therefore, be cautious when granting the serviceAccountUser role to a user. When you create a service account, populate its display name with the purpose of the service account. Except as otherwise noted, the content of this page is licensed under theand code samples are licensed under the. Last updated October 30, 2018.
