DEV Community: Henrique

AKS with multiple nginx ingress controllers, Application Gateway and Key Vault certificates

Henrique — Tue, 01 Dec 2020 19:08:14 +0000

Intro

In the previous blog post we created an AKS cluster with an nginx ingress controller and certificates retrieved from Azure Key Vault.

For this blog post we will extend that previous setup and include;

Deploy Azure Private DNS
Deploy two nginx ingress controllers running in the cluster (one for internal the other for public traffic. Both with internal ip adresses)
Deploy one Application Gateway as the entry point for the public traffic, that will be integrated with Key Vault and do SSL termination

To follow this blog post it is required that you have an AKS cluster and the components discussed in the previous post installed

1. Azure Private DNS

Create Azure Private DNS resource

#Setup some variables that we are going to use throughout the scripts
export SUBSCRIPTION_ID="<SubscriptionID>"
export TENANT_ID="<YOUR TENANT ID>"
export RESOURCE_GROUP="<AKSResourceGroup>"
export CLUSTER_NAME="<AKSClusterName>"
export REGION="westeurope"
export NODE_RESOURCE_GROUP="MC_${RESOURCE_GROUP}_${CLUSTER_NAME}_${REGION}"
export IDENTITY_NAME="identity-aad" #must be lower case
export KEYVAULT_NAME="<KeyVault Name>"
export DNS_ZONE="private.contoso.com"
export PUBLIC_DNS_ZONE="public.contoso.com"

az network private-dns zone create -g ${RESOURCE_GROUP} -n ${DNS_ZONE}
az network private-dns zone create -g ${RESOURCE_GROUP} -n ${PUBLIC_DNS_ZONE}

Link the private DNS zone with the AKS Virtual Network (Vnet that was created by AKS). This will allow for resources in that virtual network to resolve the DNS name.

You can get the AKS Vnet Resource Id by going into the Node Resource Group that was created by AKS, the naming convention is MC_<resource group name>_<aks name>_<region>. Click the Virtual Network resource and copy the Virtual Network Resource Id from the properties.

az network private-dns link vnet create -g ${RESOURCE_GROUP} -n MyDNSLink -z ${DNS_ZONE} -v <AKS Vnet Resource ID> -e true

#register public dns zone - this time auto register is false because only one link can be true in the same vnet
az network private-dns link vnet create -g ${RESOURCE_GROUP} -n MyDNSLink -z ${PUBLIC_DNS_ZONE} -v <AKS Vnet Resource ID> -e false

When finished you can check the link was created in the Private DNS Zone

2. nginx ingress controller

First let's create a new certificate and import it to Key Vault. The other certificate for the DNS_ZONE was created in the previous post

export CERT_NAME=publicingresscert
openssl req -x509 -nodes -days 365 -newkey rsa:2048 \
    -out ingress-tls.crt \
    -keyout ingress-tls.key \
    -subj "/CN=${PUBLIC_DNS_ZONE}"

openssl pkcs12 -export -in ingress-tls.crt -inkey ingress-tls.key  -out $CERT_NAME.pfx
# skip Password prompt

az keyvault certificate import --vault-name ${KEYVAULT_NAME} -n $CERT_NAME -f $CERT_NAME.pfx

If continuing from the last post you should have two certificates, with the addition of the newly created publicingresscert

In this article I wont be creating a new identities and will reuse the same identity created in the last post

Now lets configure the ingress controllers. To be able to run multiple ingress controllers you need to configure the ingress class and add the correct annotation to the ingress to map to the correct ingress controller. More info

Install or upgrade the helm release (if continuing from the previous post)

# internal ingress controller - set ingress class = nginx-internal
helm install nginx-ingress-internal ingress-nginx/ingress-nginx \
    --set controller.replicaCount=2 \
    --set controller.ingressClass=nginx-internal \
    --set controller.podLabels.aadpodidbinding=${IDENTITY_NAME} \
    -f - <<EOF
