Skip to content

CKS

Restricting linux capabilities with AppArmor

Introduction

AppArmor (Application Armor) is a Linux kernel security module that provides mandatory access control (MAC) to restrict the capabilities of programs.

It enforces security policies, known as profiles, that define the file system and network resources a program can access. By confining applications, AppArmor reduces the potential impact of security breaches, limiting the damage a compromised application can cause.

It is known for its ease of use and integration with various Linux distributions, providing a robust layer of defense to enhance system security.

Key Concepts

  • Profiles: AppArmor profiles define the permitted and denied actions for an application, enhancing security by restricting programs to a limited set of resources.
  • Modes: AppArmor operates in two modes:
    1. Enforcement: Enforces the rules defined in the profile, blocking any unauthorized actions.
    2. Complain: Logs unauthorized actions but does not block them, useful for developing and testing profiles.

Profile Components

  • Capability Entries: Define allowed capabilities (e.g., network access, raw socket usage).
  • Network Rules: Control access to network resources.
  • File access permissions: Specify file and directory access permissions.
#include <tunables/global>

profile /bin/ping {
  # Include common safe defaults
  #include <abstractions/base>
  #include <abstractions/nameservice>

  # Allow necessary capabilities
  capability net_raw,
  capability setuid,

  # Allow raw network access
  network inet raw,

  # File access permissions
  /bin/ping ixr,
  /etc/modules.conf r,
}

Common Commands

Check Profile Status.
aa-status
Load/Unload Profiles
sudo apparmor_parser -r <profile_file>
Disables a profile
sudo aa-disable <profile_name>
Switches a profile to complain mode.
sudo aa-complain <profile_name>
Switches a profile to enforce mode.
sudo aa-enforce <profile_name>

Best Practices

  • Least Privilege: Ensure profiles grant the minimum necessary permissions to applications.
  • Regular Updates: Keep profiles up to date with application changes and security patches.
  • Testing: Use complain mode to test new or modified profiles before enforcing them.
  • Monitoring: Regularly check logs for denied actions to identify potential issues or required profile adjustments.

Kubernetes Integration

In Kubernetes, you can enhance pod security by specifying AppArmor profiles within the securityContext of a pod or container.

Pod-Level AppArmor Profile:

To apply an AppArmor profile to all containers in a pod, include the securityContext in the pod specification:

apiVersion: v1
kind: Pod
metadata:
  name: apparmor-pod
spec:
  securityContext:
    appArmorProfile:
      type: Localhost
      localhostProfile: my-apparmor-profile
  containers:
    - name: my-container
      image: my-image

Container-Level AppArmor Profile:

To apply an AppArmor profile to a specific container, define the securityContext within the container specification:

apiVersion: v1
kind: Pod
metadata:
  name: apparmor-pod
spec:
  containers:
    - name: my-container
      image: my-image
      securityContext:
        appArmorProfile:
          type: Localhost
          localhostProfile: my-apparmor-profile

Key Points:

  • Profile Types:
  • RuntimeDefault: Uses the container runtime's default AppArmor profile.
  • Localhost: Uses a profile loaded on the host; specify the profile name in localhostProfile.

  • Unconfined: Runs the container without AppArmor confinement.

  • Profile Availability: Ensure the specified AppArmor profiles are loaded on all nodes where the pods might run. You can verify loaded profiles by checking the /sys/kernel/security/apparmor/profiles file on each node.

  • Kubernetes Version Compatibility: The use of securityContext for AppArmor profiles is supported in Kubernetes versions 1.30 and above. For earlier versions, AppArmor profiles are specified through annotations.

By configuring AppArmor profiles within the securityContext, you can effectively manage and enforce security policies for your applications in Kubernetes, enhancing the overall security of your containerized environments.

Scanning Images with Trivy.

Introduction

Trivy is an open-source security scanner that detects vulnerabilities in container images, file systems, and Git repositories. It identifies security issues in both operating system packages and application dependencies within the container. By using a regularly updated vulnerability database, Trivy helps ensure that containers are secure and compliant with security best practices.

Commands

Trivy commands specifically related to image scanning that are useful for the CKS exam:

Basic Image Scan

trivy image <image_name>

Scans a specified container image for vulnerabilities.

Output and Formatting

  • Output in JSON Format:
trivy image -f json -o results.json <image_name>

Scans the image and outputs the results in JSON format to a file.

  • Output in Table Format:
trivy image -f table <image_name>

Scans the image and outputs the results in a table format (default format).

