Authenticating to Google APIs and service accounts
1. Authenticating to Google APIs and service accounts
SPEAKER: Next, we discuss authentication in Google Cloud. IAM enables authorization for Google Cloud Services, specifying what you're permitted to do. Authentication proves that you are who you say you are. You prove your identity by presenting some kind of credential. If you are an application developer on Google Cloud, you might need to use or create different types of authentication. Your application might need to authenticate to Google and allow access to Google services and resources. You might need to call apps hosted on Google Cloud Services, like Cloud Run. Usually, you want only authenticated callers to access your apps. You might also need to authenticate end users for your application. When you call a Google Cloud service, you're typically making an API call. There are three ways to authorize API calls to Google services. An API key is a string of characters that identifies the application. Using an API key associates the request with a Google Cloud project for billing and quota purposes. A compromised API key will allow full and long-lasting access to the API. So API keys are typically appropriate only for low-security, read-only APIs. Most Google APIs do not accept API keys. A user account represents a person. The account is identified by the email address of the person. The act of logging in uses the email address and a separate credential, usually a password, to create an OAuth token. The token allows limited access to the API based on the user's permissions and expires after a period of time. Oauth tokens are typically more secure than API keys. A service account represents a workload or application and is identified by its unique email address. An OAuth token for a service account provides access to the API based on the roles attached to the service account. We focus first on service account authentication. A service account acts as the identity for an application or a compute workload. The service account is used by your application to call a Google API or service so that users aren't directly involved in the authentication process. Each service account is identified by its unique email address. Service accounts enable authorization because you can assign specific IAM roles to a service account. Service accounts are authenticated by using an RSA private-public key pair. There is no password associated with the service account, so you can't use the service account to log in with the browser. You can assign specific IAM roles to a service account to provide the level of access required by the application. Unlike user accounts, service accounts do not have passwords. Instead, service accounts use RSA key pairs for authentication. The private key for a service account can be downloaded as a service account JSON file. In the early days of service accounts, downloaded service account keys were typically used whenever you needed to authenticate as an application. If you know the private key of a service account's key pair, you can use the private key to request an access token. The resulting access token can be used to interact with Google Cloud APIs on the service account's behalf. For this reason, having access to the private key is similar to knowing a user's password. Service account keys can become a security risk if not managed carefully. There are risks associated with using service account keys. The first risk is credential leakage. Consider what would happen if a developer committed a private key to a public code repository. A bad actor could use this key to gain access to resources in your environment. Another risk is privilege escalation. If a bad actor gets access to a service account key, they could use the key to escalate their own privileges. For example, the bad actor could use a service account with permission on a database to give themselves access to the database. Even after you managed to detect the danger and change the service account key, escalated privileges would remain. A third risk is identity masking. By authenticating as the service account, a bad actor might conceal their identity and actions. The best way to mitigate these risks is to avoid using downloaded service account keys and use other methods to authenticate service accounts whenever possible.2. Let's practice!
Create Your Free Account
or
By continuing, you accept our Terms of Use, our Privacy Policy and that your data is stored in the USA.