Blog Exisf

Setting Up Kubernetes RBAC

Exisf — Thu, 26 Sep 2024 23:00:00 GMT

In Kubernetes, fine-grained access control is essential for securing cluster resources and defining who can do what. Role-Based Access Control (RBAC) is the built-in mechanism that lets you assign permissions to users, groups, and service accounts. In this guide, we’ll walk through the process of setting up RBAC for a service account by creating a ClusterRole, binding it with a ClusterRoleBinding, and extracting the token and certificate from a secret for API access. Whether you're automating tasks, integrating external tools, or simply exploring Kubernetes internals, understanding how to securely authorize service accounts is a vital skill.

Step-by-Step: Setting Up Kubernetes RBAC for a Service Account

Create a Namespace (Optional but Recommended)

Organizing resources into a namespace helps isolate access vi my-namespace.yaml
```
 apiVersion: v1
 kind: Namespace
 metadata:
   name: my-namespace
```
Apply with: kubectl apply -f my-namespace.yaml

Create a Service Account vi my-sa.yaml

 apiVersion: v1
 kind: ServiceAccount
 metadata:
   name: my-service-account
   namespace: my-namespace

Apply with: kubectl apply -f my-sa.yaml

Define a ClusterRole

This grants permissions across the entire cluster. Here’s an example with read access to all pods: vi my-cr.yaml

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

Apply with: kubectl apply -f my-cr.yaml

Bind the ClusterRole to the Service Account vi my-crb.yaml

 apiVersion: rbac.authorization.k8s.io/v1
 kind: ClusterRoleBinding
 metadata:
   name: read-pods-global
 subjects:
 - kind: ServiceAccount
   name: my-service-account
   namespace: my-namespace
 roleRef:
   kind: ClusterRole
   name: pod-reader
   apiGroup: rbac.authorization.k8s.io

Apply with: kubectl apply -f my-cr.yaml

Test if the service account can perform required action

kubectl auth can-i   --as=system:serviceaccount::

Replace the placeholders as follows:

– the action to test, e.g., list, get, create, delete
– the Kubernetes resource, e.g., pods, secrets, configmaps
– the namespace where the service account resides
– the name of the service account you're testing

Up Next: Extracting Tokens and CA Certs from Kubernetes Service Accounts

In the next post, I’ll cover how to extract service account tokens and certificates depending on your Kubernetes version:

For Kubernetes < 1.24: Using auto-generated secrets.
For Kubernetes 1.24+: Using kubectl create token or manually creating a Secret of type kubernetes.io/service-account-token.

You’ll also learn how to use these credentials to configure a custom kubeconfig file for accessing the cluster via kubectl or automation tools.

Mastering kubectl: The Guide to Kubernetes CLI Commands

Exisf — Wed, 12 Jun 2024 23:00:00 GMT

Whether you’re just stepping into Kubernetes or you're managing large-scale production clusters, kubectl is your essential Swiss Army knife. It’s the command-line tool used to interact with your Kubernetes cluster, allowing you to deploy apps, inspect resources, troubleshoot issues, and automate workflows.

In this comprehensive guide, we’ll walk through kubectl command, grouped by purpose, with clear explanations of what each one does.

1. Cluster Configuration and Context Management

These commands help you connect to, configure, and switch between Kubernetes clusters.

kubectl version
Shows the version of kubectl and the connected Kubernetes API server.
kubectl config view
Displays the kubeconfig file details (clusters, contexts, users).
kubectl config use-context
Switches the current context to a different cluster.
kubectl config get-contexts
Lists all available contexts in your kubeconfig.
kubectl config current-context
Prints the name of the current context.
kubectl cluster-info
Displays addresses of the Kubernetes control plane and services.
kubectl config set-context
Sets a named context in your kubeconfig.

2. Listing and Describing Resources

Used for inspecting the current state of your cluster’s resources.

