Like any open source project, Istio's documentation relies heavily on the contributions from the community. If you are passionate about documentation and would like to make a contribution, the first step is to set up the documentation site locally. In this article, we will learn the basic steps to achieve this.

Prerequisites

• Git

• Docker Desktop

Local Setup

Fork the repository

Create a fork of the istio/istio.io repository

Clone the fork

git clone https://github.com/adityasamant25/istio.io

Create a branch

// Navigate to the project directory
cd istio.io
git checkout -b issue-10

Deploy the website locally

Istio provides a Docker image with all the tools needed, including Hugo which is the site generator. To build and publish the website locally within the docker container, execute the command below:

make serve

git config --global --add safe.directory /work

Once the website builds successfully, you should see the following message:

Built in 18037 ms
Environment: "development"
Serving pages from disk
Web Server is available at http://localhost:1313/latest/ (bind address 0.0.0.0)

Access the URL http://localhost:1313/latest/ from within a browser. The Istio documentation is now available to you locally.

Contribute changes

The documentation for the English language is available at the following path:

/content/en/docs

Navigate to the .md file you need to edit. Make the appropriate changes and save the file. Saving the changes automatically triggers a redeployment of the site. The browser refreshes automatically and this enables you to immediately validate your changes locally.

Once you are satisfied with your changes, perform the following steps:

• Commit the changes to your local branch

    git add <file paths>
    git commit -m "Fixed issue 10"
  

• Push the changes to a branch on your fork

    git push origin issue-10
  

• Raise a pull request from your branch to the istio.io master branch

After you raise a pull request, wait for a maintainer to review the changes. In case of any review comments, incorporate the changes and push a new commit.

Conclusion

Hope this article helps in getting you started on your journey to contribute to Istio documentation. In case of any issues, please post a reply and I will try to assist.

Well, what are we waiting for? Let's go ahead and revamp our Zsh terminal.

Oh My Zsh

Oh My Zsh (pronounced oh my zee shell) is an open source, community-driven framework for managing your zsh configuration.

Oh My Zsh will not make you a 10x developer...but you may feel like one.

Install Oh My Zsh

sh -c "$(curl -fsSL https://raw.githubusercontent.com/ohmyzsh/ohmyzsh/master/tools/install.sh)"

As soon as the installation is complete, you will see a hint of colour on your terminal.

Oh My Zsh creates a new .zshrc file. Copy the custom alias, paths and secrets from your backup .zshrc file and paste it at the end of the new file.

Save the file and source it.

source ~/.zshrc

Powerlevel10k

Powerlevel10k is a theme for Zsh. It emphasizes speed, flexibility and out-of-the-box experience. It boosts the terminal with a nice new font and enables a fully customizable look and feel.

Install the Meslo Nerd Font by following the instructions mentioned here.

After installing the Font, Open Terminal → Settings → Profiles → Text, click Change under Font and select MesloLGS NF family. If you're unable to spot the Font, ensure you select "All Fonts" under the "Collection" option. Refer to the picture below.

Install Powerlevel10k using the command below:

git clone --depth=1 https://github.com/romkatv/powerlevel10k.git ${ZSH_CUSTOM:-$HOME/.oh-my-zsh/custom}/themes/powerlevel10k

Next step is to use the Powerlevel10k these for Oh My Zsh. To do that, open the ~/.zshrc file and edit the value of the existing field ZSH_THEME from robbyrussell to powerlevel10k/powerlevel10k as follows:

ZSH_THEME="powerlevel10k/powerlevel10k"

After installation, restart Zsh using the following command:

exec zsh

This will open the Powerlevel10k configuration wizard.

Here are the options that worked best for me:

Try a command such as

cd ~/Documents

You will see the an immediate change:

zsh-autosuggestions

zsh-autosuggestions suggests commands as you type based on history and completions.

Install the zsh-autosuggestions plugin using the following command:

git clone https://github.com/zsh-users/zsh-autosuggestions ${ZSH_CUSTOM:-~/.oh-my-zsh/custom}/plugins/zsh-autosuggestions

Add the plugin to the list of existing plugins for Oh My Zsh to load (inside ~/.zshrc)

plugins=(git zsh-autosuggestions)

Source the .zshrc using the following command:

source ~/.zshrc

Try to type some commands you have used before and you will see that the terminal suggests an auto-completion. To choose the suggested option, simply click the right arrow key.

zsh-syntax-highlighting

zsh-syntax-highlighting provides syntax highlighting for Zsh. It enables highlighting of commands whilst they are typed at a Zsh prompt into an interactive terminal. This helps in reviewing commands before running them, particularly in catching syntax errors.

Install the zsh-syntax-highlighting plugin using the following command:

git clone https://github.com/zsh-users/zsh-syntax-highlighting.git ${ZSH_CUSTOM:-~/.oh-my-zsh/custom}/plugins/zsh-syntax-highlighting

Add the plugin to the list of existing plugins for Oh My Zsh to load (inside ~/.zshrc)

plugins=(git zsh-autosuggestions zsh-syntax-highlighting)

Source the .zshrc using the following command:

source ~/.zshrc

Try to type some commands. You will find that the terminal highlights valid commands in green and invalid commands in red.

Kubernetes Joy

For Kubernetes users, as soon as you type kubectl , the active context from the kubeconfig file is shown at the right of the terminal.

If the current namespace is anything other than default, it shows the custom namespace as well. In the below example, the context name is istio and the namespace is temp.

