I ran into this problem trying to do a port-forward on port 443 in WSL2. Normally you don’t use ‘sudo’ for ‘kubectl’ commands but when it comes to port-forwarding ports under port 1024, 443 in this case, you need ‘sudo’ to get your OS to accept the binding of the port

The solution for me was to make sure the root user had access to the .kube/config file of my normal user. I did this via the environment variable KUBECONFIG:

1. Open a root shell

sudo su

2. Export the KUBECONFIG with a path to my regular users .kube/config

export KUBECONFIG=/home/niklas/.kube/config

3. Do the port-forward to port 443 (or anything else that needs root access)

kubectl port-forward -n ingress-nginx service/ingress-nginx-controller 443:443

I wasn’t looking for a permanent solution so this worked for the few tests I needed to do while setting up my Ingress for mTLS authentication

Tested on ‘kubectl’ 1.26, WSL2 with Ubuntu 20.08 and Kubernetes v1.26 on Minikube

Mutual TLS (mTLS) is a good way to secure your sensitive information when it travels over the Internet. One draw-back is that certificates needs to be renewed every now and then and if you have many applications using the same certificate chain, eg. a company with many micro services that handle sensitive information, you often find yourself needing to change the key store in many applications every time the certificate reaches its expiry. One way to handle this in a Kubernetes environment is to have all the micro services using the same key store via a Secrets or ConfigMap object.

Here is how to set it up:
1. Create a Secret (or ConfigMap) with the key stores you need (I’ve also added a trust store here):

kubectl create secret generic shared-trust-and-key-stores --from-file=keystore.p12 --from-file=truststore.jks

2. (Optional) Create a Secret to hold the pass phrases for the key stores

kubectl create secret generic shared-trust-and-key-store-credentials --from-literal=truststore_password=secret1 --from-literal=key_password=secret2 --from-literal=keystore_password=secret3

3. For every application setup a volume and mount the Secret (or ConfigMap) into that volume:

...
containers:
  - name: mypod
    image: myimage
    volumeMounts:
    - name: shared-keystores
      mountPath: "/etc/ssl"
  volumes:
  - name: shared-keystores
    secret:
      secretName: shared-trust-and-key-stores
...

4. (Optional) Map the pass phrase Secret as environment variables in the pod

...
containers:
  - name: mypod
    image: myimage
    env:
    - name: TRUSTSTORE_PASSWORD
      valueFrom:
        secretKeyRef:
          name: shared-trust-and-key-store-credentials
          key: truststore_password
    - name: KEY_PASSWORD
      valueFrom:
        secretKeyRef:
          name: shared-trust-and-key-store-credentials
          key: key_password
    - name: KEYSTORE_PASSWORD
      valueFrom:
        secretKeyRef:
          name: shared-trust-and-key-store-credentials
          key: keystore_password
...

Now in our application all we have to do is to point it to /etc/ssl for our key stores
* key store: /etc/ssl/keystore.p12
* trust store: /etc/ssl/truststore.jks

and if you are using the shared-trust-and-key-stores-credetials you will find the pass phrases as environment variables called:
* KEY_PASSWORD
* KEYSTORE_PASSWORD
* TRUSTSTORE_PASSWORD

When the time comes for renewing the certificates you only have to change in one place

Tested on WMVare Tansu v1.23.8

Here is how I set up a Camel-K installation in VMware Tansu with a Harbor registry.

1. Log into Harbor
2. Got to your project
   
3. Create a Robot Account with both push and pull permissions (you might need Admin permissions in the project for this)
   
4. Copy the JWT at the end of the creation process
   
5. Log into VMware Tansu CLI
6. Create a secret with that JWT token

   kubectl create secret docker-registry camel-k-stage --docker-server=<Harbor adress> --docker-username="robot\$camel-k-stage" --docker-password='<JWT token>'

7. Install Camel-K Operator

   kamel install --registry <Harbor adress> --organization <Harbor project name> --registry-secret camel-k-stage

8. Your Camel-K operator is now ready for use

Tested on Harbor v2.0 and VMware Tansu Kubernetes v1.22