kubectl get
Lists one or more resources (e.g., pods, services, deployments).
kubectl get -o wide
Adds more detail to the output (IP, node name, etc.).
kubectl get -A
Shows resources across all namespaces.
kubectl get all
Lists all standard resources (pods, services, deployments, etc.) in the current namespace.
kubectl describe
Shows detailed information about a resource, including events and configuration.
kubectl explain
Displays the API documentation for the resource type and fields.
kubectl get events
Lists cluster events in chronological order.
kubectl get componentstatuses (deprecated)
Shows the health of cluster components (controller manager, scheduler, etc.).

3. Creating, Applying, and Deleting Resources

For managing resource lifecycles from YAML or JSON files.

kubectl create -f .yaml
Creates resources defined in a manifest file.
kubectl apply -f .yaml
Creates or updates resources declaratively.
kubectl delete -f .yaml
Deletes resources defined in the file.
kubectl replace -f .yaml
Replaces the live resource with a new one from a file.
kubectl create deployment --image=
Imperatively creates a deployment.
kubectl delete
Deletes a specific resource by name.
kubectl delete --all
Deletes all resources of a type in the current namespace.

4. Editing and Patching Resources

For quick changes to live resources.

kubectl edit
Opens the resource definition in your editor for inline editing.
kubectl patch -p ''
Applies a strategic merge patch to a resource.

5. Working with Pods

Manage and troubleshoot pods with these commands.

kubectl get pods
Lists pods in the current namespace.
kubectl logs
Displays logs from a pod's main container.
kubectl logs -c
Shows logs from a specific container in the pod.
kubectl exec --
Runs a command inside the pod (e.g., kubectl exec pod-name -- ls /).
kubectl exec -it -- bash
Opens an interactive terminal session inside the container.
kubectl port-forward 8080:80
Forwards a local port to a port on the pod.
kubectl cp :
Copies files from a pod to the local machine or vice versa.
kubectl delete pod
Deletes a specific pod.
kubectl delete pod --all
Deletes all pods in the current namespace.

6. Deployments and Rollouts

Commands for managing application rollouts.

kubectl rollout status deployment/
Monitors the rollout status of a deployment.
kubectl rollout history deployment/
Shows the history of a deployment.
kubectl rollout undo deployment/
Rolls back to the previous deployment.
kubectl rollout restart deployment/
Triggers a new rollout by restarting the deployment.
kubectl scale deployment --replicas=
Changes the number of pod replicas in a deployment.

7. Services and Exposing Pods

Use these to expose pods and create services.

kubectl expose pod --port=80 --target-port=8080
Exposes a pod as a service.
kubectl expose deployment --port=80 --type=NodePort
Exposes a deployment through a service.

8. Namespaces

Commands for managing namespaces.

kubectl get namespaces
Lists all namespaces.
kubectl create namespace
Creates a new namespace.
kubectl delete namespace
Deletes the specified namespace.
kubectl get pods --namespace
Lists pods in a specific namespace.

9. Labels and Annotations

Used to organize and identify Kubernetes resources.

kubectl label key=value
Adds or updates a label on a resource.
kubectl annotate key=value
Adds or updates an annotation.

10. Resource Usage

Check CPU and memory consumption.

kubectl top pod
Shows CPU and memory usage of pods.
kubectl top node
Shows CPU and memory usage of nodes.

(Requires metrics server to be installed.)

11. Access Control and Security (RBAC)

Useful for debugging permissions and managing roles.

kubectl auth can-i
Checks whether the current user is allowed to perform an action.
kubectl describe role
Describes a Role's permissions.
kubectl describe clusterrole
Describes a ClusterRole's permissions.
kubectl get roles / kubectl get clusterroles
Lists roles and cluster-wide roles.

12. Output Customization and Sorting

Get more detailed or structured output.

kubectl get -o yaml
Outputs the resource definition in YAML format.
kubectl get -o json
Outputs the resource definition in JSON format.
kubectl get --sort-by=.metadata.name
Sorts the resource list by a field.
kubectl get -l key=value
Filters by label selector.