Wow, now that's an awesome upgrade!

Happy coding!

In Kubernetes 1.21, a feature for Immutability of ConfigMaps and Secrets was GA. What exactly is this concept and its purpose? This article has the answers.

Concept

Kubernetes 1.21 was released back in 2021, and it provided an option to mark ConfigMaps and Secrets as immutable. This meant that once created, the data in these objects could not be altered.

Purpose

Some would question the need for this feature. Since ConfigMaps and Secrets deal with configuration, and configuration is subject to change, why would we need such a feature?

Performance

It is important to understand that the kubelet on each node watches over each ConfigMap and Secret and periodically syncs its information to the Pods via the kube-apiserver. Large scale production deployments can have tens of thousands of such ConfigMaps and Secrets and obviously there is a cost associated with continuously keeping a watch for changes.

ConfigMaps and Secrets containing data that is constant over time can be marked as immutable. The kubelet does not watch over these resources. This in turn reduces the load on the kube-apiserver, saves compute resources and effectively improves the performance of the cluster.

Security and Reliability

As the data for immutable ConfigMaps and Secrets cannot be altered, it can protect the sensitive and critical configuration from accidental (or unwanted) updates that could cause application outages.

It provides an additional layer of security against malicious actors attempting to manipulate data.

Consistency

Immutability is ideal for scenarios where you want to ensure a consistent configuration across multiple Pods and Deployments.

Definition

Immutable ConfigMaps and Secrets are defined by setting the immutable field to true.

apiVersion: v1
kind: ConfigMap
metadata:
  ...
data:
  ...
immutable: true

apiVersion: v1
kind: Secret
metadata: 
  ...
data: 
  ...
immutable: true

Example

Let's check an example of an Immutable ConfigMap that is mounted as a Volume in a Pod. We will also demonstrate how to update configuration driven by an Immutable ConfigMap.

Prerequisites

1. A local Kubernetes cluster such as minikube, kind, K3s or MicroK8s.

2. The kubectl command line tool to interact with the Kubernetes cluster.

An example manifest for an Immutable ConfigMap is shown below:

apiVersion: v1
data:
  season: "summer"
kind: ConfigMap
immutable: true
metadata:
  name: season

Create the Immutable ConfigMap:

kubectl apply -f https://raw.githubusercontent.com/adityasamant25/courses/main/kubernetes/configmaps/examples/immutable-configmaps.yaml

Below is an example of a Deployment manifest with the Immutable ConfigMap season mounted as a volume into the Pod's only container:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: immutable-configmap-volume
  labels:
    app.kubernetes.io/name: immutable-configmap-volume
spec:
  replicas: 3
  selector:
    matchLabels:
      app.kubernetes.io/name: immutable-configmap-volume
  template:
    metadata:
      labels:
        app.kubernetes.io/name: immutable-configmap-volume
    spec:
      containers:
        - name: alpine
          image: alpine:3
          command:
            - /bin/sh
            - -c
            - while true; do echo "$(date) My preferred season is $(cat /etc/config/season)";
              sleep 10; done;
          ports:
            - containerPort: 80
          volumeMounts:
            - name: config-volume
              mountPath: /etc/config
      volumes:
        - name: config-volume
          configMap:
            name: season

Create the Deployment:

kubectl apply -f https://raw.githubusercontent.com/adityasamant25/courses/main/kubernetes/configmaps/examples/deployment-with-immutable-configmap-as-volume.yaml

Check the Deployment:

kubectl get deployment immutable-configmap-volume

You should see an output similar to:

NAME               READY   UP-TO-DATE   AVAILABLE   AGE
configmap-volume   3/3     3            3           19s

Check the pods for this Deployment (matching by selector):

kubectl get pods --selector=app.kubernetes.io/name=immutable-configmap-volume

You should see an output similar to:

NAME                                          READY   STATUS    RESTARTS   AGE
immutable-configmap-volume-5c677f6494-n7cg5   1/1     Running   0          30s
immutable-configmap-volume-5c677f6494-sdhkp   1/1     Running   0          30s
immutable-configmap-volume-5c677f6494-vsszf   1/1     Running   0          30s

The Pod's container refers to the data defined in the ConfigMap and uses it to print a report to stdout. You can check this report by viewing the logs for one of the Pods in that Deployment:

# Pick one Pod that belongs to the Deployment, and view its logs
kubectl logs deployments/immutable-configmap-volume

You should see an output similar to:

Found 3 pods, using pod/immutable-configmap-volume-5c677f6494-n7cg5
Tue Mar  5 11:38:27 UTC 2024 My preferred season is summer
Tue Mar  5 11:38:37 UTC 2024 My preferred season is summer
Tue Mar  5 11:38:47 UTC 2024 My preferred season is summer
Tue Mar  5 11:38:57 UTC 2024 My preferred season is summer
Tue Mar  5 11:39:07 UTC 2024 My preferred season is summer

Edit the ConfigMap:

kubectl edit configmap season

In the editor that appears, change the value of key season from summer to winter.

Here's an example of how that manifest could look after you edit it:

apiVersion: v1
data:
  season: winter
