Using Google Cloud Services
1. Using Google Cloud Services
Google Kubernetes Engine offers several storage options for applications in your cluster, including storage abstractions like Volumes and PersistentVolumes. Let’s say you’re building and deploying a MySQL server as a container. To store the database files, you use a GKE Volume based on Persistent Disks. The disadvantage of this approach is that you are responsible for managing the application lifecycle and building a resilient and reliable service. Another option is to use Google Cloud’s fully managed database and storage services. Google Cloud offers relational database, non-relational database, and object storage services that help remove operational management burden. To access managed storage services, applications running in a GKE Kubernetes cluster must be capable of communicating with Google Cloud APIs. After the relevant API is enabled, the application will use granted credentials for authentication and authorization to perform tasks. To help, Workload Identity can be used to simplify and secure process management on your cluster. Every action in Google Cloud must be authenticated and authorized. Workload Identity uses dedicated credentials to directly authenticate, which eliminates the need to manage a collection of service account keys for each Google Cloud API you want to use. And both GKE and IAM have service accounts to provide an additional layer of security. IAM Service Accounts, which are defined within Google Cloud instead of GKE, are used for Google Cloud API authentication and authorization for applications. After Workload Identity is enabled on your cluster, an IAM policy can be used to bind an IAM service account to a GKE service account. From there, you can annotate the Kubernetes ServiceAccount object with the name of the IAM service account, and assign the GKE service account to the workloads that will use the Google Cloud APIs. The IAM service account must have an IAM role that matches your application’s required permissions. Separate service accounts improve security and simplify the management, monitoring, and auditing of API requests. For example, if you need to revoke API access for a specific application, you can delete the service account associated with that application instead of having to revoke access to a shared service account, which would impact multiple applications. Instead of using the default Compute Engine service accounts, you can create a dedicated service account for each application that interacts with Google Cloud services, then grant each service account only the specific IAM roles and permissions it needs. Separate service accounts also provide protection in the event of a security breach. If an attacker notices many service accounts, the value of each will appear to be less valuable.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.