kubectl is powerful because it abstracts Kubernetes operations into a unified CLI. From basic pod management to advanced rollout strategies and RBAC validation, mastering kubectl is essential for efficient Kubernetes operations. As Kubernetes evolves, keep an eye on updates and new flags, but this foundation will always serve you well.

Guide on How to Deploy a Private Container Registry

Exisf — Tue, 12 Sep 2023 23:00:00 GMT

Private registries are used to store and distribute Docker images within your organization, providing control and security over your containerized applications. It is a common task when working with containerization technologies like Docker. In this post, I'll walk you through the steps to set up a private Docker registry.

There are various tools available for creating private registries, and Docker itself provides a registry image called Docker Registry. We will focus on using Docker Registry, depending on your needs, you may also explore Harbor, Artifactory, or Azure Container Registry.

Prerequisites:

A Linux host where you'll host the private registry.
Docker is installed on the host.
Docker Compose installed (optional but recommended for ease of management).

Here are the steps:

Install Docker Registry:

You can use Docker Compose to easily set up the Docker Registry. Create a docker-compose.yml file with the following content

version: '3'
services:
  registry:
    image: registry:2
    ports:
      - 5000:5000
    environment:
      REGISTRY_STORAGE_FILESYSTEM_ROOTDIRECTORY: /var/lib/registry

Configure TLS (Optional but recommended):

It is strongly advised that you configure TLS to secure your private registry. You can use tools like certbot or generate a self-signed certificates. Then, update the TLS configuration to your docker-compose.yml file.

version: '3'
services:
  registry:
    image: registry:2
    ports:
      - 5000:5000
    environment:
      REGISTRY_STORAGE_FILESYSTEM_ROOTDIRECTORY: /var/lib/registry
    volumes:
      - /path/to/certs:/certs
    tls:
      certificate: /certs/your.crt
      key: /certs/your.key

Replace /path/to/certs, your.crt, and your.key with the actual paths and filenames of your TLS certificates.

Secure the Registry:

To secure the registry, you can set up authentication. Docker Registry supports both basic authentication and token-based authentication. Basic authentication involves creating a htpasswd file, and token-based authentication can be set up using Docker Notary.

For basic authentication, create an htpasswd file and mount it into the registry container. Update your docker-compose.yml to include the authentication:

version: '3'
services:
  registry:
    image: registry:2
    ports:
      - 5000:5000
    environment:
      REGISTRY_STORAGE_FILESYSTEM_ROOTDIRECTORY: /var/lib/registry
      REGISTRY_AUTH: htpasswd
      REGISTRY_AUTH_HTPASSWD_PATH: /auth/htpasswd
      REGISTRY_AUTH_HTPASSWD_REALM: Registry Realm
    volumes:
      - /path/to/certs:/certs
      - /path/to/auth:/auth
    tls:
      certificate: /certs/your.crt
      key: /certs/your.key

Replace /path/to/auth with the path to your htpasswd file.

Save this file and run the registry as a Docker container.

docker-compose up -d

Access the Registry:

Once your private registry is up and running, you can login to the registry if authentication was setup, push and pull Docker images to and from it using the following format:

docker login :5000
docker pull :5000/:
docker push :5000/:

is the hostname or IP address of your private registry server.

That's it! You now have a private Docker registry up and running. Make sure to configure the necessary firewall rules and access controls to restrict access to authorized users only. Additionally, consider setting up regular backups and monitoring your registry to ensure its reliability and security.

How to setup private registry in Kubernetes cluster using cri-o as CRI

Exisf — Sat, 02 Sep 2023 23:00:00 GMT

Before we begin, there are a few conditions that must be met. We need to have the following in place.

Private container registry setup.
- Setup guide: https://blog.exisf.com/guide-on-how-to-deploy-a-private-container-registry
The images are pushed to the registry.
Have a functioning Kubernetes environment up and running.
Authentication credentials such as username, password, or tokens are needed to access the private registry.
If the private registry uses HTTPS, you may need to manage SSL/TLS certificates. To create a secure connection, Kubernetes must trust the registry's certificate.