Severity Filtering

  • Filter by Severity:
trivy image --severity HIGH,CRITICAL <image_name>

Scans the image and reports only high and critical severity vulnerabilities.

Cache Management

  • Clear Cache:
trivy image --clear-cache

Clears the local cache used by Trivy before scanning the image.

Ignoring Specific Vulnerabilities

  • Ignore Specific Vulnerabilities:
trivy image --ignorefile .trivyignore <image_name>

Uses a .trivyignore file to specify vulnerabilities to ignore during scanning.

Advanced Options

  • Timeout Setting:
trivy image --timeout 5m <image_name>

Sets a timeout for the scanning process.

  • Ignore Unfixed Vulnerabilities:
trivy image --ignore-unfixed <image_name>

Ignores vulnerabilities that do not have a fix yet.

  • Skip Update:
trivy image --skip-update <image_name>

Skips updating the vulnerability database before scanning.

Comprehensive Scan with All Details

trivy image --severity HIGH,CRITICAL --ignore-unfixed --skip-update -f json -o results.json <image_name>

A comprehensive scan that filters by severity, ignores unfixed vulnerabilities, skips database update, and outputs results in JSON format to a file.

These commands allow you to perform detailed and customizable scans on container images, ensuring you can identify and manage vulnerabilities.

Documentation Guide For CKS

Domains & Competencies

Topic Weightage (%)
Cluster Setup 10
Cluster Hardening 15
System Hardening 15
Minimize Microservice Vulnerabilities 20
Supply Chain Security 20
Monitoring, Logging and Runtime Security 20

Certified Kubernetes Security Specialist Certification Free Courses

1. Cluster Setup

2. Cluster Hardening

3. System Hardening

4. Minimize Microservice Vulnerabilities

5. Supply Chain Security

6. Monitoring, Logging and Runtime Security

Understanding Kubernetes Authentication and Authorization

CKAD
Overview

Kubernetes authentication and authorization are critical for securing access to the Kubernetes API and ensuring that users and services have the correct permissions to perform actions.

Documentation

Kubernetes Authentication and Authorization.

Authentication Methods
  • Normal Users: Usually authenticate using client certificates. They are typically managed by an external, independent service.
  • ServiceAccounts: Use tokens for authentication, which are automatically managed by Kubernetes.
Authorization with RBAC

Role-Based Access Control (RBAC) is used in Kubernetes to manage authorization. It involves defining roles and binding them to users or ServiceAccounts.

  1. Roles and ClusterRoles

    A Role defines a set of permissions within a specific namespace.

    A ClusterRole defines permissions that are applicable across the entire cluster.

  2. RoleBindings and ClusterRoleBindings

    A RoleBinding grants the permissions defined in a Role to a user or set of users within a specific namespace.

    A ClusterRoleBinding grants the permissions defined in a ClusterRole across the entire cluster.

Steps to Configure RBAC for Kubernetes Auth

  1. Define Roles or ClusterRoles

    Create a Role or ClusterRole to specify permissions.

    Example for a Role
    apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: pod-reader
rules:
  - apiGroups: [""]
    resources: ["pods"]
    verbs: ["get", "watch", "list"]

  2. Bind Roles to Users/ServiceAccounts

    Use a RoleBinding or ClusterRoleBinding to grant these permissions to users or ServiceAccounts.

    Example for a RoleBinding
    apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: read-pods
subjects:
  - kind: User
    name: jane
    apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io

  3. Apply the Configuration

    Use kubectl apply to create these roles and bindings in the Kubernetes cluster.

  4. Verify Permissions

    Verify that the users or ServiceAccounts have the appropriate permissions as defined by the roles and bindings.

Conclusion

Understanding and correctly implementing Kubernetes authentication and authorization are essential for maintaining the security and proper functioning of a Kubernetes cluster. RBAC provides a flexible and powerful way to control access to resources in Kubernetes, allowing administrators to precisely define and manage who can do what within the cluster.

Apply SecurityContexts to Enforce Security Policies in Pods

CKAD
Overview

SecurityContexts in Kubernetes allow you to enforce security policies in Pods. They enable you to control permissions, privilege levels, and other security settings for Pods and their containers.

Documentation

Configure a Security Context for a Pod or Container.

Security Context

Here's an example of a Pod with a defined SecurityContext, as found in the Kubernetes documentation:

apiVersion: v1
kind: Pod
metadata:
  name: security-context-demo