controller:
  service:
    annotations:
      service.beta.kubernetes.io/azure-load-balancer-internal: "true"
  extraVolumes:
      - name: secrets-store-inline
        csi:
            driver: secrets-store.csi.k8s.io
            readOnly: true
            volumeAttributes:
              secretProviderClass: "ingress-tls"   #name of the SecretProviderClass we created above
  extraVolumeMounts:
      - name: secrets-store-inline
        mountPath: "/mnt/secrets-store"
        readOnly: true
EOF

#external ingress controller - set ingress class = nginx-external
helm install nginx-ingress-external ingress-nginx/ingress-nginx \
    --set controller.replicaCount=2 \
    --set controller.ingressClass=nginx-external \
    --set controller.service.annotations."service\.beta\.kubernetes\.io/azure-load-balancer-internal"=true

As you can see in the scripts each ingress controller has an ingressClass and the annotation for internal load balancer defined.

After the install succeeds you will have 4 new pods, two for the internal ingress and two for the external ingress because we defined 2 replicas.

There are also 2 new services with internal ips from the range of your virtual network.

Now lets created both ingresses, remember the ingress class we defined for each ingress controller? Now is the time to use that property.

#deploy the second demo app
kubectl apply -f https://raw.githubusercontent.com/hjgraca/playground/master/k8s/nginx/secondapp.yaml

#internal ingress
cat <<EOF | kubectl apply -f -
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  annotations:
    kubernetes.io/ingress.class: nginx-internal
  name: internal-ingress
  namespace: default
spec:
  tls:
  - hosts:
    - $DNS_ZONE
    secretName: ingress-tls-csi   # the secret that got created by the secret store provider and assigned to the ingress controller
  rules:
    - host: $DNS_ZONE
      http:
        paths:
          - backend:
              serviceName: firstapp
              servicePort: 80
            path: /
EOF

#external ingress, without TLS, the TLS is taken care by Application Gateway
cat <<EOF | kubectl apply -f -
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  annotations:
    kubernetes.io/ingress.class: nginx-external
  name: external-ingress
  namespace: default
spec:
  rules:
    - host: $PUBLIC_DNS_ZONE
      http:
        paths:
          - backend:
              serviceName: secondapp
              servicePort: 80
            path: /
EOF

Once installed we can get the ingresses, the list will show the hosts and the binding ip, if you describe one of the ingresses you can see what service and pods it is attached to.

I found that its better to wait for one ingress controller to be fully installed and only then move to the next one.

Let's test the endpoints

Firstly lets add those ip addresses to the Private DNS Zones we created earlier

az network private-dns record-set a add-record -g ${RESOURCE_GROUP} -z ${DNS_ZONE} -n @ -a <ip address of internal ingress>

az network private-dns record-set a add-record -g ${RESOURCE_GROUP} -z ${PUBLIC_DNS_ZONE} -n @ -a <ip address of external ingress>

Those scripts will create A records for the domain in the Private DNS Zones

Since we are using internal ip addresses, the only way we can resolve those ips is from within that virtual network, vpn, bastion. I am going for the simplest option of running a pod inside the cluster.

#run a pod with a tweaked busybox image with curl
kubectl run -it --rm jumpbox-pod --image=radial/busyboxplus:curl

#when in the prompt we can now curl our private endpoints
#public -> external ingress -> non TLS -> returns secondapp
curl http://public.contoso.com

#private -> internal ingress -> TLS -> returns firstapp
curl -v -k https://private.contoso.com

Now internal consumers can get to our TLS protected endpoint using https://private.contoso.com as long as they are in the same virtual network, for other ways of resolution, like resolving from on-premises you will need a DNS forwarder running in Azure that will forward the DNS queries to the Azure DNS.

As for external consumers we want to protected that endpoint using Application Gateway.

3. Azure Application Gateway to expose service

To create an Application Gateway we first need some infrastructure to be present.

#first create a subnet in the existing AKS Vnet
az network vnet subnet create \
  --name AppGwSubnet \
  --resource-group ${NODE_RESOURCE_GROUP} \ 
  --vnet-name <name of the vnet>  \
  --address-prefix 10.0.2.0/27

#Now lets create the public ip that will serve the public requests
az network public-ip create \
  --resource-group ${RESOURCE_GROUP} \
  --name myAGPublicIPAddress \
  --allocation-method Static \
  --sku Standard