With the above in place, we are ready to proceed with this exercise. Let's walk through the process.

In this example, we use a self-hosted docker registry with the URL 'myregistry.com' listening on port '5000'. Log in to the image registry via the command line. If you do not have the docker tool installed, check below for an optional method to create the secret.

docker login myregistry.com:5000

Provide the credential you want to use to authenticate to the registry when prompted, this could be an access token or the password for the docker ID.

The login process creates or updates a config.json file that holds an authorization token usually in the home directory.

cat $HOME/.docker/config.json

To use the token within Kubernetes, we create a secret based on the credentials above. Kubernetes cluster authenticates with the registry to retrieve images using the secret of kubernetes.io/dockerconfigjson type.

kubectl create secret generic regcredname  --from-file=.dockerconfigjson= --type=kubernetes.io/dockerconfigjson

Optional method to create the secret

If you don't have docker installed, do this instead. Use kubectl to create the secret and store the registry login credentials providing them via the command line. But if you prefer the docker login method then skip this step.

kubectl create secret docker-registry regcredname --docker-server  --docker-username= --docker-password= --docker-email=

Note that secrets typed on the command line may be stored unprotected in your shell history, and those secrets may be available to other users on that host while Kubectl is running.

Use the secret in a Kubernetes manifest file

The following is a manifest for a pod that requires access to the credentials we created in regcredname, to pull the image specified from the private registry.

vi my-private-reg-pod.yaml

apiVersion: v1
kind: Pod
metadata:
  name: my-app-priv-reg
spec:
  containers:
  - name: my-private-reg-image
    image: myregistry.com:5000/my-reg-image:tag
  imagePullSecrets:
  - name: regcredname

Replace myregistry.com:5000/my-reg-image:tag with the actual image.

Update the location of the registry to the Kubernetes registries config file

In the Kubernetes cluster, edit the container registry configuration file and specify the registry URL and SSL/TLS option.

The default location is /etc/containers/registries.conf, If you wish to modify it for a single user, you may create a new file at $HOME/.config/containers/registries.conf

Update the [[registry]] section with the URL or IP of the container registry. To skip TLS verification, that is, using HTTP rather than HTTPS to connect to the registry, add insecure=true.

[[registry]]
location="myregistry.com:5000"
insecure=true

If there are numerous registries, the [[registry]] double brackets indicate that we can specify a list or a table of [registry] objects. In this example, there is only one registry myregistry.com:5000.

After updating the file, restart the CRI-O service to apply the changes

systemctl restart crio.service

Finally, deploy the pod to the Kubernetes cluster using kubectl and verify it is running.

kubectl apply -f my-private-reg-pod.yaml
kubectl get pod my-app-priv-reg

Now, your Kubernetes pods should be able to pull images from your private container registry with the appropriate authentication credentials. Make sure to replace placeholders with your actual registry and credentials information.

Networks: Exploring Docker's Building Blocks - Docker objects

Exisf — Sun, 20 Aug 2023 23:00:00 GMT

Docker networks are an essential component of Docker's networking capabilities, allowing you to establish and control communication between Docker containers as well as communication between containers and the host system. Docker networks provide isolation, security, and flexibility for containerized applications.

First, we will introduce the fundamental concepts and benefits of Docker networks starting with the default network. Then, in the second section, we delve into hands-on examples and specific commands for working with Docker networks.

Section 1a:

Understanding the Default Bridge Network

When you run a Docker container without specifying a custom network, it is automatically assigned to the "bridge" network. Containers on the same bridge network can communicate with one another directly, but they are isolated from other bridge networks unless port forwarding is configured.

Key Features and Characteristics