immutable: true
kind: ConfigMap
# You can leave the existing metadata as they are.
# The values you'll see won't exactly match these.
metadata:
  annotations:
    kubectl.kubernetes.io/last-applied-configuration: |
      {"apiVersion":"v1","data":{"season":"summer"},"immutable":true,"kind":"ConfigMap","metadata":{"annotations":{},"name":"season","namespace":"default"}}      
  creationTimestamp: "2024-03-05T11:36:22Z"
  name: season
  namespace: default
  resourceVersion: "3840"
  uid: 10cdc5e6-47b8-4473-a9f3-ed401c2073f9

Attempt to save the changes. You should see that the save fails and a temporary manifest is opened which contains the reason for failure:

# reopened with the relevant failures.
#
# configmaps "season" was not valid:
# * data: Forbidden: field is immutable when `immutable` is set
#

Without any further change, save the temporary manifest. You should see an output similar to:

A copy of your changes has been stored to "/var/folders/nn/bb6y1j8d69n9lhqppjlrfthm0000gn/T/kubectl-edit-139284375.yaml"
error: Edit cancelled, no valid changes were saved.

Once a ConfigMap is marked as immutable, it is not possible to revert this change nor to mutate the contents of the data or the binaryData field. In order to modify the contents, the only option is to delete and recreate the ConfigMap.

Delete and recreate the ConfigMap season by using the temporary manifest as follows:

# Use the appropriate path to the temporary manifest
kubectl replace --force -f /var/folders/nn/bb6y1j8d69n9lhqppjlrfthm0000gn/T/kubectl-edit-139284375.yaml

Tail (follow the latest entries in) the logs of one of the pods that belongs to this Deployment:

# As the text explains, the output does NOT change
kubectl logs deployments/immutable-configmap-volume --follow

Notice that the output remains unchanged, even though you recreated the ConfigMap:

Tue Mar  5 12:02:07 UTC 2024 My preferred season is summer
Tue Mar  5 12:02:17 UTC 2024 My preferred season is summer
Tue Mar  5 12:02:27 UTC 2024 My preferred season is summer
Tue Mar  5 12:02:37 UTC 2024 My preferred season is summer

Delete the Deployment:

kubectl delete deployment immutable-configmap-volume

Wait for all the Pods to terminate. Verify that the Pods have terminated using the following command:

kubectl get pods --selector=app.kubernetes.io/name=immutable-configmap-volume

You should see an output similar to:

No resources found in default namespace.

Recreate the Deployment:

kubectl apply -f https://k8s.io/examples/deployments/deployment-with-immutable-configmap-as-volume.yaml

Next, check the Deployment:

kubectl get deployment immutable-configmap-volume

You should see an output similar to:

NAME                         READY   UP-TO-DATE   AVAILABLE   AGE
immutable-configmap-volume   3/3     3            3           6s

Check the Pods:

kubectl get pods --selector=app.kubernetes.io/name=immutable-configmap-volume

You should see an output similar to:

NAME                                          READY   STATUS    RESTARTS   AGE
immutable-configmap-volume-5c677f6494-dxjwg   1/1     Running   0          31s
immutable-configmap-volume-5c677f6494-k54fc   1/1     Running   0          31s
immutable-configmap-volume-5c677f6494-w9b4c   1/1     Running   0          31s

View the logs for a Pod in this Deployment:

# Pick one Pod that belongs to the Deployment, and view its logs
kubectl logs deployment/immutable-configmap-volume

You should see an output similar to the below:

Found 3 pods, using pod/immutable-configmap-volume-5c677f6494-dxjwg
Tue Mar  5 12:40:43 UTC 2024 My preferred season is winter
Tue Mar  5 12:40:53 UTC 2024 My preferred season is winter
Tue Mar  5 12:41:03 UTC 2024 My preferred season is winter

Summary

Once a ConfigMap is marked as immutable, it is not possible to revert this change nor to mutate the contents of the data or the binaryData field. You can only delete and recreate the ConfigMap. Because existing resources maintain a mount point to the deleted ConfigMap, it is necessary to ensure that every existing reference to the old ConfigMap (not just Pods, any reference) has been cleaned up.

Cleaning up

Delete the resources created during the tutorial:

kubectl delete deployment immutable-configmap-volume
kubectl delete configmap season

We will also dive into the usage of the kubectl command line tool to check API access in Kubernetes. It especially focuses on the difference between the --user and --as options in kubectl.

Prerequisites

You need to have a Kubernetes cluster, and the kubectl command-line tool must be configured to communicate with your cluster. If you do not already have a cluster, you can create one using minikube.

OpenSSL command line utility will be used to view the x509 certificates.

Role-based access control

Role-based access control (RBAC) is a method of regulating access to computer or network resources based on the roles of individual users within your organisation.

You may choose to go through the Kubernetes RBAC documentation before reading ahead.

Checking API Access

The kubectl auth can-i command can be used to determine whether a user has permissions to execute a certain action.

Scenario for the Default Admin User

In the first example, we will work with the default admin user.

Check the contexts available in the minikube cluster:

kubectl config get-contexts minikube

You should see an output similar to:

CURRENT   NAME       CLUSTER    AUTHINFO   NAMESPACE
*         minikube   minikube   minikube   default

Check the name of the admin user that is created with our basic minikube installation:

kubectl config view -o jsonpath='{.contexts[?(@.name=="minikube")].context.user}'

You should see an output similar to:

minikube

Check the certificate of the minikube user:

kubectl config view -o jsonpath='{.users[?(@.name=="minikube")].user.client-certificate}'

You should see an output similar to:

/Users/adityasamant/.minikube/profiles/minikube/client.crt