Results in 2 subnets

And a Public Ip Address in your Resource Group

Now let's create the Application Gateway (disclaimer; since I did not create a vnet in the resource group where the AKS is I will have to deploy to the Node Resource Group)

export APPGW_NAME="myAppGateway"

#create application gateway
az network application-gateway create \
  --name ${APPGW_NAME} \
  --location ${REGION} \
  --resource-group ${NODE_RESOURCE_GROUP} \
  --capacity 1 \
  --sku Standard_v2 \
  --public-ip-address myAGPublicIPAddress \
  --vnet-name <VNET Name> \
  --subnet AppGwSubnet

#add backend pool ip address of our ingress
az network application-gateway address-pool create -g ${NODE_RESOURCE_GROUP} --gateway-name ${APPGW_NAME} -n AKSAddressPool --servers <ip address of your public ingress>

# One time operation, assign the identity to Application Gateway so we can access key vault
az network application-gateway identity assign \
  --gateway-name ${APPGW_NAME} \
  --resource-group ${NODE_RESOURCE_GROUP} \
  --identity ${IDENTITY_RESOURCE_ID}

#get secret-id of your certificate from keyvault
versionedSecretId=$(az keyvault certificate show -n publicingresscert --vault-name $KEYVAULT_NAME --query "sid" -o tsv)
unversionedSecretId=$(echo $versionedSecretId | cut -d'/' -f-5) # remove the version from the url

#add the ssl certificate to app gateway
az network application-gateway ssl-cert create \
  --resource-group ${NODE_RESOURCE_GROUP} \
  --gateway-name ${APPGW_NAME} \
  -n MySSLCert \
  --key-vault-secret-id $unversionedSecretId

#create a new port for HTTPS
az network application-gateway frontend-port create \
  --port 443 \
  --gateway-name ${APPGW_NAME} \
  --resource-group ${NODE_RESOURCE_GROUP} \
  --name port443

#create an HTTP-LISTENER for HTTPS that uses your certificate
#this is your entry point
az network application-gateway http-listener create -g ${NODE_RESOURCE_GROUP} --gateway-name ${APPGW_NAME} \
    --frontend-port port443 -n https --frontend-ip appGatewayFrontendIP  --ssl-cert MySSLCert --host-name ${PUBLIC_DNS_ZONE}

#create a rule to map the http listener to the backend pool
az network application-gateway rule create \
  --gateway-name ${APPGW_NAME} \
  --name rule2 \
  --resource-group ${NODE_RESOURCE_GROUP} \
  --http-listener https \
  --address-pool AKSAddressPool

# create a custom probe with the host name specified
az network application-gateway probe create -g ${NODE_RESOURCE_GROUP} --gateway-name ${APPGW_NAME} \
    -n MyProbe --protocol http --host ${PUBLIC_DNS_ZONE} --path /


# upadte the http-settings to use the new probe
az network application-gateway http-settings update --enable-probe true --gateway-name ${APPGW_NAME} --name appGatewayBackendHttpSettings --probe MyProbe --resource-group ${NODE_RESOURCE_GROUP}

After deploying and configuring the Application Gateway we can now test our public endpoint, since this is not a domain I own we will need to use curl or change the local hosts file.

#curl the public endpoint resolve the ip and validate the certificates
curl -v -k --resolve $PUBLIC_DNS_ZONE:443:20..***** https://$PUBLIC_DNS_ZONE

#the response 
* Server certificate:
*  subject: CN=public.contoso.com
*  start date: Nov 30 21:05:33 2020 GMT
*  expire date: Nov 30 21:05:33 2021 GMT
*  issuer: CN=public.contoso.com
*  SSL certificate verify result: self signed certificate (18), continuing anyway.

#and the secondapp html is returned

We did it!

What did we do?

