Securing Machine Access

1. Securing Machine Access

We just talked about assigning roles to members. We focused on users and Google Groups, but there's another kind of member that helps secure machine access. A service account is a special kind of account used by an application, a virtual machine instance, or a GKE node pool. Applications or services use service accounts to make authorized API calls. The service account is the identity of the service and defines permissions which control the resources the service can access. A service account is both an identity and a resource. A service account is used as an identity for your application or service to authenticate, for example, a Compute Engine VM running as a service account. To give the VM access to the necessary resources, you need to grant the relevant Cloud IAM roles to the service account. At the same time, you need to control who can create VMs with the service account so random VMs cannot assume the identity. Here, the service account is the resource to be permissioned. You assign the ServiceAccountUser role to the users you trust to use the service account. Each service account is associated with public/private RSA key-pairs that are used to authenticate to Google. These keys can be Google-managed or user-managed. Google-managed keys, both the public and private keys, are stored by Google, and they are rotated regularly. The maximum usage period is two weeks. For user-managed keys, the developer owns both public and private keys. They can be used from outside Google Cloud. User-managed keys can be managed by the Cloud IAM API, gcloud command-line tool, or the service accounts page in the Cloud Console. It is possible to create up to 10 key-pairs per service account to support key rotation. User-managed keys are extremely powerful credentials, and they can represent a security risk if they are not managed correctly. You can limit their use by applying the constraints/iam.disableServiceAccountKeyCreation Organization Policy Constraint to projects, folders, or even your entire organization. After applying the constraint, you can enable user-managed keys in well-controlled locations. To minimize the potential risk caused by unmanaged keys, consider using Cloud Key Management Service (Cloud KMS) to help securely manage your keys. The slide shows the generation of a key using the Cloud Console. The private key can be seen in the screenshot. It's your responsibility for storing the private key securely. For developers to gain controlled access to resources without acquiring access to the Cloud Console, it is possible to configure the gcloud command-line utility to use service account credentials to make requests. The command on this slide, gcloud auth activate-service-account, serves the same purpose as gcloud auth login, but uses the service account instead of user credentials. The key file contains the private key in JSON format, which I just discussed.

2. Let's practice!

Create Your Free Account

By continuing, you accept our Terms of Use, our Privacy Policy and that your data is stored in the USA.