View the Subject of this certificate (use the path generated in the previous command):

openssl x509 -in /Users/adityasamant/.minikube/profiles/minikube/client.crt -text -noout | grep Subject | grep -v "Public Key Info"

You should see an output similar to:

Subject: O=system:masters, CN=minikube-user

Use the kubectl auth can-i command to verify a few scenarios.

Check permissions to create pods:

kubectl auth can-i create pods

yes

Check permissions to create deployments:

kubectl auth can-i create deployments

yes

Check permissions to delete secrets:

kubectl auth can-i delete secrets

yes

Scenario for a Normal User

Configure a normal user and verify how the kubectl auth can-i commands can be used to check the access. To do this we need to issue a certificate for the user.

Create a private key and a csr file:

openssl genrsa -out jane.key 2048
openssl req -new -key jane.key -out jane.csr -subj "/CN=jane"

This will generate a private key named jane.key and a certificate signing request named jane.csr.

Get the base64 encoded value of the CSR file content:

cat jane.csr | base64 | tr -d "\n"

Create a CertificateSigningRequest:

cat <<EOF | kubectl apply -f -
apiVersion: certificates.k8s.io/v1
kind: CertificateSigningRequest
metadata:
  name: jane
spec:
  request: <base64 encoded csr>
  signerName: kubernetes.io/kube-apiserver-client
  expirationSeconds: 86400  # one day
  usages:
  - client auth
EOF

Get the CSR:

kubectl get csr jane

NAME   AGE   SIGNERNAME                            REQUESTOR       REQUESTEDDURATION   CONDITION
jane   55s   kubernetes.io/kube-apiserver-client   minikube-user   24h                 Pending

Approve the CSR:

kubectl certificate approve jane

kubectl get csr jane

NAME   AGE     SIGNERNAME                            REQUESTOR       REQUESTEDDURATION   CONDITION
jane   2m17s   kubernetes.io/kube-apiserver-client   minikube-user   24h                 Approved,Issued

Granting permissions via RBAC

Create a clusterrole granting permissions to only create pods:

kubectl create clusterrole createpods --verb=create --resource=pods

clusterrole.rbac.authorization.k8s.io/createpods created

Create a clusterrolebinding to bind the clusterrole with user jane:

kubectl create clusterrolebinding createpods --clusterrole=createpods --user=jane

clusterrolebinding.rbac.authorization.k8s.io/createpods created

Difference between ‘--as’ and ‘--user’ options of kubectl

kubectl has a number of global options that can be passed as an argument to any kubectl command. The list can be found with the following command:

kubectl options

Two of the options are --user and --as. It is important to understand the difference between them.

--user='':
The name of the kubeconfig user to use

--as='':
Username to impersonate for the operation. 
User could be a regular user or a service account in a namespace.

Let’s put the theory into action with the help of the user we created.

Using ‘--as’ to Check Access

Check permissions to create pods:

kubectl auth can-i create pods --as=jane

yes

Check permissions to create deployments:

kubectl auth can-i create deployments --as=jane

no

Check permissions to delete secrets:

kubectl auth can-i delete secrets --as=jane

no

Due to the fact that we explicitly assigned the clusterrole createpods to user jane, we see that jane has access to create pods, but no access to create deployments or delete secrets. Great, this is as expected.

Using ‘--user’ to Check Access

Try the same commands, but this time using the --user option:

kubectl auth can-i create pods --user=jane

error: auth info "jane" does not exist

The command leads to an error. This is because we have not configured the user jane in the kubeconfig file.

We will fix this in the next step.

Adding the user to kubeconfig

Get the user’s certificate:

kubectl get csr jane -o jsonpath='{.status.certificate}'| base64 -d > jane.crt

Add the new credentials to kubeconfig:

kubectl config set-credentials jane --client-key=jane.key --client-certificate=jane.crt --embed-certs=true

User "jane" set.

Add the context to kubeconfig:

kubectl config set-context jane --cluster=minikube --user=jane

Context "jane" created.

Let’s try the kubectl auth can-i command once again to verify the permissions on user jane:

Check permissions to create pods:

kubectl auth can-i create pods --user=jane

yes

Check permissions to create deployments:

kubectl auth can-i create deployments --user=jane

no

Check permissions to delete secrets:

kubectl auth can-i delete secrets --user=jane

no

Now everything works as expected.

Example for a non-existent user

If the --as option is used for a non-existent user, there is no error thrown as shown below.

kubectl auth can-i create pods --as=nobody

no

Scenario for a Custom Admin User

Configure a new admin user and verify the behaviour of the kubectl auth can-i commands.

This time we will check the permissions that a user inherits via the group it is attached to.

Issue a certificate for the new admin user.

Create a private key and a csr file:

openssl genrsa -out poweruser.key 2048
openssl req -new -key poweruser.key -out poweruser.csr -subj "/CN=poweruser/O=system:masters"

Create a CertificateSigningRequest:

cat <<EOF | kubectl apply -f -
apiVersion: certificates.k8s.io/v1
kind: CertificateSigningRequest
metadata:
  name: poweruser
spec:
  request: <base64 encoded csr>
  signerName: kubernetes.io/kube-apiserver-client
  expirationSeconds: 86400  # one day
  usages:
  - client auth
EOF

The above command throws an error as the kube-apiserver blocks any CertificateSigningRequest that attempts to add a user as part of the system:masters group.