Deployed two ingress controllers in our cluster, one for internal traffic the other for public traffic; the scenario is when you want to separate your workloads for different audiances
Deployed one ingress with TLS, the certificate was stored in Key Vault and we were able to assign that secret to our ingress using AAD pod identity and CSI Secret Store Provider
Deployed another ingress without TLS but still internal load balancer
Deployed an Azure Application Gateway that does the TLS offloading and gets the certificate from Key Vault, it uses the same User Assigned Managed Identity that we used for the AAD pod identity to access Key Vault
A private DNS zone so we can resolve DNS names from our virtual network

Final Notes

It's easier/recommended to deploy Application Gateway using ARM or Terraform
If you want to automatically add your private DNS Zones based on the Kubernetes ingresses you can use a tool like External-DNS

AKS ingress with nginx and Key Vault certificates

Henrique — Mon, 30 Nov 2020 20:14:39 +0000

Intro

In this blog post I will show you how to deploy nginx ingress controller in AKS and secure the backends with TLS certificates that are stored in Key Vault.

Part 2 of this blog post can be found here, were we augment this setup with internal ip addresses and Azure Application Gateway

To securely access Key Vault from the pods we will create an User Assigned Managed Identity and install AAD pod identity and CSI Secret Store Provider in the cluster.

What we will build

1. Installing AKS

The simplest way to create and AKS cluster is using Azure command line interface. For instructions on how to install follow this link.

After installing Azure cli it is also convinient to install kubectl to access the cluster, you can do that running az aks install-cli

First create a resource group and create the AKS cluster with the default settings.

With default settings you will create a cluster with Kubenet networking. This is enough for this blog post.

#Setup some variables that we are going to use throughout the scripts
export SUBSCRIPTION_ID="<SubscriptionID>"
export TENANT_ID="<YOUR TENANT ID>"
export RESOURCE_GROUP="<AKSResourceGroup>"
export CLUSTER_NAME="<AKSClusterName>"
export REGION="westeurope"
export NODE_RESOURCE_GROUP="MC_${RESOURCE_GROUP}_${CLUSTER_NAME}_${REGION}"
export IDENTITY_NAME="identity-aad" #must be lower case
export KEYVAULT_NAME="<KeyVault Name>"
export DNS_ZONE="private.contoso.com"

#create resource group
az group create --name ${RESOURCE_GROUP} --location ${REGION}
#create cluster
az aks create --resource-group ${RESOURCE_GROUP} --name ${CLUSTER_NAME} --node-count 1 --generate-ssh-keys

2. Azure Key Vault

Same as before we will use Azure cli to install Key Vault on the same resource group as AKS.

az keyvault create --name ${KEYVAULT_NAME} --resource-group ${RESOURCE_GROUP} --location ${REGION}

3. Roles

Remember when AKS was able to create Azure resources this was because AKS has an identity, in our case a Service Principal that has permissions to manage resources on the Node Resource Group.

This section explains various role assignments that need to be performed before using AAD Pod Identity. Without the proper role assignments, your Azure cluster will not have the correct permission to assign and un-assign identities from the underlying virtual machines (VM) or virtual machine scale sets (VMSS).

To follow best practices I will not be using the AKS Service Principal but will create a User Assigned Managed Identity and bind it to AAD Pod Identity.

We will also provide this managed identity access to get certificates from Key Vault

# Get the AKS service principal Id
export SP_ID="$(az aks show -g ${RESOURCE_GROUP} -n ${CLUSTER_NAME} --query servicePrincipalProfile.clientId -otsv)"
#Assign the roles
az role assignment create --role "Managed Identity Operator" --assignee ${SP_ID} --scope /subscriptions/${SUBSCRIPTION_ID}/resourcegroups/${NODE_RESOURCE_GROUP}
az role assignment create --role "Virtual Machine Contributor" --assignee ${SP_ID} --scope /subscriptions/${SUBSCRIPTION_ID}/resourcegroups/${NODE_RESOURCE_GROUP}

#Create an User Assigned Managed Identity
az identity create -g ${RESOURCE_GROUP} -n ${IDENTITY_NAME}
export IDENTITY_CLIENT_ID="$(az identity show -g ${RESOURCE_GROUP} -n ${IDENTITY_NAME} --query clientId -otsv)"
export IDENTITY_RESOURCE_ID="$(az identity show -g ${RESOURCE_GROUP} -n ${IDENTITY_NAME} --query id -otsv)"

