DEV Community: ZC

How to Enable Duo MFA on GCP Windows VMs for Compliance in 10 Minutes

ZC — Wed, 28 Jan 2026 07:09:50 +0000

Introduction

The Problem: For the compliance, you might be asking to implement the MFA for running VM in GCP, it is easy when it comes to Linux, but how about Windows?
The Solution: There are not only one solution to achieve the goal, but this time we choose Cisco Duo as the MFA infrastructure.
The Goal: "By the end of this guide, you will have a secure Windows VM that prompts for MFA upon every RDP login."

Architecture Overview

Prerequisites

A running Windows Server VM on GCP.
Admin access to the VM (RDP).
A valid Cisco Duo account (Free trial or Admin access).
Critical Network Check: Ensure the VM allows outbound traffic on TCP port 443 to api-*.duosecurity.com.(It will be used by the installation of Duo Authentication for Windows )

Step 1: Configure Duo Admin Panel

Action: Create a "Protect an Application" entry.
Selection: Choose "Microsoft RDP".
Key Data: Note down the Integration Key (IKEY), Secret Key (SKEY), and API Hostname.

Step 2: Installation on GCP Windows VM

Download: Link to the official Duo Authentication for Windows Logon installer.
Install: Walk through the wizard.
Configuration:
Enter the IKEY, SKEY, and Hostname. (Refers to last step in Step 1)

Step 3: Verification & Troubleshooting

The Test: After the above steps, try to log into Windows and you will see the MFA requirement like below screenshot.

Troubleshooting:
- Problem: "I locked myself out!"
- Solution: Use GCP Serial Console or a startup script to uninstall/bypass Duo in an emergency.