By default, containers linked to the default bridge network are separated from external networks. This separation offers another degree of security by preventing container services from being directly exposed to the host's network interfaces.
Containers connected to the same default bridge network can interact using the internal IP addresses assigned by Docker. This communication is possible through the use of basic networking protocols like HTTP, HTTPS, and others.
Docker assigns unique container names, making it easy for containers to reference each other. This simplifies communication by allowing containers to use these names as hostnames.
The default bridge network also supports port mapping, which allows containers to expose certain ports to the host system or even external networks. This is required if you wish to access containerized services from outside the container.

Use Cases for the Default Bridge Network

The default bridge network is suitable for various scenarios which include:

Microservices Communication: Different components of an application can connect over the default bridge network in microservices designs, enabling efficient communication while retaining isolation.
Development and Testing: Containers on the default bridge network can communicate fluidly during development and testing, simulating a production-like environment without exposing services to the larger network.

Limitations and Considerations

Despite being convenient, the basic bridge network has some drawbacks:

Container Isolation: Containers on the default bridge network have a common network namespace, which could restrict security in some circumstances.
No Host Access: Containers on the default bridge network cannot directly access services on the host system.

Conclusion

The default bridge network in Docker serves as the foundation for container communication on a single host. It provides isolation, container-to-container interaction, and port mapping, making it an integral part of Docker's networking architecture. Understanding the default bridge network is essential for anyone working with Docker containers and building containerized applications.

In our next section 1b, we will explore the custom network types, and highlight the benefits of creating custom bridge networks, features, use cases and limitations. Stay tuned to take your Docker networking skills to the next level!

Container: Exploring Docker's Building Blocks - Docker objects

Exisf — Fri, 18 Aug 2023 16:48:02 GMT

In our last post, we discussed Docker images and how they serve as the essential building blocks of containerization, and how Docker images encapsulate an application along with its dependencies, providing consistency across various environments. As a continuation of our Docker journey, this write-up will focus on another important part of the Docker object: Docker containers.

Containers: Dynamic and Agile Application Environments

Think of containers as isolated, lightweight runtime environments for applications. They encapsulate the application, its runtime, system tools, libraries, and settings, providing an efficient and consistent way to deploy applications across various environments.

Containers are engineered for agility and portability. Since they bundle everything needed to run an application, from its dependencies to configuration files, developers can be confident that their code will run consistently across development, testing, and production environments. Containers are isolated from the host system and other containers, ensuring that changes made in one container do not affect others or the underlying host system.

Key Advantages of Containers:

Resource Efficiency: Containers share the kernel of the host operating system, reducing overhead and allowing the deployment of multiple programs on the same hardware.
Consistency: Containers ensure consistent behaviour across diverse environments, eliminating the "it works on my machine" issue.
Rapid Deployment: Containers can be spun up and torn down quickly, making it easy to scale applications based on demand.
Isolation: Containers provide isolation between applications, enhancing security and preventing conflicts.
Version Control: Docker images and containers can be versioned, allowing easy rollback and updates.

Commonly used commands and their use case include.

docker run:
- Create and start a new container based on an image.
  
  docker run -it ubuntu:latest bash
docker start:
- Start a stopped container.
  
  docker start container_name
docker stop:
- Gracefully stop a running container.
  
  docker stop container_name
docker restart:
- Stop and then start a container.
  
  docker restart container_name
docker pause:
- Pause all processes in a running container.
  
  docker pause container_name
docker unpause:
- Unpause a paused container.
  
  docker unpause container_name
docker kill:
- Forcefully stop a running container.
  
  docker kill container_name
docker exec:
- Run a command inside a running container.
  
  docker exec -it container_name bash
docker attach:
- Attach to a running container's console.
  
  docker attach container_name
docker logs:
- Display logs from a container.
  
  docker logs container_name
docker ps:
- List all running containers.
  
  docker ps
docker ps -a:
- List all containers (both running and stopped).
  
  docker ps -a
docker rm:
- Remove a stopped container.
  
  docker rm container_name
docker commit:
- Create a new image from a container's changes.
  
  docker commit container_name new_image_name