#Assign the Service principal as an operator to the Managed User Identity
az role assignment create --role "Managed Identity Operator" --assignee ${SP_ID} --scope ${IDENTITY_RESOURCE_ID}

#Assign Reader Role to new Identity for your keyvault
az role assignment create --role Reader --assignee ${IDENTITY_CLIENT_ID} --scope /subscriptions/${SUBSCRIPTION_ID}/resourcegroups/${RESOURCE_GROUP}/providers/Microsoft.KeyVault/vaults/${KEYVAULT_NAME}

# set policy to access certs in your keyvault
az keyvault set-policy -n ${KEYVAULT_NAME} --certificate-permissions get --spn ${IDENTITY_CLIENT_ID}
az keyvault set-policy -n ${KEYVAULT_NAME} --secret-permissions get --spn ${IDENTITY_CLIENT_ID}

For next steps we will require

Helm to be installed, instructions here

Kubernetes context correctly configured; az aks get-credentials -g ${RESOURCE_GROUP} -n ${CLUSTER_NAME}

4. AAD pod identity

Now that we have our roles configured it's time to install AAD Pod Identity, which enables Kubernetes applications to access cloud resources securely with Azure Active Directory.

Since we are using kubenet and starting on version 1.7 of AAD pod identity we need to explicitly enable the support for it to be able to run in Kubenet clusters by enabling the flag --allow-network-plugin-kubenet=true. More info

#add the helm repo to our helm workspace
helm repo add aad-pod-identity https://raw.githubusercontent.com/Azure/aad-pod-identity/master/charts
#install aad pod identity with the Kubenet flag
helm install aad-pod-identity aad-pod-identity/aad-pod-identity --set nmi.allowNetworkPluginKubenet=true

Now that the crds are installed and the AAD pod identity pods are running we can deploy our identity and identity binding.

Create an AzureIdentity with type 0 (Set type: 0 for user-assigned MSI, type: 1 for Service Principal with client secret, or type: 2 for Service Principal with certificate. For more information, see here).

cat <<EOF | kubectl apply -f -
apiVersion: "aadpodidentity.k8s.io/v1"
kind: AzureIdentity
metadata:
  name: ${IDENTITY_NAME}
spec:
  type: 0
  resourceID: ${IDENTITY_RESOURCE_ID} #Resource Id of the Managed Identity
  clientID: ${IDENTITY_CLIENT_ID} #Id of the Managed Identity 
EOF

Now that the Identity is created we need to create an identity binding that defines the relationship between an AzureIdentity and a pod with a specific selector.

cat <<EOF | kubectl apply -f -
apiVersion: "aadpodidentity.k8s.io/v1"
kind: AzureIdentityBinding
metadata:
  name: ${IDENTITY_NAME}-binding
spec:
  azureIdentity: ${IDENTITY_NAME}
  selector: ${IDENTITY_NAME}
EOF

5. CSI Secret Store Provider (Key Vault integration)

Firstly lets create a certificate and store it in Key Vault

export CERT_NAME=ingresscert
openssl req -x509 -nodes -days 365 -newkey rsa:2048 \
    -out ingress-tls.crt \
    -keyout ingress-tls.key \
    -subj "/CN=${DNS_ZONE}"

openssl pkcs12 -export -in ingress-tls.crt -inkey ingress-tls.key  -out $CERT_NAME.pfx
# skip Password prompt

az keyvault certificate import --vault-name ${KEYVAULT_NAME} -n $CERT_NAME -f $CERT_NAME.pfx

You should see a new certificate in the Certificates window in Key Vault

Now let's install the Secrets Store Provider

#add the repo
helm repo add csi-secrets-store-provider-azure https://raw.githubusercontent.com/Azure/secrets-store-csi-driver-provider-azure/master/charts
#install chart
helm install csi-secrets-store-provider-azure/csi-secrets-store-provider-azure --generate-name

Now we have another crd available SecretProviderClass, this crd provides provider-specific (Azure) parameters to the Secret Score CSI driver.

NOTE: The SecretProviderClass has to be in the same namespace as the pod referencing it.