spec:
  securityContext:
    runAsUser: 1000
    fsGroup: 2000
  containers:
  - name: sec-ctx-demo
    image: busybox
    command: ["sh", "-c", "sleep 1h"]
    securityContext:
      runAsUser: 2000
      capabilities:
        add: ["NET_ADMIN", "SYS_TIME"]
      readOnlyRootFilesystem: true
Steps to Apply SecurityContexts

  1. Define the SecurityContext

    Include the SecurityContext in your Pod YAML file, as shown in the example.

  2. Apply the SecurityContext

    Save the YAML file with a name like security-context-demo.yaml. Deploy it to your cluster using kubectl apply -f security-context-demo.yaml.

  3. Verify Security Settings

    Confirm the enforcement of security settings by inspecting the running Pod: Use commands like kubectl exec to examine process permissions and filesystem access.

Conclusion

SecurityContexts are essential for maintaining security in Kubernetes Pods. They provide granular control over security aspects such as user identity, privilege levels, and filesystem access, thus enhancing the overall security posture of Kubernetes applications.

Restricting network access with UFW

Introduction

  • Uncomplicated Firewall (UFW) is a user-friendly interface for managing firewall rules in Linux distributions.
  • It simplifies the process of configuring the iptables firewall, providing an easy-to-use command-line interface.

Installation

  • UFW is typically installed by default on many Linux distributions.

  • If not installed, it can be easily installed using the package manager of your distribution.

    sudo apt-get install ufw   # For Ubuntu/Debian
sudo yum install ufw       # For CentOS/RHEL

Fundamentals

  • Basic Usage: Enable the firewall:

    sudo ufw enable

  • Disable the firewall:

    sudo ufw disable

  • Check the firewall status:

    sudo ufw status

Managing Rules

  • Allow incoming traffic on specific ports (e.g., SSH, HTTP, HTTPS)

    sudo ufw allow 22/tcp
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp

  • Allow incoming traffic from specific IP addresses:

    sudo ufw allow from 192.168.1.100

  • Deny incoming traffic on specific ports:

    sudo ufw deny 25/tcp

  • Delete a rule:

    sudo ufw delete allow 22/tcp

Advanced Configuration

  • UFW supports more advanced configurations such as port ranges and specifying protocols.

    sudo ufw allow 8000:9000/tcp
sudo ufw allow proto udp to any port 53

Logging

  • UFW can log denied connections for troubleshooting purposes.

    sudo ufw logging on

Default Policies

  • By default, UFW denies all incoming connections and allows all outgoing connections.

  • Default policies can be changed if needed.

    sudo ufw default deny incoming
sudo ufw default allow outgoing

Integration with CKS Preparation

  • Understanding UFW is valuable for Certified Kubernetes Security Specialist (CKS) preparation.
  • CKS candidates may need to configure network policies and ingress/egress rules within Kubernetes clusters.
  • Knowledge of UFW can help in securing access to Kubernetes nodes and ensuring only necessary traffic is allowed.

Conclusion

  • Uncomplicated Firewall (UFW) is a powerful tool for managing firewall rules in Linux environments.
  • Its simplicity makes it suitable for both beginners and advanced users.
  • Understanding UFW is beneficial for CKS preparation, particularly for configuring network policies and securing Kubernetes clusters.

Understanding Kubeconfig in Kubernetes

What is Kubeconfig?

Kubeconfig is a configuration file used by kubectl and other Kubernetes tools to access and manage Kubernetes clusters. It contains information about clusters, users, contexts, and other settings needed to authenticate and communicate with Kubernetes clusters.

Location of Config File

By default, the kubeconfig file is located at:

  • Linux/Mac: $HOME/.kube/config
  • Windows: %USERPROFILE%\.kube\config

You can also specify a different location using the KUBECONFIG environment variable or the --kubeconfig flag with kubectl commands.

Clusters, Contexts, Users

A kubeconfig file typically contains several sections:

  • Clusters: Defines the Kubernetes clusters you can connect to. Each cluster entry includes the cluster name, server URL, and certificate authority data.

  • Contexts: Represents a combination of a cluster, a user, and a namespace. Contexts allow you to switch between different cluster-user combinations easily.

  • Users: Specifies the credentials needed to authenticate to a cluster. This can include client certificates, tokens, or other authentication methods.

Example Kubeconfig File

apiVersion: v1
clusters:
- cluster:
    certificate-authority: /path/to/ca.crt
    server: https://your-kubernetes-cluster-server
  name: my-cluster

contexts:
- context:
    cluster: my-cluster
    namespace: default
    user: my-user
  name: my-context