docker inspect:
- Display detailed information about a container.
  
  docker inspect container_name
docker stats:
- Display real-time resource usage statistics for containers.
  
  docker stats container_name
docker top:
- Display the running processes in a container.
  
  docker top container_name
docker rename:
- Rename an existing container.
  
  docker rename old_container_name new_container_name
docker cp:
- Copy files or folders between a container and the local filesystem.
  
  docker cp container_name:/path/to/file local_path

These are just a subset of Docker container commands. Depending on your specific use case, you might find other commands relevant as well. Remember to use docker --help or consult the official Docker documentation for detailed information on each command's options and usage.

While Docker images serve as the blueprint, containers are the dynamic actors that execute the scripts. These components, when combined, constitute the foundation of Docker's containerization method, which is transforming software deployment and development practices. In future articles, we'll go further into another Docker object: Docker networks, Capabilities and how they enable seamless communication and collaboration among containers.

Image: Exploring Docker's Building Blocks - Docker objects

Exisf — Fri, 11 Aug 2023 17:19:41 GMT

Docker object: We can create, distribute, and run applications in containers with docker. The requirements and configurations required to operate these applications are built within a docker image and run in containers, which are paths of the docker objects. Docker objects are the various components and entities used within the docker environment. Such as creating and utilising images, containers, networks, volumes, plugins, and other items. Some of the benefits of docker include;

Consistency
Portability
Resource Efficiency
Versioning and Rollbacks
Rapid Deployment

In this opening post, we will explore some of the most often-used commands related to docker images. How these commands enable us to efficiently manage, manipulate, and interact with docker images, forming the bedrock of containerization technology.

Docker image

Provides the blueprint for running containers, and instances of images that are executed in isolated environments.
A standalone package that encapsulates a piece of software, including code, runtime, system tools, libraries, and settings. Once created, it remains unchangeable. Modifications result in new image layers.
Composed of multiple read-only layers that build upon each other build instructions.
Can be created based on another image with custom instructions and configuration parameters required.
Can be moved and deployed across various environments consistently, tagged with versions, making it easy to track and manage changes.

Commonly used commands and their use case includes.

Docker build:
1. Build a docker image from a dockerfile named "my_image" with tag "latest" in the current working directory
  - docker image build -t my_image:latest .
Docker pull:
1. Download (pull) the latest version of the nginx image from the docker public Hub
  - docker pull nginx:latest
2. Download (pull) the latest version of the nginx image from a hosted registry
  - docker login registry.mydomain.com
  - docker pull nginx:latest
Docker push:
1. Upload or pushes the "my_image" image to a docker registry
  - docker push my_image:latest
Docker image:
1. List pulled docker image in the local system with either command
  - docker images
  - docker image ls
Docker image remove:
1. Remove docker image
  - docker image rm my_image:latest
Docker image prune
1. Remove dangling image. A dangling image means images that are not tagged and are not referenced by any container
  - docker image prune
2. Remove all images which are not used by existing containers
  - docker image prune -a
Docker image inspect:
1. Display detailed information on one or more images, e.g my_image:latest
  - docker image inspect my_image:latest
Docker image history:
1. Show the history of the "my_image:latest" image layers
  - docker image history my_image:latest
Docker image tag:
1. Create a new version tag from an existing image
  - docker image tag my_image:latest my_image:v2
Docker image save:
1. Save the image to a tarball archive
  - docker image save -o my_image.tar my_image:latest
2. This method can also be used to copy images from one host to another
  1. After saving the image, copy it with cp, scp, rsync or any preferred option to the remote host.
  2. From the remote host
    - docker load -i path_to_transferred_tar_file

Docker images are at the core of Docker's containerization technology, serving as the building blocks that enable the isolation and efficient deployment of applications.

In the next path, we'll expand our focus on the creation, lifecycle management, and interaction of another fundamental Docker object: the container. Containers provide a flexible and dynamic environment that encapsulates applications, their dependencies, and runtime configurations.