cat <<EOF | kubectl apply -n default -f -
apiVersion: secrets-store.csi.x-k8s.io/v1alpha1
kind: SecretProviderClass
metadata:
  name: ingress-tls
spec:
  provider: azure
  secretObjects:                                
  - secretName: ingress-tls-csi    #name of the secret that gets created - this is the value we provide to nginx
    type: kubernetes.io/tls
    data: 
    - objectName: $CERT_NAME
      key: tls.key
    - objectName: $CERT_NAME
      key: tls.crt
  parameters:
    usePodIdentity: "true"   #since we are using aad pod identity we set this to true
    keyvaultName: $KEYVAULT_NAME                        
    objects: |
      array:
        - |
          objectName: $CERT_NAME
          objectType: secret
    tenantId: $TENANT_ID      # the tenant ID of KeyVault            
EOF

6. Install nginx ingress controller

We are now going to create an ingress controller that will expose a public ip and will be able to serve TLS requests (It will give a warning because its a self-signed certificate)

#add the repo
helm repo add ingress-nginx https://kubernetes.github.io/ingress-nginx
#install nginx ingress controller
helm install ingress-nginx/ingress-nginx --generate-name \
    --set controller.replicaCount=2 \
    --set controller.podLabels.aadpodidbinding=${IDENTITY_NAME} \
    -f - <<EOF
controller:
  extraVolumes:
      - name: secrets-store-inline
        csi:
            driver: secrets-store.csi.k8s.io
            readOnly: true
            volumeAttributes:
              secretProviderClass: "ingress-tls"   #name of the SecretProviderClass we created above
  extraVolumeMounts:
      - name: secrets-store-inline
        mountPath: "/mnt/secrets-store"
        readOnly: true
EOF

This script will install nginx ingress controller and configure the Secret Store driver.
We also set the label aadpodidbinding with the identity name for the identity binding to assign the correct identity to this pod.

it's also recommended to have at least 2 replicas of the ingress running. When you need to refresh the certificate the way you have to do it is by restarting the ingress controller pods. There is some work happening that will improve this by providing a better way of refreshing secrets.

This is the moment of truth if everything worked as expected this is when nginx ingress controller will ask Secret Store driver for a secret, and in turn Secret Store will use AAD pod identity to get that secret from Key Vault

The list of running pods

The list of secrets which contain the secret that was created by the Secret Store provider ingress-tls-csi, this is the secret we will use on nginx ingress

7. Preparing the ingress

Let's start by deploying a simple demo application, that exposes a ClusterIP service on port 80 and will serve as the backend to our ingress

kubectl apply -f https://raw.githubusercontent.com/hjgraca/playground/master/k8s/nginx/firstapp.yaml

Let's deploy the ingress

cat <<EOF | kubectl apply -f -
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  name: ingress
  namespace: default
spec:
  tls:
  - hosts:
    - $DNS_ZONE
    secretName: ingress-tls-csi
  rules:
    - host: $DNS_ZONE
      http:
        paths:
          - backend:
              serviceName: firstapp
              servicePort: 80
            path: /
EOF

Now let's access that public ip to see if everything worked.
Since private.contoso.com is not a valid domain owned by us and mapped to that ip address to be able to get a response we either change our local hosts file or use curl to do that for us.

curl -v -k --resolve $DNS_ZONE:443:20.71.67.138 https://$DNS_ZONE

#you should see something like this in the reply
* Server certificate:
*  subject: CN=private.contoso.com
*  start date: Nov 30 17:47:25 2020 GMT
*  expire date: Nov 30 17:47:25 2021 GMT
*  issuer: CN=private.contoso.com
*  SSL certificate verify result: self signed certificate (18), continuing anyway.

And if I change my hosts file, I can resolve the domain private.contoso.com but I get an expected error from the browser, if I check the certificate I can see it is indeed my self-signed certificate.

And that's it you now have a secure(ish) TLS endpoint using a certificate stored in Key Vault.

Final notes

Delete the ingress controller

helm delete ingress-nginx-****

This will delete the public ip address and the secret that contains the certificate.