current-context: my-context

kind: Config
preferences: {}
users:
- name: my-user
  user:
    client-certificate: /path/to/client.crt
    client-key: /path/to/client.key

Embedding Certificates in Kubeconfig

Instead of referring to certificate files, you can embed the certificate data directly in the kubeconfig file. This makes the configuration portable and easier to manage.

Example Kubeconfig File with Embedded Certificates

apiVersion: v1
kind: Config
clusters:
- name: my-cluster
  cluster:
    server: https://your-kubernetes-cluster-server
    certificate-authority-data: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSURrVENDQWVrZ0F3SUJBZ0lKQU9XWFpXK0pqOTRmTUEwR0NTcUdTSWIzRFFFQkJRVUFNQTB4Q3pBSkJnTlYKQkFNTUdWUjBMbWgwZEhCekxtWnZiM1F1YzJWeU1TNW5jR0YwWVRBMU1TNHdPVEV6TVRJd1pEQXpNRm9YRFRNMwpNamM1T0RjeU1EWXhPRFl4TUZvWFRUUTVNamN4TkRreU1EWTBNelF3TkRFVk1CTUdBMVVFQXhNR2J6RXhN

contexts:
- name: my-context
  context:
    cluster: my-cluster
    user: my-user
    namespace: default

current-context: my-context

users:
- name: my-user
  user:
    client-certificate-data: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSURrVENDQWVrZ0F3SUJBZ0lKQU9XWFpXK0pqOTRmTUEwR0NTcUdTSWIzRFFFQkJRVUFNQTB4Q3pBSkJnTlYKQkFNTUdWUjBMbWgwZEhCekxtWnZiM1F1YzJWeU1TNW5jR0YwWVRBMU1TNHdPVEV6TVRJd1pEQXpNRm9YRFRNMwpNamM1T0RjeU1EWXhPRFl4TUZvWFRUUTVNamN4TkRreU1EWTBNelF3TkRFVk1CTUdBMVVFQXhNR2J6RXhN
    client-key-data: LS0tLS1CRUdJTiBSU0EgUFJJVkFURSBLRVktLS0tLQo...

How to Embed Certificates

  1. Convert Certificate Files to Base64: Use the base64 command to encode your certificate and key files.
base64 -w 0 /path/to/ca.crt > ca.crt.base64
base64 -w 0 /path/to/client.crt > client.crt.base64
base64 -w 0 /path/to/client.key > client.key.base64

  1. Embed the Encoded Data in the Kubeconfig: Replace the file paths in your kubeconfig with the Base64-encoded data.

  2. For the certificate-authority-data key:

    certificate-authority-data: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0t...

  3. For the client-certificate-data key:

    client-certificate-data: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0t...

  4. For the client-key-data key:

    client-key-data: LS0tLS1CRUdJTiBSU0EgUFJJVkFURSBLRVktLS0tLQo...

Example Commands

base64 -w 0 /path/to/ca.crt > ca.crt.base64
base64 -w 0 /path/to/client.crt > client.crt.base64
base64 -w 0 /path/to/client.key > client.key.base64

These commands will generate files containing the Base64-encoded data, which you can then copy and paste into your kubeconfig file under the appropriate keys.

By embedding the certificate data directly in the kubeconfig file, you make the configuration self-contained, which can be particularly useful for automation and sharing configurations across different environments

Current Context

The current context determines which cluster, user, and namespace are active when you run kubectl commands. It is specified in the current-context field of the kubeconfig file.

Viewing the Current Context

To view the current context:

kubectl config current-context

Setting the Current Context

To set the current context:

kubectl config use-context my-context

KubeConfig Management Commands

Here are some useful kubectl commands for working with kubeconfig:

  • View Current Context:
kubectl config current-context
  • Set Current Context:
kubectl config use-context <context-name>
  • View All Contexts:
kubectl config get-contexts
  • Switch to a Different Context:
kubectl config use-context <context-name>
  • View Cluster Information:
kubectl config view
  • Add a New Cluster:
kubectl config set-cluster <cluster-name> --server=<server-url> --certificate-authority=<path-to-ca.crt>
  • Add a New User:
kubectl config set-credentials <user-name> --client-certificate=<path-to-client.crt> --client-key=<path-to-client.key>
  • Add a New Context:
kubectl config set-context <context-name> --cluster=<cluster-name> --namespace=<namespace> --user=<user-name>

By understanding and managing the kubeconfig file, you can efficiently switch between different Kubernetes clusters and user configurations, making cluster management more streamlined and effective.