Error from server (Forbidden): error when creating “STDIN”: certificatesigningrequests.certificates.k8s.io “poweruser” is forbidden: use of kubernetes.io/kube-apiserver-client signer with system:masters group is not allowed

Granting permissions via RBAC through groups

In order to create a new admin user we will create a custom admin group that replicates the behaviour of the system:masters group. Let’s call it example:masters

To do this, create a new clusterrolebinding as below:

cat <<EOF | kubectl apply -f -
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: example-cluster-admin
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: cluster-admin
subjects:
- apiGroup: rbac.authorization.k8s.io
  kind: Group
  name: example:masters
EOF

The next step is to add the new admin user to the example:masters group.

Delete the previous files created for poweruser:

rm poweruser.key poweruser.csr

Create a new private key and a csr file:

openssl genrsa -out poweruser.key 2048
openssl req -new -key poweruser.key -out poweruser.csr -subj "/CN=poweruser/O=example:masters"

Create a CertificateSigningRequest:

cat <<EOF | kubectl apply -f -
apiVersion: certificates.k8s.io/v1
kind: CertificateSigningRequest
metadata:
  name: poweruser
spec:
  request: <base64 encoded csr>
  signerName: kubernetes.io/kube-apiserver-client
  expirationSeconds: 86400  # one day
  usages:
  - client auth
EOF

Approve the CSR:

kubectl certificate approve poweruser

certificatesigningrequest.certificates.k8s.io/poweruser approved

Get the certificate:

kubectl get csr poweruser -o jsonpath='{.status.certificate}'| base64 -d > poweruser.crt

View the Subject of this certificate:

openssl x509 -in poweruser.crt -text -noout | grep Subject | grep -v "Public Key Info"

Subject: O=example:masters, CN=poweruser

Add the new admin user to kubeconfig.

Add the new credentials:

kubectl config set-credentials poweruser --client-key=poweruser.key --client-certificate=poweruser.crt --embed-certs=true

User "poweruser" set.

Add the context:

kubectl config set-context poweruser --cluster=minikube --user=poweruser

Context "poweruser" created.

Try the kubectl auth can-i command to verify the permissions on the new admin user:

Check permissions to create pods:

kubectl auth can-i create pods --user=poweruser

yes

Check permissions to create deployments:

kubectl auth can-i create deployments --user=poweruser

yes

Check permissions to delete secrets:

kubectl auth can-i delete secrets --user=poweruser

yes

Try the same commands but with using the --as option.

Check permissions to create pods:

kubectl auth can-i create pods --as=poweruser

no

Check permissions to create deployments:

kubectl auth can-i create deployments --as=poweruser

no

Check permissions to delete secrets:

kubectl auth can-i delete secrets --as=poweruser

no

Strange!!! The expected output was yes for all 3 commands, as poweruser is an admin user with full access to the cluster.

We can prove this as follows:

Switch the context to work with the poweruser:

kubectl config use-context poweruser

Create a pod:

kubectl run nginx --image=nginx

pod/nginx created

Create the deployment:

kubectl create deployment nginx-deploy --image=nginx

deployment.apps/nginx-deploy created

Create and delete a secret:

kubectl create secret generic test-secret --from-literal=secret=1234

secret/test-secret created

kubectl delete secrets test-secret

secret "test-secret" deleted

My first thought was that this is a defect in Kubernetes.

I raised issue #122579 to Kubernetes for confirmation.

The reality is that the behaviour is as-expected. The API server has no knowledge of group membership apart from what is encoded directly in the credential or provided by a token webhook.

To overcome this you need to pass the group you want to impersonate with the --as-group flag.

The ‘--as-group’ option of kubectl

Try the same commands but this time append the --as-group option as well.

Check permissions to create pods:

kubectl auth can-i create pods --as=poweruser --as-group=example:masters

yes

Check permissions to create deployments:

kubectl auth can-i create deployments --as=poweruser --as-group=example:masters

yes

Check permissions to delete secrets:

kubectl auth can-i delete secrets --as=poweruser --as-group=example:masters

yes

Now the results are as expected.

Summary

The kubectl auth can-i command behaves differently for the --user and --as options.

The --user option checks for the actual presence of the user in the kubeconfig file and has the ability to check permissions derived from the group of the user.

The --as option can be used to check permissions for any user irrespective of its presence in the kubeconfig file. It checks permissions which are directly bound to the user through RBAC, and does not check permissions that are derived from the user’s group. The API server has no knowledge of group membership apart from whatever is encoded directly in the credential or provided by a token webhook.

The --as-group option should be used to check for permissions that are derived from the user’s group.

Cleaning up

Delete the resources created during this lab:

rm jane*
rm poweruser*
kubectl delete pod nginx
kubectl delete deployment nginx-deploy

Optionally, you can delete the entire minikube cluster:

minikube delete --all

Objectives

• Update configuration via a ConfigMap mounted as a Volume

• Update environment variables of a Pod via a ConfigMap

• Learn the difference between the two

Prerequisites

1. A local Kubernetes cluster such as minikube, kind, K3s or microk8s.

2. The kubectl command line tool to interact with the Kubernetes cluster.

Update configuration via a ConfigMap mounted as a Volume

Use the kubectl create configmap command to create a ConfigMap from literal values:

kubectl create configmap sport --from-literal=sport=football

