Saturday, March 18, 2023

Google Professional Cloud Security Engineer Exam Prep notes - Part 4

 Google API Private Access

Private Google Access is configured at the subnet level and allows subnetworks to access GCP services privately. The resources in the subnet can access Google services without an external IP, for eg: Cloud storage, Youtube, etc. It offers better security as the exposure to outside networks is reduced, thereby minimizing the possibilities of data interception and attacks.

Google cloud service accounts

 These accounts are used for service-to-service authentication. For eg: an application in compute engine can use a service account to access a storage account 

Two types of service accounts - Google-managed service accounts & user-managed service accounts

In Google-managed service accounts, the private and public keys are managed by Google. Each key can be used for a max of two weeks. Private keys of google managed keys are never directly accessible and the platform itself manages the key rotation process

With user-managed keys, only public keys are stored in Google. users should manage the private key , keeping them secure and also for key rotation. For key rotation, you can create up to 10 user-managed service account keys per service

IAM policies and conditions

IAM policy can be considered as a statement of access permissions attached to a resource. Components of policy are a set of roles and role members. Resources inherit policies from the parent resource. Policies specific to a resource are a combination of parent policy and policies assigned to that resource. It is important to note that a least restrictive parent policy will override a more restrictive resource-specific policy. 

 IAM policies have role bindings that bind an IAM principle to a specific role. IAM conditions can be used to specify attribute-based access, ie either allow or deny access based on specific attributes and if the configured conditions are met. These conditions can either be resource or request-specific. For eg: allow access only to cloud SQL service with a specific name prefix

Organization policies 

Organizational policies provide centralized control over all projects in an organization. They can be set on organizations, folders, and projects. You can configure constraints to implement restrictions on Google services. These restrictions will be applied to the specific resource at which it is applied and all its descendants. There are two types of constraints - lists and booleans

Sample usage of list constraint is to create a list of VMs restricted from having external IPs. Enabling and disabling features such as nested virtualization, serial port access, service account creation, etc are boolean constraints. You can also configure at each resource hierarchy node whether you want to inherit the policies from the parent node. 

Difference between organization policies and IAM policies

Organization policies are used to define the "what" ie what restrictions you want to implement on your resources

IAM policies are focussed on the "Who", ie who is authorized to take specific actions on resources based on assigned permissions


Sunday, March 12, 2023

Tech basics series : Containers , Microservices & Kubernetes - Part 3

 In the third part of our tech basics series on Containers, Microservices & Kubernetes, we will talk about Pods, ReplicaSets, and Replication controllers. If you are new here, do check out Part 1 and Part 2 of this blog series first!!

What are Pods?

Pods are the smallest object you can create in Kubernetes that encapsulates containers. Imagine a single node K8s clusters running a single pod. When the application needs to scale, you create additional pods of the same application. The pods can also be distributed across multiple nodes in a cluster. Usually, the relationship between pods and containers is 1:1, but it is not mandatory. There is a case of a side car  container as well, which could be helping the main application and included in the same pod. Every time a new pod of the application is created, both the main container and sidecar container are created together. They share the same network and storage and can connect to each other as localhost. 

Basic commands to manage pods

1. Command to run a container in K8s :

kubectl run <pod name> --image <image name>>

Image can be fetched from any container registry , for eg: Docker hub. Image name has to match the name in the registry

2. To view status of running pods:

kubectl get pods

3. To get additional details of the pods:

kubectl describe pod <name of the pod>

3. Command to view details of the node where the pod is deployed, its IP address etc:

kubectl get pods -o  wide

4. Sample yaml file for a pod:

You can use the below command to create the pod

kubectl create -f pod-definition.yml

ReplicaSets & Replicas

If there is only one instance of the application running on a pod, the application will become unavailable if the pod fails. To prevent users from losing access, you can have more than one application instance running in multiple pods. This is enabled by the replication controller. Even in the case of a single pod, the replication controller can bring back the pod if it fails. The replication controller spans multiple nodes in a cluster. When the demand for application increases, the replication controller can deploy the pods across multiple nodes as well to scale the application. ReplicaSets is the new version of the replication controller and is used in current versions of Kubernetes

The details of the replica set are defined in the spec of the replication controller yaml file by adding a section called template, please see sample yaml file here to create a ReplicaSet. You can see that we have additionally specified the number of replicas and a selector in the yaml file. 

kubectl create -f replicaset.yaml

Kubectl get replicaset

Replicaset will monitor the pods and recreate them if they fails. For replicaset to do that we need to create labels for pods while creating the poids. Now we can use the "matchLabels" filters to identify which pods should be monitored by ReplicaSets. Even if you have created additional pods not included in the yaml file definition of the replicaset, it can monitor them based on the labels of the pods and ensure that the number of replicas of the pod(3, in this example) is always running.

If you want to scale your application, you can update the number of replicas in the definition file and run the following command

kubectl replace -f replicaset.yaml

Or you can use the kubectl scale command

or you can increase the replicas on the fly using the following command

kubectl scale --replicas=6 replicaset.yaml


Total Pageviews

About Me

Cloud Solutions expert with 17+ years of experience in IT industry with expertise in Multi cloud technologies and solid background in Datacentre management & Virtualization. Versatile technocrat with experience in cloud technical presales, advisory, innovation , evangelisation and project delivery. Currently working with Google as Infra modernization specialist, enabling customers on their digital transformation journey . I enjoy sharing my experiences in my blog, but the opinions expressed in this blog are my own and does not represent those of people, institutions or organizations that I may be associated with in professional or personal capacity, unless explicitly stated.

Search This Blog

Powered by Blogger.