Securing Kubelet - A Guide for CKS

Introduction

The Certified Kubernetes Security Specialist (CKS) exam requires a deep understanding of securing the Kubelet, the primary "node agent" in Kubernetes. This guide covers key aspects of securing the Kubelet, including configuration, authentication, and best practices.

Kubelet Configuration File

The Kubelet's behavior is configured via a configuration file, typically found at:

  • Linux: /var/lib/kubelet/config.yaml
  • Windows: C:\var\lib\kubelet\config.yaml

Viewing the Configuration

To view the contents of the Kubelet configuration file, use:

cat /var/lib/kubelet/config.yaml

Viewing Kubelet Options

To see all available configuration options for the Kubelet, use:

kubelet --help

This command displays all command-line flags and options that can be used to configure the Kubelet.

Kubelet Serving Ports and Their Functions

The Kubelet uses several ports for different functions:

  • 10250: Main Kubelet API port for communication with the Kubernetes API server.
  • 10255: Read-only port for health checks and metrics (deprecated and should be disabled).

Example Kubelet Configuration

apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration
authentication:
  anonymous:
    enabled: false
  webhook:
    enabled: true
  x509:
    clientCAFile: /etc/kubernetes/pki/ca.crt
authorization:
  mode: Webhook
port: 10250
readOnlyPort: 0

Enable/Disable Anonymous Authentication in Kubelet

Anonymous authentication allows unauthenticated requests to access the Kubelet's API. For security, it is recommended to disable this feature.

Disabling Anonymous Authentication

To disable anonymous authentication, ensure the following configuration is set:

authentication:
  anonymous:
    enabled: false

Enabling Anonymous Authentication

If necessary, you can enable anonymous authentication by setting:

authentication:
  anonymous:
    enabled: true

After modifying the configuration file, restart the Kubelet to apply the changes:

sudo systemctl restart kubelet

Kubelet Authentication: Certificates and API Bearer Tokens

Kubelet supports multiple authentication methods to secure communication with the Kubernetes API server and other components.

Certificate-Based Authentication

Configure the Kubelet to use client certificates for authentication:

authentication:
  x509:
    clientCAFile: /etc/kubernetes/pki/ca.crt

API Bearer Token Authentication

Configure the Kubelet to use API bearer tokens for authentication:

authentication:
  webhook:
    enabled: true
  token:
    enabled: true

Example Configuration with Authentication

apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration
authentication:
  anonymous:
    enabled: false
  webhook:
    enabled: true
  x509:
    clientCAFile: /etc/kubernetes/pki/ca.crt
authorization:
  mode: Webhook
serverTLSBootstrap: true
port: 10250
readOnlyPort: 0

Best Practices for Securing Kubelet

  1. Disable Read-Only Port: Ensure the read-only port (10255) is disabled.
  2. Enable Webhook Authorization: Use webhook authorization to enforce fine-grained access control.
  3. Use TLS: Always use TLS for secure communication.
  4. Rotate Certificates Regularly: Implement a process to rotate Kubelet certificates regularly.
  5. Restrict Node Access: Limit access to nodes and the Kubelet API to trusted sources only.

By following these practices, you can enhance the security of the Kubelet and maintain a secure Kubernetes environment, essential for passing the CKS exam and ensuring robust cluster security.

Guide to CIS Kubernetes Benchmarking with Kube-bench

What is CIS?

The Center for Internet Security (CIS) is a non-profit organization that develops globally recognized best practices for securing IT systems and data. CIS provides benchmarks, controls, and guidelines to help organizations improve their cybersecurity posture.

CIS Benchmark for Kubernetes

The CIS Kubernetes Benchmark provides a comprehensive set of guidelines for securing Kubernetes clusters. These benchmarks cover various aspects such as configuration, management, and monitoring, aiming to enhance the overall security of Kubernetes deployments.

You can download the CIS Kubernetes Benchmark from the official CIS website: CIS Kubernetes Benchmark Download.

Introduction to Kube-bench Tool

Kube-bench is an open-source tool developed by Aqua Security that automates the process of checking Kubernetes clusters against the CIS Kubernetes Benchmark. It provides a detailed report highlighting which controls are compliant and which need remediation.

Deploy Kube-bench Options

There are multiple ways to deploy Kube-bench in your Kubernetes environment:

  • Running as a Job: Execute Kube-bench as a Kubernetes job, which runs the checks and exits.
  • Running as a DaemonSet: Deploy Kube-bench as a DaemonSet to run on every node in the cluster.
  • Running locally: Run Kube-bench directly on the command line for individual nodes.
  • Kube-bench Installation
  • Killer Coda Labs