Below is an example of a Deployment manifest with the ConfigMap sport mounted as a volume into the Pod's only container.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: configmap-volume
  labels:
    app.kubernetes.io/name: configmap-volume
spec:
  replicas: 3
  selector:
    matchLabels:
      app.kubernetes.io/name: configmap-volume
  template:
    metadata:
      labels:
        app.kubernetes.io/name: configmap-volume
    spec:
      containers:
        - name: alpine
          image: alpine:3
          command:
            - /bin/sh
            - -c
            - while true; do echo "$(date) My preferred sport is $(cat /etc/config/sport)";
              sleep 10; done;
          ports:
            - containerPort: 80
          volumeMounts:
            - name: config-volume
              mountPath: /etc/config
      volumes:
        - name: config-volume
          configMap:
            name: sport

Create the Deployment:

kubectl apply -f https://raw.githubusercontent.com/adityasamant25/courses/main/kubernetes/configmaps/examples/deployment-with-configmap-as-volume.yaml

Check the Deployment:

kubectl get deployment configmap-volume

You should see an output similar to:

NAME               READY   UP-TO-DATE   AVAILABLE   AGE
configmap-volume   3/3     3            3           19s

Check the pods for this Deployment (matching by selector):

kubectl get pods --selector=app.kubernetes.io/name=configmap-volume

You should see an output similar to:

NAME                                READY   STATUS    RESTARTS   AGE
configmap-volume-6b976dfdcf-qxvbm   1/1     Running   0          72s
configmap-volume-6b976dfdcf-skpvm   1/1     Running   0          72s
configmap-volume-6b976dfdcf-tbc6r   1/1     Running   0          72s

On each node where one of these Pods is running, the kubelet fetches the data for that ConfigMap and translates it to files in a local volume. The kubelet then mounts that volume into the container, as specified in the Pod template. The code running in that container loads the information from the file and uses it to print a report to stdout. You can check this report by viewing the logs for one of the Pods in that Deployment:

kubectl logs deployments/configmap-volume

You should see an output similar to:

Found 3 pods, using pod/configmap-volume-76d9c5678f-x5rgj
Thu Jan  4 14:06:46 UTC 2024 My preferred sport is football
Thu Jan  4 14:06:56 UTC 2024 My preferred sport is football
Thu Jan  4 14:07:06 UTC 2024 My preferred sport is football
Thu Jan  4 14:07:16 UTC 2024 My preferred sport is football
Thu Jan  4 14:07:26 UTC 2024 My preferred sport is football

Edit the ConfigMap:

kubectl edit configmap sport

In the editor that appears, change the value of key sport from football to cricket. Save your changes. The kubectl tool updates the ConfigMap accordingly (if you see an error, try again).

Here's an example of how that manifest could look after you edit it:

apiVersion: v1
data:
  sport: cricket
kind: ConfigMap
# You can leave the existing metadata as they are.
# The values you'll see won't exactly match these.
metadata:
  creationTimestamp: "2024-01-04T14:05:06Z"
  name: sport
  namespace: default
  resourceVersion: "1743935"
  uid: 024ee001-fe72-487e-872e-34d6464a8a23

You should see the following output:

configmap/sport edited

Tail (follow the latest entries in) the logs of one of the pods that belongs to this Deployment:

kubectl logs -f deployments/configmap-volume

After few seconds, you should see the log output change as follows:

Thu Jan  4 14:11:36 UTC 2024 My preferred sport is football
Thu Jan  4 14:11:46 UTC 2024 My preferred sport is football
Thu Jan  4 14:11:56 UTC 2024 My preferred sport is football
Thu Jan  4 14:12:06 UTC 2024 My preferred sport is cricket
Thu Jan  4 14:12:16 UTC 2024 My preferred sport is cricket

When you have a ConfigMap that is mapped into a running Pod using either a configMap volume or a projected volume, and you update that ConfigMap, the running Pod sees the update almost immediately. However, your application only sees the change if it is written to either poll for changes, or watch for file updates. An application that loads its configuration once at startup will not notice a change.

The total delay from the moment when the ConfigMap is updated to the moment when new keys are projected to the Pod can be as long as kubelet sync period. Also check Mounted ConfigMaps are updated automatically.

Update environment variables of a Pod via a ConfigMap

Use the kubectl create configmap command to create a ConfigMap from literal values:

kubectl create configmap fruits --from-literal=fruits=apples

Below is an example of a Deployment manifest with an environment variable configured via the ConfigMap fruits.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: configmap-env-var
  labels:
    app.kubernetes.io/name: configmap-env-var
spec:
  replicas: 3
  selector:
    matchLabels:
      app.kubernetes.io/name: configmap-env-var
  template:
    metadata:
      labels:
        app.kubernetes.io/name: configmap-env-var
    spec:
      containers:
        - name: alpine
          image: alpine:3
          env:
            - name: FRUITS
              valueFrom:
                configMapKeyRef:
                  key: fruits
                  name: fruits
          command:
            - /bin/sh
            - -c
            - while true; do echo "$(date) The basket is full of $FRUITS";
                sleep 10; done;
          ports:
            - containerPort: 80

Create the Deployment:

kubectl apply -f https://raw.githubusercontent.com/adityasamant25/courses/main/kubernetes/configmaps/examples/deployment-with-configmap-as-envvar.yaml

Check the Deployment:

kubectl get deployment configmap-env-var

You should see an output similar to:

NAME                READY   UP-TO-DATE   AVAILABLE   AGE
configmap-env-var   3/3     3            3           7s

Check the pods for this Deployment (matching by selector):

kubectl get pods --selector=app.kubernetes.io/name=configmap-env-var

You should see an output similar to:

NAME                                 READY   STATUS    RESTARTS   AGE
configmap-env-var-59cfc64f7d-74d7z   1/1     Running   0          46s
configmap-env-var-59cfc64f7d-c4wmj   1/1     Running   0          46s
configmap-env-var-59cfc64f7d-dpr98   1/1     Running   0          46s

The key-value pair in the ConfigMap is configured as an environment variable in the container of the Pod. Check this by viewing the logs of the Pod.

kubectl logs deployment/configmap-env-var

You should see an output similar to:

Found 3 pods, using pod/configmap-env-var-7c994f7769-l74nq
Thu Jan  4 16:07:06 UTC 2024 The basket is full of apples
Thu Jan  4 16:07:16 UTC 2024 The basket is full of apples
Thu Jan  4 16:07:26 UTC 2024 The basket is full of apples

Edit the ConfigMap:

kubectl edit configmap fruits

In the editor that appears, change the value of key fruits from apples to mangoes. Save your changes. The kubectl tool updates the ConfigMap accordingly (if you see an error, try again).

Here's an example of how that manifest could look after you edit it:

apiVersion: v1
data:
  fruits: mangoes
kind: ConfigMap
# You can leave the existing metadata as they are.
# The values you'll see won't exactly match these.
metadata:
  creationTimestamp: "2024-01-04T16:04:19Z"
  name: fruits
  namespace: default
  resourceVersion: "1749472"

You should see the following output:

configmap/fruits edited

Tail the logs of the Deployment and observe the output for few seconds:

kubectl logs deployment/configmap-env-var

Notice that the output remains unchanged, even though you edited the ConfigMap:

Thu Jan  4 16:12:56 UTC 2024 The basket is full of apples
Thu Jan  4 16:13:06 UTC 2024 The basket is full of apples
Thu Jan  4 16:13:16 UTC 2024 The basket is full of apples
Thu Jan  4 16:13:26 UTC 2024 The basket is full of apples

Although the value of the key inside the ConfigMap has changed, the environment variable in the Pod still shows the earlier value. This is because environment variables for a process running inside a Pod are not updated when the source data changes; if you wanted to force an update, you would need to have Kubernetes replace your existing Pods. The new Pods would then run with the updated information.

You can trigger that replacement. Perform a rollout for the Deployment, using kubectl rollout:

# Trigger the rollout
kubectl rollout restart deployment configmap-env-var

# Wait for the rollout to complete
kubectl rollout status deployment configmap-env-var --watch=true

Next, check the Deployment:

kubectl get deployment configmap-env-var

You should see an output similar to:

NAME                READY   UP-TO-DATE   AVAILABLE   AGE
configmap-env-var   3/3     3            3           12m

Check the Pods:

kubectl get pods --selector=app.kubernetes.io/name=configmap-env-var

The rollout caused Kubernetes to make a new ReplicaSet for the Deployment; that means that the existing Pods were terminated, and new ones have been created. You should finally see an output similar to:

NAME                                 READY   STATUS        RESTARTS   AGE
configmap-env-var-6d94d89bf5-2ph2l   1/1     Running       0          13s
configmap-env-var-6d94d89bf5-74twx   1/1     Running       0          8s
configmap-env-var-6d94d89bf5-d5vx8   1/1     Running       0          11s

View the logs for a Pod in this Deployment:

kubectl logs deployment/configmap-env-var

You should see an output similar to the below:

Found 3 pods, using pod/configmap-env-var-6d9ff89fb6-bzcf6
Thu Jan  4 16:30:35 UTC 2024 The basket is full of mangoes
Thu Jan  4 16:30:45 UTC 2024 The basket is full of mangoes
Thu Jan  4 16:30:55 UTC 2024 The basket is full of mangoes

This demonstrates the scenario of updating environment variables in a Pod that are derived from a ConfigMap. Changes to the ConfigMap values are applied to the Pod during the subsequent rollout. If Pods get created for another reason, such as scaling up the Deployment, then the new Pods also use the latest configuration values; if you don't trigger a rollout, then you might find that your app is running with a mix of old and new environment variable values.

Summary

Changes to a ConfigMap mounted as a Volume on a Pod are available seamlessly after the subsequent kubelet sync.

Changes to a ConfigMap that configures environment variables for a Pod are available after the subsequent rollout for the Pod.

Cleaning up

Delete the resources created during the tutorial:

kubectl delete deployment configmap-volume configmap-env-var
kubectl delete configmap sport fruits

As you progress through the course, it is critical to prepare notes along the way and use them to revise the important concepts a few days before the exam.

I am sharing the notes that I prepared during the many days of preparation for this exam. Hopefully these will assist you.

Please visit the link below to access the content:

AWS Certified Solutions Architect Associate - Important Concepts

In a world of microservices, a production grade enterprise application comprises of hundreds of docker images. Organisations and their customers have a high focus on the security of applications and one of the key requirements is to keep the count of Common Vulnerabilities and Exposures (CVEs) to a minimum. Many organisations have strict policies that prevent a vulnerable image to be deployed on production environments. Furthermore, docker images are often made up of layers. So a CVE in one of the base layers will propagate to all images built using the particular base layer.