If you are looking into storing Let's Encrypt certificates in Key Vault have a look at this project on GitHub
If you want to renew the certificate, after updating it in Key Vault you will need to delete the existing ingress controller pods, so they can ask for a new secret to be generated.
For the second part of this tutorial I will add a Private DNS zone and two ingress controllers one for public and the other for private traffic.

Style your Windows terminal and use WSL and PowerShell like a pro

Henrique — Thu, 14 Nov 2019 11:12:11 +0000

With zsh and powerline10k you can have a terminal that will make your unix friends jealous 😀

Finished look of the terminal

Some assumptions

Have WSL installed. If not you can follow the official docs (I am using Ubuntu 18.04). Once you finished installing you need to setup for the first time, follow tutorial here
(optional) Have WSL 2 installed following the official docs (WSL 2 is only available in Windows 10 builds 18917 or higher)
Have the new Windows Terminal (preview) installed. You can get it from the Windows Store

Getting Started

Without any styling you should have something very similar to this

Default Windows Terminal screen

The first thing I recommend it to go into the settings and change the default profile to Ubuntu. After you click settings your json editor will popup with the profiles.json file.

Next you are going to add two new schemes to the file and change the default values from the PowerShell and Ubuntu profiles. The end result will be:

Great after we saved the file we should see something different

Ubuntu

PowerShell

Looks better but not there yet. You must have noticed the font faces in the profiles, those do not exist in windows by default so we need to install them.

Fonts

Install Powerline fonts in Windows

To have a correctly working theme, you needed to download and install some needed fonts.

Open Powershell command prompt:

git clone [https://github.com/powerline/fonts.git](https://github.com/powerline/fonts.git) --depth=1

cd fonts

.\install.ps1

# this will take a while to install all fonts. you can delete the folder after.

Next go to Nerd Fonts and download and install the font you like. In this tutorial I downloaded the mononokifont. These are custom fonts and icons for your terminal.

Unzip the file

And install the font

PowerShell

Let´s start by styling PowerShell (scroll down if you want to see WSL). You will need to have installed Git for Windows .

Follow these directions, this will install Posh-Git and Oh-My-Posh.

Install posh-git and oh-my-posh:

# You could have the following to allow for scripts execution 
# Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope CurrentUser

Install-Module posh-git -Scope CurrentUser
Install-Module oh-my-posh -Scope CurrentUser

Enable the prompt:

# Start the default settings (might not work so optional)
Set-Prompt

# To enable the engine edit your PowerShell profile, run
notepad $PROFILE

# and append the following lines to the profile file you just opened (or created in case the file was not there already):

Import-Module posh-git
Import-Module oh-my-posh
Set-Theme Paradox

Once you are done this is what your PowerShell will look like. You can get other themes here. And as you can see all icons are there including the git icons 😎

WSL

Now that we have PowerShell styled lets take care of Ubuntu.

First install zsh

sudo apt-get install zsh curl git

Install oh-my-zsh.

# When prompted to set zsh as your default shell say Yes

sh -c "$(curl -fsSL https://raw.githubusercontent.com/robbyrussell/oh-my-zsh/master/tools/install.sh)"

If all went well, your Ubuntu terminal shell should look like this. Just your username in the prompt.

Now we are ready to add some themes. I will be using Powerlevel10k . And because we have oh my zsh installed we just need to run the following scripts

git clone --depth=1 https://github.com/romkatv/powerlevel10k.git $ZSH\_CUSTOM/themes/powerlevel10k

Set ZSH_THEME=powerlevel10k/powerlevel10k in your ~/.zshrc. To do that run vim ~/.zshrcand replace the ZSH_THEME value. Save and exit Vim 😂

Now restart the Windows Terminal and you should see the Powerlevel10k configuration wizard

If all the fonts were installed correctly you should see a diamond (like above) a lock and a debian logo. Follow the wizard until the end and then apply your changes to the ~/.zshrc file

Depending on the style you chose you should have a good looking terminal like this.

That’s it you now have a very good looking PowerShell and WSL terminal that will make your unix friends jealous 😍

Extras for WSL

Plugins

zsh and Powerlevel10k have an enormous amount of plugins and extensions that you can add to your shell.

Add Auto Suggestions (repo)

Clone this repository into $ZSH_CUSTOM/plugins (by default ~/.oh-my-zsh/custom/plugins)

git clone [https://github.com/zsh-users/zsh-autosuggestions](https://github.com/zsh-users/zsh-autosuggestions) ${ZSH\_CUSTOM:-~/.oh-my-zsh/custom}/plugins/zsh-autosuggestions

Add the plugin to the list of plugins for Oh My Zsh to load (inside ~/.zshrc): (you will probably have git already)

plugins=(zsh-autosuggestions)

# and bellow add: to fix the suggestion style

ZSH\_AUTOSUGGEST\_HIGHLIGHT\_STYLE="fg=244"

Start a new terminal session. And now you have auto suggestions.

Kubectl plugin (repo)

For those like me that have to deal with Kubernetes this is an amazing plugin, because it gives you autocomplete and many aliases for you to have to type less. What do you have to do?! Very easy just open ~/.zshrc and edit the plugins line and add kubectl. Save and exit Vim

plugins=(git zsh-autosuggestions **kubectl** )

Restart the terminal session

Styling the prompt with Powerlevel10k

We can add many things to the prompt, like aws or azure login user information, Kubernetes cluster and namespace information, nodejs version and so on. To do so we need to edit the Powerlevel10k configuration file ~/.p10k.zsh :

vim ~/.p10k.zsh

Change the POWERLEVEL9K_LEFT_PROMPT_ELEMENTS to change the left hand side of the prompt.

Change the POWERLEVEL9K_RIGHT_PROMPT_ELEMENTS to change the right hand side of the prompt. This is where most of the elements are.

For example to add the Kubernetes cluster and namespace information I just enable the kubecontext element. And for the battery information the *battery * element

In pink the Kubernetes cluster(aks9533) and namepsace (demo).

And that’s it, totally customizable and good looking terminal. To learn more have a look at the style your prompt guide of Powerlevel9k (original project) to know what to change.

Using WSL2 + Visual Studio Code for Jekyll blogging on Windows 10

Henrique — Thu, 05 Sep 2019 16:11:56 +0000

If you are like me and have your blog hosted on GitHub pages you are using Jekyll as your blog generation engine. Turns out that Jekyll does not support Windows so you have to do some hacking in order to make it work on Windows. In this post I will show you how to take advantage of WSL2 and Ubuntu 18.04 to install Jekyll and locally run your blog.

What is Windows Subsystem for Linux 2?

The Windows Subsystem for Linux (WSL) is a new Windows 10 feature that enables you to run native Linux command-line tools directly on Windows.

WSL 2 is a new version of the architecture that powers the Windows Subsystem for Linux to run ELF64 Linux binaries on Windows. This new architecture changes how these Linux binaries interact with Windows and your computer’s hardware, but still provides the same user experience as in WSL 1 (the current widely available version). Individual Linux distros can be run either as a WSL 1 distro, or as a WSL 2 distro, can be upgraded or downgraded at any time, and you can run WSL 1 and WSL 2 distros side by side. WSL 2 uses an entirely new architecture that uses a real Linux kernel.

How to install WSL2 is documented here

Visual Studio Remote WSL

If you have VS Code already installed you will need to install the Remote WSL extension so that you are able to run linux commands and applications against your mounted Windows folder where your Jekyll blog is.

Extension is here

After the extension is installed you will see a small icon on the bottom left of VS Code

VS Code Remote icon

What I usually do is open the folder that as the blog before starting the remote session. Once I have the folder open in VS Code I click on the Remote WSL icon and are presented with the following options:

Remote WSL options

You will then choose Remote-WSL: Reopen Folder in WSL (if you had the folder opened). Once everything is finished the icon will change to:

Session established

Now open the terminal window and you will see that the context is your Ubuntu machine and the folder is a mount to your Jekyll blog folder

Installing Jekyll in WSL Ubuntu 18.04

And now you can run your blog locally in Windows 10 with the power of WSL2 and Linux without having to hack your way installing Jekyll on Windows.