Run Kube-bench

kube-bench run --benchmark <benchmark-version> --targets master,node

Fix One Sample Issue

Let's fix an issue identified by Kube-bench:

Ensure that the --anonymous-auth argument is set to false (CIS 1.2.5).

Steps to Fix

1. Identify the Configuration File

Locate the kube-apiserver configuration file, usually found in /etc/kubernetes/manifests/kube-apiserver.yaml.

2. Edit the Configuration

Open the kube-apiserver.yaml file and add or modify the --anonymous-auth flag to be false.

- --anonymous-auth=false
3. Apply the Changes

Save the file and the kubelet will automatically restart the kube-apiserver with the new settings.

4. Verify the Fix

Run Kube-bench again to ensure that the issue is resolved.

kube-bench run --check 1.2.5

Conclusion

Using the CIS Kubernetes Benchmark and Kube-bench tool is a robust approach to enhance the security of your Kubernetes clusters. Regularly running these checks and addressing identified issues helps maintain a secure and compliant environment.

Certificate API

Info

Certificates and Certificate Signing Requests

Overview of what a Certificate Signing Request (CSR).

  1. Request for Certificate: A CSR is a request sent to a Certificate Authority (CA) asking for a digital certificate.

  2. Contains Public Key: It includes the applicant's public key along with identity information (e.g., common name, organization details).

  3. Signed by Private Key: The CSR is signed by the applicant's private key to prove ownership and authenticity of the public key.

  4. Establishes Trust: By submitting a CSR, the applicant seeks validation of their identity by the CA to establish trust.

  5. Enables Secure Communications: Once approved, the CA issues a digital certificate that binds the applicant's identity to their public key, enabling secure encrypted communications (e.g., HTTPS, SSL/TLS connections).

1. Create a CSR
  • First, generate a private key and CSR using OpenSSL:
openssl genrsa -out my-key.key 2048
openssl req -new -key my-key.key -out my-csr.csr -subj "/CN=my-user"
  • Encode CSR in Base64 Encode the CSR in base64 (to be included in the YAML):
cat my-csr.csr | base64 | tr -d '\n'
  • Next, create a Kubernetes CSR manifest (my-csr.yaml):
apiVersion: certificates.k8s.io/v1
kind: CertificateSigningRequest
metadata:
  name: my-csr
spec:
  request: <encoded-base64-goes-here>
  signerName: kubernetes.io/kube-apiserver-client
  usages:
  - client auth
  • Apply the CSR manifest:
kubectl apply -f my-csr.yaml
2. Approve or Deny the CSR
  • To approve the CSR:
kubectl certificate approve my-csr
  • To deny the CSR:
kubectl certificate deny my-csr
3. List CSRs
  • List all CertificateSigningRequests:
kubectl get csr
4. View YAML and Describe CSR
  • View the CSR in YAML format:
kubectl get csr my-csr -o yaml
  • Describe the CSR:
kubectl describe csr my-csr
5. Delete the CSR
kubectl delete csr my-csr

Locating Certificates on the Master Node

Once a CSR is approved, the certificate will typically be signed by the Kubernetes Certificate Authority and returned. To locate certificates:

  • Certificates are generally stored in etcd and are not directly accessible from the file system. However, if you are managing custom certificates, they may be stored in specific directories like /etc/kubernetes/pki.

  • For cluster components (e.g., kube-apiserver, kubelet), certificates are usually stored in /etc/kubernetes/pki on the master node.

  • Example locations:

  • CA certificates: /etc/kubernetes/pki/ca.crt
  • API server certificates: /etc/kubernetes/pki/apiserver.crt
  • Kubelet certificates: /var/lib/kubelet/pki/kubelet-client-current.pem
Accessing the Master Node
  • SSH into the master node:
ssh user@master-node-ip
  • Navigate to the directory containing certificates:
cd /etc/kubernetes/pki
  • List the files to see the certificates:
ls -l

Additional Tips

  • Ensure you have appropriate permissions to manage CSRs and access the file system on the master node.
  • Regularly back up your certificate files and maintain secure practices around certificate management.
  • Refer to the Kubernetes documentation for detailed information on the CSR API and certificate management best practices.

By following these steps, you should be able to create, manage, and locate certificates effectively in a Kubernetes cluster, which is essential for your CKS certification preparation.