CVEs are a moving target. New CVEs are identified and detected by vulnerability scanners each day. This calls for a process that scans and fixes these vulnerabilities.

Docker images are immutable. It means that the only way to fix a Docker image is to build a new patch containing the fix. The last thing you want is to release a new build only to realize it contains a bunch of CRITICAL CVEs and is a NO-GO for production.

There are a number of CVE scanners available, however in this article we will use Trivy from Aqua which is a free and open-source vulnerability scanner for images.

Installation

Installing CVE is trivial. Follow the steps for your platform of choice.

Using the CLI

If installed using a package manager or as a binary, trivy is available through a command line tool.

Use the following command to verify the installation:

trivy version

To demonstrate the command used for scanning, let's use the python:3.4-alpine image:

trivy image python:3.4-alpine

The command results in an output that reports the CVEs in the image, along with the ID, severity, description and a fixed version (if available).

python:3.4-alpine (alpine 3.9.2)

Total: 37 (UNKNOWN: 0, LOW: 4, MEDIUM: 16, HIGH: 13, CRITICAL: 4)

To capture the output in a file:

trivy image python:3.4-alpine > report.txt

Generally, CRITICAL and HIGH severity CVEs are considered as blockers for a release. So you may want the output to be filtered on CRITICAL and HIGH CVEs only.

For that, use the -s option

trivy image -s CRITICAL,HIGH python:3.4-alpine

Run as a Docker Image

An alternative way, is to run trivy as a docker container.

docker run -v /var/run/docker.sock:/var/run/docker.sock -v $HOME/Library/Caches:/root/.cache/ aquasec/trivy:0.49.1 image python:3.4-alpine

Summary

Using trivy is an easy and cost-effective way of scanning images for CVEs. Integrating it in CI/CD pipelines is recommended.

Istio is an open source service mesh that layers transparently onto distributed applications running on Kubernetes. Istio's powerful features provide a uniform and more efficient way to secure, connect, and monitor services.

In this post, I'll explain the bare minimum steps needed in order to successfully install and test Istio on your local machine.

Prerequisites

1. A local Kubernetes cluster such as minikube, kind, K3s or microk8s. In this blog post I have chosen minikube with the use of the minikube tunnel to provide a load balancer for use by Istio.

2. The kubectl command line tool to interact with the Kubernetes cluster.

Installation

Create a new minikube cluster:

minikube start -p minikube-istio

Start a minikube tunnel to provide a load balancer for use by Istio:

minikube tunnel -p minikube-istio

Download Istio as per the instructions in this link:

curl -L https://istio.io/downloadIstio | sh -

Add the istio-*/bin directory to your environment PATH variable and check the version:

istioctl version

The output should be similar to:

no ready Istio pods in "istio-system"
1.20.3

Install Istio with the demo profile:

istioctl install --set profile=demo

After successful installation, you should have an istio-system namespace available

kubectl get ns

You should see an output similar to:

NAME              STATUS   AGE
kube-system       Active   4m22s
default           Active   4m22s
kube-public       Active   4m22s
kube-node-lease   Active   4m22s
istio-system      Active   2m49s

Check the Pods inside the istio-system namespace:

kubectl get pods -n istio-system

You should see the istiod, istio-ingressgateway and the istio-egressgateway pods up and running.

Automatic Injection of Sidecars

Automatic injection of sidecar containers is achieved by setting the label istio-injection=enabled on namespaces.

kubectl label ns default istio-injection=enabled

Create a simple deployment of nginx to test the sidecar injection:

kubectl create deploy my-nginx --image=nginx

Get the details of the pod:

kubectl get pod

You will see two containers for the Pod, as it includes the sidecar container:

NAME                      READY   STATUS    RESTARTS   AGE
my-nginx-b8dd4cd6-4kh4x   2/2     Running   0          24s

Delete this deployment as we do not need it anymore:

kubectl delete deploy my-nginx

Demo Application

We will deploy an application with two Spring Boot microservices named customers and rest-client.

The customers microservice is a CRUD microservice that provides APIs to manipulate customer data.

The rest-client microservice acts as a client to the customers microservice and invokes it using the new RestClient in Spring Framework 6.1.x

Create the Gateway Resource:

kubectl apply -f https://raw.githubusercontent.com/adityasamant25/courses/main/istio/demo/gateway.yaml

Create the Deployment and Service for the rest-client application:

kubectl apply -f https://raw.githubusercontent.com/adityasamant25/courses/main/istio/demo/rest-client.yaml

Create the Deployment and Service for the customers application:

kubectl apply -f https://raw.githubusercontent.com/adityasamant25/courses/main/istio/demo/customers-v1.yaml

Create a Virtual Service for the rest-client and bind it to the Gateway resource:

kubectl apply -f https://raw.githubusercontent.com/adityasamant25/courses/main/istio/demo/rest-client-vs.yaml

Run CURL against the following URL:

curl http://127.0.0.1/api/customers

You should see an output of 3 customers as follows:

[
{"id":1,"firstName":"John","lastName":"Doe"},
{"id":2,"firstName":"Alice","lastName":"Smith"},
{"id":3,"firstName":"Bob","lastName":"Stevens"}
]

Summary

Congratulations! You have a functional Istio cluster up and running on your local machine.

You can now use this cluster to further explore the various features of Istio.

What's Next

Dig deeper into Istio's main features such as Observability, Traffic Management and Security.