If you accidentally locked yourself out, you could use GCP Serial Console(Windows should choose #2) to get into SAC to stop the service or uninstall the service.

Conclusion

By implementing Cisco Duo on your GCP Windows VM, you have successfully added a critical layer of defense against credential theft and brute-force attacks. Not only does this secure your infrastructure, but it also helps you check the box for compliance standards like SOC2 or PCI-DSS that mandate MFA for remote access.

How To Add The Whitelist for Your Ingress-Nginx Controller of K8S?

ZC — Fri, 13 Dec 2024 06:03:14 +0000

Introduction

Access control is a critical aspect of securing your Kubernetes applications. One way to enhance security is by implementing a whitelist to allow only specific IP addresses to access your services. In this post, I’ll show you how to configure IP whitelisting for your Ingress-Nginx Controller in Kubernetes.

This guide is for anyone using Kubernetes and managing external or internal traffic to their services, such as DevOps engineers and Kubernetes enthusiasts.

Prerequisites

Before we start, ensure you have the following:

A working Kubernetes cluster.
kubectl installed and configured.
Ingress-Nginx Controller already installed.

Understanding Whitelisting in Ingress-Nginx

Whitelisting allows you to restrict access to your application based on IP addresses or CIDR ranges. This is particularly useful for:

Securing internal applications that only certain teams or locations should access.
Protecting sensitive data by limiting external access.

Ingress-Nginx supports whitelisting via annotations, making it straightforward to set up.

Steps to Add a Whitelist

Step 1: Verify Ingress-Nginx Installation

First, check that the Ingress-Nginx Controller is running in your cluster. Use the following command:

kubectl get pods -n ingress-nginx

Look for a pod with a name like ingress-nginx-controller. If it’s not running, install it using Ingress-Nginx installation guides.

Step 2: Identify the IPs to Whitelist

Determine the IP addresses or CIDR ranges you want to allow access. For example:

Internal IPs: 192.168.1.0/24
External static IP: 203.0.113.0/24

Step 3: Configure the Ingress Nginx Controller(!IMPORTANT)

Before we add the whitelist into the ingress resource, we HAVE TO change the externalTrafficPolicy field to Local like below example or the whitelist will not be applied correctly.

The comparison between Local and Cluster for externalTrafficPolicy

Attribute/Behavior	Local	Cluster
Traffic Routing	Routes only to Pods on the node receiving traffic	Distributes traffic to any Pod in the cluster
Client Original IP	Preserved	Replaced by the node’s IP
Traffic Balancing	Requires Load Balancer to balance external traffic	Handled internally by Kubernetes
Network Hops	Few (direct to the target Pod)	More (may forward to other nodes)
Latency	Low	May be slightly higher
Fault Tolerance	Requires Pods to be evenly distributed across nodes	High, as traffic can reach any available Pod
Use Case	When client IP is needed (e.g., for logging or IP-based access control)	For high availability and balanced distribution without needing client IP

...

spec:
  allocateLoadBalancerNodePorts: true
  clusterIP: 10.109.177.97
  clusterIPs:
  - 10.109.177.97
  externalTrafficPolicy: Local # <--- Change it to Local, default is Cluster
  healthCheckNodePort: 32459
  internalTrafficPolicy: Cluster

...

Step 4: Configure the Ingress Resource

To implement the whitelist, add the annotation nginx.ingress.kubernetes.io/whitelist-source-range to your Ingress resource. Below is a sample YAML configuration:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: example-ingress
  annotations:
    nginx.ingress.kubernetes.io/whitelist-source-range: "192.168.1.0/24,203.0.113.0/24"
spec:
  rules:
  - host: example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: example-service
            port:
              number: 80

Save this configuration as ingress.yaml.

Step 5: Apply the Configuration

Apply the YAML configuration using kubectl:

kubectl apply -f ingress.yaml

Verify the configuration:

kubectl describe ingress example-ingress

Check for the annotation and ensure it’s applied correctly.

Step 6: Testing the Whitelist

To confirm the whitelist works as expected, test access from:

Whitelisted IPs: Access the service using a browser or curl:

curl -H "Host: example.com" http://<INGRESS_IP>

Non-Whitelisted IPs: Try accessing from an unlisted IP. You should receive a 403 Forbidden response.

Common Issues and Troubleshooting

Access Denied Despite Proper Configuration:
- Double-check the IP ranges in the annotation.
- Ensure you’re testing from the correct source IP.
Misconfigured CIDR Ranges:
- Validate your CIDR format using online tools like CIDR Calculator.
Ingress Logs:
- Check the logs of your Ingress-Nginx Controller for clues:

kubectl logs -n ingress-nginx <ingress-nginx-controller-pod>

Best Practices

Combine whitelisting with HTTPS to encrypt traffic.
Use ConfigMaps or Secrets to store sensitive configurations.
Regularly review and update the whitelist as network requirements evolve.

Conclusion

Adding a whitelist to your Ingress-Nginx Controller is a simple yet effective way to secure your Kubernetes applications. By restricting access to trusted IPs, you reduce the risk of unauthorized access. Give it a try, and feel free to share your feedback or challenges in the comments below!

References and Further Reading

How To Fix "java.io.IOException: Problem reading font data." When Load Customized TTF In Java.

ZC — Wed, 31 Jul 2024 06:59:48 +0000

Yesterday, my colleague said the service had a problem loading the customized font -- NotoSerif-Regular.ttf on our SIT, but it worked on local, the error was as follows:

After trying several methods, although it was resolved, I still have many questions.

Our containerized service uses the base container image – amazoncorretto:19-alpine.

Below is the solution and it seems that the font-noto package must be installed first, or the problem will exist again.

However, I can only treat it as a workaround but not a good solution.

Because the package I installed contained the TTF file of font covered in the source code developed by our software engineer.

Although I am still looking for the answer, I hope someone encountering this issue can fix the problem quickly.

If someone has known the answer, please casually leave a comment to share your knowledge with us, big thanks!

How Many Ingress Controllers We Need in K8S?

ZC — Mon, 17 Jun 2024 08:17:27 +0000

Generally speaking, using separate namespaces and ingress-nginx controllers for different environments like SIT (System Integration Testing) and UAT (User Acceptance Testing) is a common and effective approach. This design provides isolation between environments, allowing you to configure and manage them independently. However, depending on your specific requirements and infrastructure, there might be alternative or complementary approaches to consider.

Advantages of Separate Namespaces and Ingress Controllers

Isolation: Each environment (SIT and UAT) is isolated, preventing potential conflicts and allowing independent configurations.
Resource Management: Resources can be allocated and managed separately for each environment.
Security: Fine-grained access control can be applied to each namespace.
Scalability: Environments can be scaled independently based on their specific needs.
Environment-Specific Configurations: Different configurations, such as DNS, SSL certificates, and ingress rules, can be applied to each environment.

Alternative and Complementary Approaches

Cluster-per-Environment:
- Description: Deploy separate Kubernetes clusters for SIT and UAT.
- Pros: Complete isolation at the cluster level, allowing for different Kubernetes versions and configurations. Enhanced security and resource isolation.
- Cons: Higher operational overhead and costs due to managing multiple clusters.
Namespace-per-Environment with Single Ingress Controller:
- Description: Use a single ingress-nginx controller with multiple namespaces for SIT and UAT.
- Pros: Simplified management with a single ingress controller. Reduced resource usage.
- Cons: Potential for configuration conflicts and reduced isolation compared to separate controllers.
Use of Network Policies:
- Description: Implement Kubernetes Network Policies to enforce network isolation between namespaces.
- Pros: Enhanced security and isolation without needing multiple ingress controllers.
- Cons: Requires careful planning and configuration of network policies.
Service Mesh:
- Description: Use a service mesh like Istio or Linkerd to manage traffic within and between environments.
- Pros: Advanced traffic management, security, and observability. Can manage traffic routing, retries, and failures more effectively.
- Cons: Additional complexity and resource overhead.
Multi-Tenant Ingress Controller:
- Description: Configure a single ingress controller to handle multiple environments by using annotations and custom configurations.
- Pros: Centralized management and reduced overhead.
- Cons: Complexity in configuring and managing different rules for each environment.

Example: Using a Single Cluster with Namespaces and Network Policies

Namespaces:

kubectl create namespace sit
kubectl create namespace uat

Ingress Controller: Deploy a single ingress-nginx controller, or use separate controllers as needed.

Network Policies:

Define network policies to control traffic between namespaces and to/from the internet.

sit-network-policy.yaml:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-sit-ingress
  namespace: sit
spec:
  podSelector: {}
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          name: sit
    - podSelector:
        matchLabels:
          app: ingress-nginx

uat-network-policy.yaml:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-uat-ingress
  namespace: uat
spec:
  podSelector: {}
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          name: uat
    - podSelector:
        matchLabels:
          app: ingress-nginx

Ingress Resources:

Define separate ingress resources for each environment.

sit-ingress.yaml:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: sit-ingress
  namespace: sit
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /
spec:
  rules:
  - host: sit.example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: sit-service
            port:
              number: 80

uat-ingress.yaml:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: uat-ingress
  namespace: uat
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /
spec:
  rules:
  - host: uat.example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: uat-service
            port:
              number: 80

Summary

Using separate namespaces and ingress-nginx controllers for SIT and UAT is a good practice for isolating environments and managing resources independently. Depending on your needs, you might also consider alternatives like separate clusters, network policies, or a service mesh for more advanced traffic management and security features.

Choose the approach that best fits your organization's infrastructure, resource management capabilities, and operational overhead considerations.

What are SLI, SLO and SLA, and Why are they important in SRE?

ZC — Wed, 05 Jun 2024 03:10:29 +0000

Aspect	Service Level Indicator (SLI)	Service Level Objective (SLO)	Service Level Agreement (SLA)
Definition	A metric that measures the performance of a service. Examples include latency, error rate, throughput, and availability.	A target value or range of values for a particular SLI over a specified time period. It represents the goal for the service's performance.	A formalized contract between a service provider and a customer outlining expected performance standards (often defined by SLOs) and the consequences of not meeting those standards.
Purpose	To provide a quantifiable measure of some aspect of the service's performance.	To set specific, measurable goals for service performance based on SLIs.	To establish clear expectations and responsibilities between the service provider and the customer, including penalties or compensations for not meeting the agreed performance levels.
Examples	- Latency (e.g., 95th percentile response time) - Error rate (e.g., percentage of failed requests) - Availability (e.g., uptime percentage) - Throughput	- 95th percentile latency should be less than 100ms over the last 30 days - Error rate should be less than 0.1% over the last 7 days - Availability should be 99.9% over the last month	- The service will maintain 99.9% availability each month. If availability drops below this threshold, the service provider will credit the customer 10% of their monthly fee for each 0.1% drop below the threshold, up to 50%.
Who Defines It	Engineers and service owners who monitor and manage the service.	Engineers and service owners in collaboration with business stakeholders to ensure the objectives meet business needs and are achievable.	Business leaders, legal teams, and sometimes customers, often with input from engineers and service owners to ensure technical feasibility.
Scope	Specific aspects of service performance, typically focused on technical metrics.	Broader than SLIs, encompassing goals for multiple SLIs, often with business impact considerations.	Broad and formal, encompassing agreed-upon performance standards, legal obligations, and financial implications.
Timeframe	Continuous, providing real-time or near-real-time data on service performance.	Specific periods (e.g., weekly, monthly) over which the service's performance is evaluated against the objective.	Defined contract period, typically monthly or annually, with regular reviews and updates as needed.
Consequences of Not Meeting	Not meeting SLIs typically triggers alerts for engineers to investigate and resolve issues.	Not meeting SLOs may lead to internal reviews and action plans to improve service performance.	Not meeting SLAs typically results in penalties, such as service credits or refunds to the customer, and can damage the service provider's reputation and customer trust.
Visibility	Primarily internal, used by the service provider's engineering teams.	Internal, with visibility to both engineering teams and business stakeholders.	External, visible to both the service provider and the customer, often documented in legal contracts.
Example Metrics	- Average response time - Number of errors - System uptime - Request per second	- 99.9% of requests should have response times under 200ms - Error rate should not exceed 0.1% over a month - 99.99% uptime	- 99.9% availability per month - 99% of support requests answered within 24 hours - 95% of incidents resolved within 4 hours

Summary

SLI: Measures specific aspects of service performance.
SLO: Sets target performance levels for SLIs.
SLA: Formal agreement that includes SLOs and outlines the consequences of not meeting them.

Therefore, service providers can effectively manage and communicate their service performance, ensuring alignment with customer expectations and business objectives.

The flow of creating digital signatures and verification in Python

ZC — Mon, 03 Jun 2024 01:27:46 +0000

This flow demonstrates how to create and verify a digital signature using the cryptography library in Python. This process ensures the authenticity and integrity of the message, confirming that it was signed by the holder of the private key and has not been altered.
There are main 3 steps.

Generate Key Pair:
- Private Key: Created using RSA, with a public exponent of 65537 and a key size of 2048 bits.
- Public Key: Derived from the private key.
- Storage: Both keys are saved to files in PEM format.
Sign the Message:
- Message: The data to be signed.
- Hash Function: SHA-256 is used to hash the message.
- Padding: PSS (Probabilistic Signature Scheme) with MGF1 (Mask Generation Function) and a maximum salt length is used for padding.
- Signature: The message is signed using the private key, and the signature is saved to a file.
Verify the Signature:
- Public Key: Loaded from the PEM file.
- Signature: Loaded from the file.
- Message: The original message that was signed.
- Verification: The public key, along with the message and the signature, is used to verify the authenticity of the signature. If the signature is valid, it means the message was signed by the corresponding private key.

Step 1: Install the Required Library

First, ensure you have the cryptography library installed. You can install it using pip:

pip install cryptography

Step 2: Generate a Key Pair

A key pair consists of a private key (used for signing) and a public key (used for verification).

from cryptography.hazmat.primitives.asymmetric import rsa
from cryptography.hazmat.primitives import serialization

# Generate private key
private_key = rsa.generate_private_key(
    public_exponent=65537,
    key_size=2048,
)

# Generate public key from the private key
public_key = private_key.public_key()

# Save the private key to a file
with open("private_key.pem", "wb") as f:
    f.write(private_key.private_bytes(
        encoding=serialization.Encoding.PEM,
        format=serialization.PrivateFormat.PKCS8,
        encryption_algorithm=serialization.NoEncryption()
    ))

# Save the public key to a file
with open("public_key.pem", "wb") as f:
    f.write(public_key.public_bytes(
        encoding=serialization.Encoding.PEM,
        format=serialization.PublicFormat.SubjectPublicKeyInfo
    ))

Step 3: Sign a Message

To create a digital signature, you'll use the private key to sign a message.

from cryptography.hazmat.primitives import hashes
from cryptography.hazmat.primitives.asymmetric import padding

# Message to be signed
message = b"Hello, this is a secret message!"

# Sign the message
signature = private_key.sign(
    message,
    padding.PSS(
        mgf=padding.MGF1(hashes.SHA256()),
        salt_length=padding.PSS.MAX_LENGTH
    ),
    hashes.SHA256()
)

# Save the signature to a file
with open("signature.bin", "wb") as f:
    f.write(signature)

Step 4: Verify the Signature

To verify the signature, use the public key to check if it matches the message.

# Load the public key
with open("public_key.pem", "rb") as f:
    public_key = serialization.load_pem_public_key(f.read())

# Load the signature
with open("signature.bin", "rb") as f:
    signature = f.read()

# Message to be verified
message = b"Hello, this is a secret message!"

# Verify the signature
try:
    public_key.verify(
        signature,
        message,
        padding.PSS(
            mgf=padding.MGF1(hashes.SHA256()),
            salt_length=padding.PSS.MAX_LENGTH
        ),
        hashes.SHA256()
    )
    print("The signature is valid.")
except:
    print("The signature is invalid.")

How To Apply The GCP Service Account Into On-premise K8S Step By Step

ZC — Thu, 30 May 2024 03:31:07 +0000

Applying a GCP service account to a local Kubernetes cluster involves a few steps to ensure that your Kubernetes pods can authenticate to GCP services using the service account. Here's a detailed guide to achieve this:

Step-by-Step Guide

1. Create a GCP Service Account

First, create a service account in your GCP project and download the JSON key file.

Create the Service Account:

gcloud iam service-accounts create my-service-account --display-name "My Service Account"

Assign Roles to the Service Account:

gcloud projects add-iam-policy-binding <YOUR-PROJECT-ID> \
    --member="serviceAccount:my-service-account@<YOUR-PROJECT-ID>.iam.gserviceaccount.com" \
    --role="roles/YOUR-ROLE"

Replace <YOUR-PROJECT-ID> with your GCP project ID and roles/YOUR-ROLE with the appropriate roles you need for your service account.

Create and Download the Key File:

gcloud iam service-accounts keys create key.json \
    --iam-account my-service-account@<YOUR-PROJECT-ID>.iam.gserviceaccount.com

2. Create a Kubernetes Secret with the Service Account Key

Next, create a Kubernetes secret that contains the service account key file.

Create the Secret:
```
kubectl create secret generic gcp-service-account \
    --from-file=key.json=path/to/key.json
```
Replace path/to/key.json with the actual path to your downloaded service account key file.

3. Configure Your Pods to Use the Service Account

Modify your Kubernetes deployment or pod specification to mount the service account key as a volume and set the GOOGLE_APPLICATION_CREDENTIALS environment variable.

Update Deployment YAML:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
spec:
  replicas: 1
  selector:
    matchLabels:
      app: my-app
  template:
    metadata:
      labels:
        app: my-app
    spec:
      containers:
      - name: my-app
        image: gcr.io/<YOUR-PROJECT-ID>/my-app:latest
### Keypoint Start
        env:
        - name: GOOGLE_APPLICATION_CREDENTIALS
          value: /var/secrets/google/key.json
        volumeMounts:
        - name: gcp-service-account
          mountPath: /var/secrets/google
          readOnly: true
      volumes:
      - name: gcp-service-account
        secret:
          secretName: gcp-service-account
### Keypoint End

In this example:

Replace gcr.io/<YOUR-PROJECT-ID>/my-app:latest with the image you are using.
The environment variable GOOGLE_APPLICATION_CREDENTIALS is set to the path where the key file will be mounted.
The secret named gcp-service-account is mounted as a volume at /var/secrets/google.

Apply the Updated Deployment:
```
kubectl apply -f deployment.yaml
```

Summary

By following these steps, you can configure your local Kubernetes cluster to use a GCP service account. This setup involves creating a GCP service account, generating and downloading a key file, creating a Kubernetes secret with the key file, and configuring your pods to use the service account by mounting the secret and setting the appropriate environment variable. This allows your applications running in Kubernetes to authenticate with GCP services securely.

How To Pull The Images on GCP Artifact Registry From On-premise K8S

ZC — Thu, 30 May 2024 03:25:41 +0000

To access Google Cloud Platform (GCP) Artifact Registry from a local Kubernetes cluster using a service account key file, you need to follow these steps:

Create a GCP Service Account and Key File
Create a Kubernetes Secret with the Service Account Key
Configure Your Kubernetes Deployment to Use the Secret
Pull Images from Artifact Registry

Step-by-Step Guide

1. Create a GCP Service Account and Key File

Create the Service Account:

   gcloud iam service-accounts create my-service-account --display-name "My Service Account"

Grant the Necessary Roles to the Service Account:

   gcloud projects add-iam-policy-binding <YOUR-PROJECT-ID> \
       --member="serviceAccount:my-service-account@<YOUR-PROJECT-ID>.iam.gserviceaccount.com" \
       --role="roles/artifactregistry.reader"

Replace <YOUR-PROJECT-ID> with your GCP project ID.

Create and Download the Key File:

   gcloud iam service-accounts keys create key.json \
       --iam-account my-service-account@<YOUR-PROJECT-ID>.iam.gserviceaccount.com

2. Create a Kubernetes Secret with the Service Account Key

Create the Secret:

   kubectl create secret docker-registry gcp-artifact-registry \
       --docker-server=LOCATION-docker.pkg.dev \
       --docker-username=_json_key \
       --docker-password="$(cat key.json)" \
       --docker-email=your-email@example.com

Replace:

LOCATION with the location of your Artifact Registry (e.g., us-central1).
your-email@example.com with your email.

3. Configure Your Kubernetes Deployment to Use the Secret

Update your Kubernetes deployment YAML to reference the secret for pulling images.

Update Deployment YAML:

   apiVersion: apps/v1
   kind: Deployment
   metadata:
     name: my-app
   spec:
     replicas: 1
     selector:
       matchLabels:
         app: my-app
     template:
       metadata:
         labels:
           app: my-app
       spec:
         containers:
         - name: my-app
           image: LOCATION-docker.pkg.dev/PROJECT-ID/REPOSITORY/IMAGE:TAG
           ports:
           - containerPort: 8080
         imagePullSecrets:
         - name: gcp-artifact-registry

Replace the placeholders:

LOCATION with your Artifact Registry location (e.g., us-central1).
PROJECT-ID with your GCP project ID.
REPOSITORY with the name of your repository.
IMAGE:TAG with the specific image and tag you want to use.

Apply the Deployment:

   kubectl apply -f deployment.yaml

4. Verify the Setup

Check the Deployment Status:

   kubectl get pods

Describe a Pod to Verify Image Pull:

   kubectl describe pod <POD-NAME>

Look for the events section to see if the image was pulled successfully.

Summary

By following these steps, you configure your local Kubernetes cluster to authenticate with GCP Artifact Registry using a service account key file. This involves creating a service account and key, storing the key as a Kubernetes secret, and updating your deployments to use the secret for image pulls. This setup ensures secure and efficient access to your container images stored in GCP Artifact Registry.

Refs

https://cloud.google.com/artifact-registry/docs/docker/pushing-and-pulling#key
https://cloud.google.com/artifact-registry/docs/docker/authentication#json-key

Why Use "kubectl proxy" and What Is The Disadvantage?

ZC — Fri, 26 Apr 2024 06:37:23 +0000

The kubectl proxy command creates a proxy server or API proxy on your local machine that provides an API gateway to the Kubernetes API server. This proxy server provides an intermediate link between your local setup and the Kubernetes API, handling the authentication process to allow you to interact with the cluster without needing to explicitly manage credentials for each request.

Why Use `kubectl proxy`?

Simplified Access: It simplifies access to the Kubernetes API without needing to manage authentication tokens directly in your client code. kubectl proxy handles authentication to the Kubernetes API for you, making it easier to interact with the cluster.
Development and Testing: It's particularly useful in development environments when you need to frequently interact with the Kubernetes API. You can easily query the API, inspect different parts of the cluster, or debug your applications.
Security: Using kubectl proxy can improve security because it restricts API access to the services that are accessible from the local machine. It provides a more secure way to access the cluster internals without exposing them to the outside network.
API Exploration: If you're developing applications that interact with Kubernetes, or if you're just learning the Kubernetes API, kubectl proxy provides a quick and secure way to explore the API. It allows you to browse the REST API of Kubernetes via a web browser or use standard tools like curl.

When to Use `kubectl proxy`?

Development and Debugging: When developing or debugging applications that interact with Kubernetes, using kubectl proxy can provide easy and secure access to the cluster API.
Accessing the Kubernetes Dashboard: If you're using the Kubernetes Web UI (Dashboard), kubectl proxy can provide access to the dashboard without exposing it to the public internet. You can run the proxy and then navigate to the dashboard URL provided by the proxy in your browser.
Quick API Access for Scripts and Local Testing: For scripts or local testing scenarios where you might need to interact with the Kubernetes API, kubectl proxy can facilitate this interaction without complex configuration.
Educational Purposes: When learning how Kubernetes works and how to interact with its API, running kubectl proxy allows you to explore API endpoints directly from your browser or command line.

How to Use `kubectl proxy`?

Here is a basic example of how to start kubectl proxy:

kubectl proxy

This command starts the proxy at localhost:8001. Once the proxy is running, you can access the API at http://localhost:8001/api/. For example, to get details about the Kubernetes nodes via the API, you could use:

curl http://localhost:8001/api/v1/nodes

Or simply use your web browser to navigate to http://localhost:8001/api/v1/nodes.

What is the disadvantage of it?

While kubectl proxy is a helpful tool for interfacing with the Kubernetes API in various scenarios, it does have some limitations and disadvantages that might affect its suitability for certain uses:

1. Limited to Local Access

kubectl proxy runs on the local machine and does not natively support remote access. This makes it less suitable for environments where access from different network locations is required unless additional network configurations (like VPNs or port forwarding) are set up.

2. Not Suitable for Production Use

Due to its nature as a development tool, kubectl proxy is not designed for production use. It lacks the robustness, scalability, and security features needed for safe production environments.

3. Performance Overhead

Running kubectl proxy can introduce an additional layer of overhead because it acts as an intermediate proxy server. This might not be significant for small-scale or development environments but can become noticeable with extensive API interactions or large-scale operations.

4. Security Implications

While kubectl proxy provides a secure way to access the Kubernetes API by handling authentication locally, it also means that any application running on your local machine could potentially access the Kubernetes API through the proxy. This could pose a security risk if the local environment is compromised.

5. Simplicity with Limitations

kubectl proxy simplifies access by handling authentication, but it also means that more complex authentication scenarios (e.g., using different credentials for different parts of the API) are harder to manage directly through the proxy.

6. No Built-in Load Balancing

kubectl proxy provides a straightforward connection to the Kubernetes API but does not handle load balancing or failover for the Kubernetes API servers. This means it is less resilient to API server failures compared to more sophisticated proxy or API gateway solutions.

7. Dependency on kubectl

The proxy's availability and functionality are tied to the kubectl command line tool, which may not always be ideal or convenient, especially in automated scripts or environments where minimal dependencies are preferred.

8. Limited Customization

kubectl proxy offers limited options for customization. Unlike full-featured API gateways or custom proxy servers, you cannot configure things like custom headers, caching policies, or detailed logging.

When to Consider Alternatives:

Given these limitations, for scenarios that require high availability, secure remote access, or are intended for production environments, it's advisable to look into more robust solutions like:

Dedicated API gateways (e.g., Kong, Tyk)
Cloud provider-specific solutions (e.g., AWS API Gateway, Azure API Management)
Advanced ingress controllers in Kubernetes (e.g., NGINX Ingress, Traefik) that offer more control, scalability, and security features.

In summary, while kubectl proxy is excellent for development, testing, and learning purposes, it is not suitable for production environments or situations requiring advanced configuration and robust access management.

In summary, kubectl proxy is a useful tool for safely interacting with the Kubernetes API, especially during development, debugging, and learning phases. It offers a straightforward way to communicate with your cluster without complex authentication management.

Why does"etcd" Matter In Kubernetes?

ZC — Fri, 26 Apr 2024 05:51:49 +0000

etcd is a critical component primarily used in distributed systems, providing consistent and highly available key-value storage. Below are several key reasons and the importance of using etcd:

1. Coordination and State Management in Distributed Systems

etcd offers a reliable way to store and synchronize crucial data in distributed systems. This is vital for managing cluster states, configuration information, and coordinating distributed deployments.

2. Consistency Guarantees

etcd is designed based on the Raft consensus algorithm, which maintains strong data consistency across cluster nodes. Even in the case of network partitions or node failures involving multiple nodes, etcd ensures that data is not lost and automatically restores data consistency when the cluster resumes normal operation.

3. Backing Store for Kubernetes

In Kubernetes clusters, etcd serves as the backing store for all cluster data. This includes the states of pods, services, secrets, and configuration data. The reliability of this information directly affects the stability and operability of the Kubernetes cluster.

4. Service Discovery and Configuration Management

etcd can be used for service discovery and configuration management. Due to its high availability and consistency characteristics, many distributed applications and services use etcd to store configuration information and service location details for quick and reliable querying.

5. Locks and Leader Election

etcd provides distributed locks and leader election mechanisms. These are crucial for handling distributed computations and ensuring that operations across multiple processing nodes are serialized, ensuring process order and consistency.

6. Easy Integration and Language Agnosticism

etcd provides an HTTP/JSON API, which allows for easy integration with various programming languages and environments. Its openness and extensibility enable developers to use etcd flexibly according to their needs.

In summary, etcd is an indispensable component in distributed systems, especially in environments that require high consistency and reliability. Its design philosophy is to address critical issues in distributed environments, such as data consistency, service discovery, state management, and multi-node synchronization. In Kubernetes and other systems that require strong consistency guarantees, the role of etcd is particularly important.

Install K8S On Rocky Linux by A Shell Script

ZC — Tue, 09 Apr 2024 03:23:58 +0000

I recently had to install Kubernetes on our on-premise servers. Sure, there were a lot of instructions on the internet that people shared. However, I am a lazy guy. I like to do anything as simple as possible so that I create a shell script depending on the website.
I have pushed it into my GitHub Repo. Be lazy...

DEV Community: ZC

How to Enable Duo MFA on GCP Windows VMs for Compliance in 10 Minutes

Introduction

Architecture Overview

Prerequisites

Step 1: Configure Duo Admin Panel

Step 2: Installation on GCP Windows VM

Step 3: Verification & Troubleshooting

Conclusion

How To Add The Whitelist for Your Ingress-Nginx Controller of K8S?

Introduction

Prerequisites

Understanding Whitelisting in Ingress-Nginx

Steps to Add a Whitelist

Step 1: Verify Ingress-Nginx Installation

Step 2: Identify the IPs to Whitelist

Step 3: Configure the Ingress Nginx Controller(!IMPORTANT)

Step 4: Configure the Ingress Resource

Step 5: Apply the Configuration

Step 6: Testing the Whitelist

How To Fix "java.io.IOException: Problem reading font data." When Load Customized TTF In Java.

How Many Ingress Controllers We Need in K8S?

Advantages of Separate Namespaces and Ingress Controllers

Alternative and Complementary Approaches

Example: Using a Single Cluster with Namespaces and Network Policies

Summary

What are SLI, SLO and SLA, and Why are they important in SRE?

Summary

The flow of creating digital signatures and verification in Python

Step 1: Install the Required Library

Step 2: Generate a Key Pair

Step 3: Sign a Message

Step 4: Verify the Signature

How To Apply The GCP Service Account Into On-premise K8S Step By Step

Step-by-Step Guide

1. Create a GCP Service Account

2. Create a Kubernetes Secret with the Service Account Key

3. Configure Your Pods to Use the Service Account

Summary

How To Pull The Images on GCP Artifact Registry From On-premise K8S

Step-by-Step Guide

1. Create a GCP Service Account and Key File

2. Create a Kubernetes Secret with the Service Account Key

3. Configure Your Kubernetes Deployment to Use the Secret

4. Verify the Setup

Summary

Refs

Why Use "kubectl proxy" and What Is The Disadvantage?

Why Use kubectl proxy?

When to Use kubectl proxy?

How to Use kubectl proxy?

What is the disadvantage of it?

1. Limited to Local Access

2. Not Suitable for Production Use

3. Performance Overhead

4. Security Implications

5. Simplicity with Limitations

6. No Built-in Load Balancing

7. Dependency on kubectl

8. Limited Customization

When to Consider Alternatives:

Why does"etcd" Matter In Kubernetes?

1. Coordination and State Management in Distributed Systems

2. Consistency Guarantees

3. Backing Store for Kubernetes

4. Service Discovery and Configuration Management

5. Locks and Leader Election

6. Easy Integration and Language Agnosticism

Install K8S On Rocky Linux by A Shell Script

Why Use `kubectl proxy`?

When to Use `kubectl proxy`?

How to Use `kubectl proxy`?