Connect

The connection between Google Cloud and Connect

Each connected cluster receives requests from the Google Cloud control plane over Connect, and the control plane receives responses from the cluster. Through the connection, clusters can be reached and authenticated by authorized users and Google-side automation. Connect enables Anthos Config Management to install or update the Connect in-cluster agent and monitor the sync status. It also enables the Google Cloud UI to obtain information about workloads and services. 

Controller access and user access to clusters through Connect

User access  

1. Anthos: Control Anthos components and clusters with fleet-registered workloads.
    
2. Kubernetes Engine: Control clusters and workloads registered with the fleet.
    
3. Cloud Run for Anthos: Create, distribute, and control services and programs.
    
4. Marketplace: Manage and deploy applications from other parties.

Controller access 

1. Feature Authorizer: Feature Authorizer adds RBAC for Kubernetes clusters' fleet-enabled components or features, guaranteeing that each has only the particular rights necessary to carry out its duties.
    
2. Anthos Config Management: The Anthos Config Management controller oversees all of the in-cluster agents for a fleet of clusters and offers a UI that displays the status of Anthos Config Management for each cluster.
    
3. Usage metering: To provide billing services, the metering controller analyses the fundamental data about linked clusters.

Connect security features

The security features of Connect are described in this section of the blog.

Architecture of Connect

The Connect Agent connects to a Connect proxy while running in the Kubernetes cluster (one agent per cluster). Connecting to the proxy allows Google Cloud services that require communication with the GKE cluster to send requests to the agent. As shown in the following picture, the agent then transmits them to the GKE API server.

In order to wait for requests, the agent creates a permanent TLS 1.2 connection to Google Cloud when it is launched. When enabled by administrators, Google Cloud services are able to create requests for your Kubernetes clusters.

The proxy receives the request from the Google Cloud service. The deployed agent in charge of a cluster has forwarded the request via the proxy after which the agent sends it on to the GKE API server. The Kubernetes authentication, authorization, and audit-logging policies are applied by the GKE API server before it sends a response. The Google Cloud service receives the response after passing it through the agent and the proxy. Components carry out per-connection and per-request authentication and authorization at each stage of the procedure.

Component-to-component security

Each Connect request component authenticates its peers, and it only distributes data with peers who have been verified as allowed to receive it.

Each Connect request component uses the following to verify one another:

1. Transportation Layer Security(TLS)
2. Security for Application Layer Transport (ALTS)
3. OAuth 

The following are used by each component of a Connect request to authorize one another:

1. Identification and Access Control (IAM)
2. Allowlists

At least one peer of every connection between the Kubernetes cluster and Google Cloud employs certificate-based authentication, and all connections are encrypted.

Request security

The credentials of the Google Cloud service that created the request as well as (if appropriate) the end user for whom the request was submitted are included in each request sent from Google Cloud using Connect. The GKE API server can provide authorization and auditing controls for each request thanks to these credentials. it entails Service-to-Kubernetes authentication, Service-to-Agent authentication, and End-user authentication.

In-cluster security

The following figure shows how the agent ultimately transmits GKE API queries to the GKE API server. 

Like all other requests it handles, the GKE API server authenticates, authorizes, and audit logs these requests. The agent has access to sensitive information, including credentials, requests, and responses, as a proxy for these requests. Kubernetes and the Kubernetes ecosystem provide a collection of tools to help guarantee that the agent only access the resources it is authorized to access and stop other actors from gaining that access.

Updating the Connect Agent in a cluster

The Connect Agent is periodically updated automatically in a non-disruptive manner. However, you can manually register a cluster to update the Connect Agent to the most recent version. The most recent Connect Agent is obtained by gcloud, which then reinstalls it in the cluster.

Rotate the Connect Agent Service Account key

Step 1: Prepare:

PROJECT=[PROJECT_ID]
NAMESPACE=$(kubectl get ns -o jsonpath={.items..metadata.name} -l hub.gke.io/project)
SERVICE_ACCOUNT=$(kubectl get secrets -n $NAMESPACE creds-gcp \
-o jsonpath='{.data.creds-gcp\.json}' |  base64 -d | grep client_email \
| awk '{print $2}' | tr -d '",')
OLD_KEY_ID=$(kubectl get secrets -n $NAMESPACE creds-gcp \
-o jsonpath='{.data.creds-gcp\.json}' |  base64 -d | grep private_key_id \
| awk '{print $2}' | tr -d '",')

Step 2: Produce a fresh key:

gcloud iam service-accounts keys create --iam-account=$SERVICE_ACCOUNT creds-gcp.json

Step 3: Replace the agent's current key.

Step 4: Verify the agent's pod logs to see if it has been reconnected.

Step 5: Remove the previous key.

Step 6: Remove the new key's local copy.

Exposing Connect Agent Deployment

Step 1: Transfer the specific configuration to the gke-connect-agent.yaml file. The Connect Agent Deployment is exposed by the Service gke-connect-agent, which is created by this configuration.

Step 2: Where KUBECONFIG is the path to the cluster's kubeconfig file, apply the YAML file to the Connect Agent's namespace in your cluster.

Step 3: Connect the fleet Google service account to the roles/monitoring.metricWriter IAM role.

Audit logs 

1. For Anthos, the following audit log categories are available:
   • Audit logs for admin activity
   • comprise "admin write" activities that store settings or metadata.
      
2. Audit logs for admin activity cannot be turned off.
   • Audit logs for Data Access
   • Contains "admin read" actions that read configuration or metadata. comprises "data write" and "data read" actions that read or write data supplied by the user.

Audit log format

The log entry itself, which is an object of type LogEntry. The following fields are useful:

• The resource ID and audit log type are both contained in the logName.
• The resource includes the audited operation's aim.
• The time of the audited operation is contained in the timeStamp.
• The audited data is contained in the protoPayload.

Enabling audit logging

Audit logs for admin activity are never disabled; they are always enabled. Except for Data Access audit logs for BigQuery, which cannot be disabled, data access audit logs are disabled by default and are not written unless expressly enabled.

Route audit logs

You may want to route your audit logs for the following reasons:

• You can send copies of your audit logs to Cloud Storage, BigQuery, or Pub/Sub to store them for longer or to employ more robust search tools.
• You can establish aggregated sinks that can transport logs from any or all Cloud projects in the business to manage your audit logs throughout the entire organization.
• You can build sinks that exclude the Data Access audit logs from Logging if your enabled Data Access audit logs are pushing your Cloud projects beyond your log allotments.

Also see, kubernetes interview questions

Frequently Asked Questions

What is Google Compute Engine?

The core element of the Google Cloud Platform is Google Cloud Engine. It is an IaaS that offers adaptable, self-managed, Linux- and Windows-based virtual machines that are hosted on the Google infrastructure.

Which open-source cloud computing systems are the most widely used? 

Docker, OpenStack, Cloud Foundry, Apache Mesos, and KVM are open-source cloud computing systems.

What are the various software as a service (SaaS) models?

In Single multi-tenancy, you have exclusive access to your own resources and don't share them with anybody else. In Multi-tenancy of fine grain Even if the features are the same, in this form of SaaS setup, multiple tenants share the resources.

Conclusion

To conclude this blog, we discussed logging in using connect, the connection between google cloud and connect, and connect security features. We also discussed updating connect agents in clusters, exposing connect agent deployment, and lastly audit logs. 

For more content, Refer to our guided paths on Coding Ninjas Studio to upskill yourself.

Do upvote our blogs if you find them helpful and engaging!

Happy Learning!