LinkerD with Automatic certificate rotation on Ubuntu 22.04

Here are my findings about LinkerD Service Mesh and its mutual automatic TLS feature that encrypts communications between meshed Pods without any modification needed to them.

We'll start from a slightly (ok, severely) outdated K8S cluster to test the appropriate update procedure, too.

This article is meant as a work-in-progress.

References

Cert-Manager installation

[test0|default] ferdi@DESKTOP-NL6I2OD:~$ helm install \
  cert-manager jetstack/cert-manager \
  --namespace cert-manager \
  --create-namespace \
  --version v1.10.1 \
  --set installCRDs=true
NAME: cert-manager
LAST DEPLOYED: Fri Dec  9 09:39:17 2022
NAMESPACE: cert-manager
STATUS: deployed
REVISION: 1
TEST SUITE: None
NOTES:
cert-manager v1.10.1 has been deployed successfully!

In order to begin issuing certificates, you will need to set up a ClusterIssuer
or Issuer resource (for example, by creating a 'letsencrypt-staging' issuer).

More information on the different types of issuers and how to configure them
can be found in our documentation:

https://cert-manager.io/docs/configuration/

For information on how to configure cert-manager to automatically provision
Certificates for Ingress resources, take a look at the `ingress-shim`
documentation:

https://cert-manager.io/docs/usage/ingress/

Root CA certificate

We need a (long lasting) top-level certificate to serve as an origin for our mTLS certificates, so we'll create one ourselves with the aid of Step CLI.

Creation

[test0|default] ferdi@DESKTOP-NL6I2OD:~$ step certificate create root.linkerd.cluster.local ca.crt ca.key \
  --profile root-ca \
  --no-password \
  --insecure \
  --not-after=87600h
Your certificate has been saved in ca.crt.
Your private key has been saved in ca.key.

We're creating it with a 10-years validity, plenty of time to experiment!

Loading it to K8S

[test0|default] ferdi@DESKTOP-NL6I2OD:~$ kubectl create namespace linkerd
namespace/linkerd created
[test0|default] ferdi@DESKTOP-NL6I2OD:~$ kubectl create secret tls \
    linkerd-trust-anchor \
    --cert=ca.crt \
    --key=ca.key \
    --namespace=linkerd
secret/linkerd-trust-anchor created

We have created the linkerd namespace in advance, to be able to instruct Linkerd's Helm Chart to use the new certificate.

Hooking it up to Cert-Manager

We're going to need an Issuer resource, referencing our Secret

apiVersion: cert-manager.io/v1
kind: Issuer
metadata:
  name: linkerd-trust-anchor
  namespace: linkerd
spec:
  ca:
    secretName: linkerd-trust-anchor

And a Certificate generated by this Issuer

apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: linkerd-identity-issuer
  namespace: linkerd
spec:
  secretName: linkerd-identity-issuer
  duration: 48h
  renewBefore: 25h
  issuerRef:
    name: linkerd-trust-anchor
    kind: Issuer
  commonName: identity.linkerd.cluster.local
  dnsNames:
  - identity.linkerd.cluster.local
  isCA: true
  privateKey:
    algorithm: ECDSA
  usages:
  - cert sign
  - crl sign
  - server auth
  - client auth

After having applied these Custom Resources, the situation will be:

[test0|linkerd] ferdi@DESKTOP-NL6I2OD:~$ kubectl get secrets,issuers,certificates
NAME                             TYPE                                  DATA   AGE
secret/default-token-pbgcg       kubernetes.io/service-account-token   3      8m10s
secret/linkerd-identity-issuer   kubernetes.io/tls                     3      29s
secret/linkerd-trust-anchor      kubernetes.io/tls                     2      7m33s

NAME                                          READY   AGE
issuer.cert-manager.io/linkerd-trust-anchor   True    41s

NAME                                                  READY   SECRET                    AGE
certificate.cert-manager.io/linkerd-identity-issuer   True    linkerd-identity-issuer   29s

LinkerD

First of all, we'll need the CRDs

First installation

[test0|linkerd] ferdi@DESKTOP-NL6I2OD:~$ helm install linkerd-crds -n linkerd --create-namespace linkerd/linkerd-crds
NAME: linkerd-crds
LAST DEPLOYED: Fri Dec  9 10:08:26 2022
NAMESPACE: linkerd
STATUS: deployed
REVISION: 1
TEST SUITE: None
NOTES:
The linkerd-crds chart was successfully installed 🎉

To complete the linkerd core installation, please now proceed to install the
linkerd-control-plane chart in the linkerd namespace.

Looking for more? Visit https://linkerd.io/2/getting-started/

Then LinkerD itself, within the already present Namespace

[test0|linkerd] ferdi@DESKTOP-NL6I2OD:~$ helm install linkerd-control-plane -n linkerd \
  --set-file identityTrustAnchorsPEM=ca.crt \
  --set identity.issuer.scheme=kubernetes.io/tls \
  linkerd/linkerd-control-plane
NAME: linkerd-control-plane
LAST DEPLOYED: Fri Dec  9 10:09:58 2022
NAMESPACE: linkerd
STATUS: deployed
REVISION: 1
TEST SUITE: None
NOTES:
The Linkerd control plane was successfully installed 🎉

To help you manage your Linkerd service mesh you can install the Linkerd CLI by running:

  curl -sL https://run.linkerd.io/install | sh

Alternatively, you can download the CLI directly via the Linkerd releases page:

  https://github.com/linkerd/linkerd2/releases/

To make sure everything works as expected, run the following:

  linkerd check

The viz extension can be installed by running:

  helm install linkerd-viz linkerd/linkerd-viz

Looking for more? Visit https://linkerd.io/2/getting-started/

Course correction

My single-host K8S test cluster is running on top of Ubuntu 22.04, using Rancher (now SuSE) RKE1 Kubernetes distribution.

This simple fact lead me to this dire situation, after having installed the Helm Chart as shown above.

[test0|linkerd] ferdi@DESKTOP-NL6I2OD:~$ kubectl get po
NAME                                      READY   STATUS                  RESTARTS   AGE
linkerd-destination-54bc79696d-xcw7f      0/4     Init:CrashLoopBackOff   7          14m
linkerd-identity-76578bd5b9-68vrc         0/2     Init:CrashLoopBackOff   7          14m
linkerd-proxy-injector-746646f874-j45l4   0/2     Init:CrashLoopBackOff   7          14m

Let's check what's wrong with all of them!

test0|linkerd] ferdi@DESKTOP-NL6I2OD:~$ kubectl describe po linkerd-identity-76578bd5b9-68vrc|grep Message
      Message:   2-12-09T09:21:28Z" level=info msg="iptables-save v1.8.8 (legacy): Cannot initialize: Permission denied (you must be root)\n\n"
  Type     Reason     Age                   From               Message
[test0|linkerd] ferdi@DESKTOP-NL6I2OD:~$ kubectl describe po linkerd-destination-54bc79696d-xcw7f|grep Message
      Message:   2-12-09T09:21:15Z" level=info msg="iptables-save v1.8.8 (legacy): Cannot initialize: Permission denied (you must be root)\n\n"
  Type     Reason     Age                From               Message

There's a reference to this error, at the thread's bottom there is a suggestion about an Helm Chart parameter that could save the day.

[test0|linkerd] ferdi@DESKTOP-NL6I2OD:~$ helm upgrade --install linkerd-control-plane -n linkerd \
  --set-file identityTrustAnchorsPEM=ca.crt \
  --set identity.issuer.scheme=kubernetes.io/tls \
  --set "proxyInit.iptablesMode=nft" \
  linkerd/linkerd-control-plane
Release "linkerd-control-plane" has been upgraded. Happy Helming!
NAME: linkerd-control-plane
LAST DEPLOYED: Fri Dec  9 10:33:13 2022
NAMESPACE: linkerd
STATUS: deployed
REVISION: 2
TEST SUITE: None
NOTES:
The Linkerd control plane was successfully installed 🎉

To help you manage your Linkerd service mesh you can install the Linkerd CLI by running:

  curl -sL https://run.linkerd.io/install | sh

Alternatively, you can download the CLI directly via the Linkerd releases page:

  https://github.com/linkerd/linkerd2/releases/

To make sure everything works as expected, run the following:

  linkerd check

The viz extension can be installed by running:

  helm install linkerd-viz linkerd/linkerd-viz

Looking for more? Visit https://linkerd.io/2/getting-started/

Unfortunately, it didn'help a lot, below you'll find the relevant excerpt of kubectl describe pod

      Reason:    Error
      Message:   ave v1.8.8 (nf_tables): Could not fetch rule set generation id: Permission denied (you must be root)\n\n"
time="2022-12-09T09:43:09Z" level=error msg="aborting firewall configuration"
Error: exit status 4

Serious troubleshooting here

Ok, let's check the default values of the Helm Chart to find out something that could help us.

[test0|linkerd] ferdi@DESKTOP-NL6I2OD:~$ helm show values linkerd/linkerd-control-plane > linkerd-values.yml
[test0|linkerd] ferdi@DESKTOP-NL6I2OD:~$

Here's the relevant section:

# proxy-init configuration
proxyInit:
  # -- Variant of iptables that will be used to configure routing. Currently,
  # proxy-init can be run either in 'nft' or in 'legacy' mode. The mode will
  # control which utility binary will be called. The host must support
  # whichever mode will be used
  iptablesMode: "legacy"
  # -- Default set of inbound ports to skip via iptables
  # - Galera (4567,4568)
  ignoreInboundPorts: "4567,4568"
  # -- Default set of outbound ports to skip via iptables
  # - Galera (4567,4568)
  ignoreOutboundPorts: "4567,4568"
  # -- Comma-separated list of subnets in valid CIDR format that should be skipped by the proxy
  skipSubnets: ""
  # -- Log level for the proxy-init
  # @default -- info
  logLevel: ""
  # -- Log format (`plain` or `json`) for the proxy-init
  # @default -- plain
  logFormat: ""
  image:
    # -- Docker image for the proxy-init container
    name: cr.l5d.io/linkerd/proxy-init
    # -- Pull policy for the proxy-init container Docker image
    # @default -- imagePullPolicy
    pullPolicy: ""
    # -- Tag for the proxy-init container Docker image
    version: v2.0.0
  resources:
    cpu:
      # -- Maximum amount of CPU units that the proxy-init container can use
      limit: 100m
      # -- Amount of CPU units that the proxy-init container requests
      request: 100m
    memory:
      # -- Maximum amount of memory that the proxy-init container can use
      limit: 20Mi
      # -- Amount of memory that the proxy-init container requests
      request: 20Mi
    ephemeral-storage:
      # -- Maximum amount of ephemeral storage that the proxy-init container can use
      limit: ""
      # -- Amount of ephemeral storage that the proxy-init container requests
      request: ""
  closeWaitTimeoutSecs: 0
  # -- Allow overriding the runAsNonRoot behaviour (<https://github.com/linkerd/linkerd2/issues/7308>)
  runAsRoot: false
  # -- This value is used only if runAsRoot is false; otherwise runAsUser will be 0
  runAsUser: 65534
  xtMountPath:
    mountPath: /run
    name: linkerd-proxy-init-xtables-lock

Let's go with the plain old brute-force approach (running it as root user, in this case)/

[test0|linkerd] ferdi@DESKTOP-NL6I2OD:~$ helm upgrade --install linkerd-control-plane -n linkerd \
  --set-file identityTrustAnchorsPEM=ca.crt \
  --set identity.issuer.scheme=kubernetes.io/tls \
  --set "proxyInit.iptablesMode=nft" \
  --set "proxyInit.runAsRoot=true" \
  linkerd/linkerd-control-plane
Release "linkerd-control-plane" does not exist. Installing it now.

Aaand... we did it! Everything's running!

[test0|linkerd] ferdi@DESKTOP-NL6I2OD:~$ kubectl get po
NAME                                      READY   STATUS    RESTARTS   AGE
linkerd-destination-7f5857f549-xsdjf      4/4     Running   0          79s
linkerd-identity-b7d47f674-2mrsm          2/2     Running   0          79s
linkerd-proxy-injector-5c5f849755-4xrz7   2/2     Running   0          79s
[test0|linkerd] ferdi@DESKTOP-NL6I2OD:~$ 
[test0|linkerd] ferdi@DESKTOP-NL6I2OD:~$ 
[test0|linkerd] ferdi@DESKTOP-NL6I2OD:~$ linkerd check
Linkerd core checks
===================

kubernetes-api
--------------
√ can initialize the client
√ can query the Kubernetes API

kubernetes-version
------------------
√ is running the minimum Kubernetes API version
√ is running the minimum kubectl version

linkerd-existence
-----------------
√ 'linkerd-config' config map exists
√ heartbeat ServiceAccount exist
√ control plane replica sets are ready
√ no unschedulable pods
√ control plane pods are ready
√ cluster networks contains all node podCIDRs
√ cluster networks contains all pods
√ cluster networks contains all services

linkerd-config
--------------
√ control plane Namespace exists
√ control plane ClusterRoles exist
√ control plane ClusterRoleBindings exist
√ control plane ServiceAccounts exist
√ control plane CustomResourceDefinitions exist
√ control plane MutatingWebhookConfigurations exist
√ control plane ValidatingWebhookConfigurations exist
√ proxy-init container runs as root user if docker container runtime is used

linkerd-identity
----------------
√ certificate config is valid
√ trust anchors are using supported crypto algorithm
√ trust anchors are within their validity period
√ trust anchors are valid for at least 60 days
√ issuer cert is using supported crypto algorithm
√ issuer cert is within its validity period
‼ issuer cert is valid for at least 60 days
    issuer certificate will expire on 2022-12-11T09:04:05Z
    see https://linkerd.io/2.12/checks/#l5d-identity-issuer-cert-not-expiring-soon for hints
√ issuer cert is issued by the trust anchor

linkerd-webhooks-and-apisvc-tls
-------------------------------
√ proxy-injector webhook has valid cert
√ proxy-injector cert is valid for at least 60 days
√ sp-validator webhook has valid cert
√ sp-validator cert is valid for at least 60 days
√ policy-validator webhook has valid cert
√ policy-validator cert is valid for at least 60 days

linkerd-version
---------------
√ can determine the latest version
√ cli is up-to-date

control-plane-version
---------------------
√ can retrieve the control plane version
√ control plane is up-to-date
√ control plane and cli versions match

linkerd-control-plane-proxy
---------------------------
√ control plane proxies are healthy
√ control plane proxies are up-to-date
√ control plane proxies and cli versions match

Status check results are √

Experiments with LinkerD

Protocols

Here you'll find a detailed explanation of the proxying capabilities of LinkerD, I'm quoting some excerpt

Linkerd is capable of proxying all TCP traffic, including TLS connections, WebSockets, and HTTP tunneling.

In most cases, Linkerd can do this without configuration. To accomplish this, Linkerd performs protocol detection to determine whether traffic is HTTP or HTTP/2 (including gRPC). If Linkerd detects that a connection is HTTP or HTTP/2, Linkerd automatically provides HTTP-level metrics and routing.

If Linkerd cannot determine that a connection is using HTTP or HTTP/2, Linkerd will proxy the connection as a plain TCP connection, applying mTLS and providing byte-level metrics as usual.

(Note that HTTPS calls to or from meshed pods are treated as TCP, not as HTTP. Because the client initiates the TLS connection, Linkerd is not be able to decrypt the connection to observe the HTTP transactions.)

Linkerd maintains a default list of opaque ports that corresponds to the standard ports used by protocols that interact poorly with protocol detection. As of the 2.12 release, that list is: 25 (SMTP), 587 (SMTP), 3306 (MySQL), 4444 (Galera), 5432 (Postgres), 6379 (Redis), 9300 (ElasticSearch), and 11211 (Memcache).

The following table contains common protocols that may require additional configuration.

Protocol	Standard port(s)	In default list?	Notes
SMTP	25, 587	Yes
MySQL	3306	Yes
PostgreSQL	5432	Yes
Redis	6379	Yes
ElasticSearch	9300	Yes
Memcache	11211	Yes
MySQL with Galera	3306, 4444, 4567, 4568	Partially	Ports 4567 and 4568 are not in Linkerd’s default set of opaque ports

Using LinkerD to secure the traffic

Here, as usual, there are some references

Enabling default-deny firewall policy

Let's upgrade again our LinkerD Helm Chart configuration:

[test0|linkerd] ferdi@DESKTOP-NL6I2OD:~$ helm upgrade --install linkerd-control-plane \
  --namespace linkerd \
  --set-file identityTrustAnchorsPEM=ca.crt \
  --set identity.issuer.scheme=kubernetes.io/tls \
  --set "proxyInit.iptablesMode=nft" \
  --set "proxyInit.runAsRoot=true" \
  --set "proxy.defaultInboundPolicy=deny" \
  linkerd/linkerd-control-plane

This way, we ensure that LinkerD-meshed Pods could only be contacted by predetermined entities

Test deployments

We're going to use custom ServiceAccounts for each Deployment (it's a requirement to identify the client side) and we'll show two different ways to select the server side of the allowed connection.

# File: whoami.yml
---
apiVersion: v1
kind: ServiceAccount
metadata:
  name: whoami1
  namespace: default
---
apiVersion: v1
kind: ServiceAccount
metadata:
  name: whoami2
  namespace: default
---
apiVersion: v1
kind: ServiceAccount
metadata:
  name: whoami3
  namespace: default
---
apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: whoami1
  name: whoami1
  namespace: default
spec:
  replicas: 1
  selector:
    matchLabels:
      app: whoami1
  template:
    metadata:
      labels:
        app: whoami1
    spec:
      automountServiceAccountToken: false
      containers:
      - image: containous/whoami
        imagePullPolicy: Always
        name: whoami
        ports:
        - containerPort: 80
          protocol: TCP
        resources: {}
      - args:
        - -c
        - sleep 999999999
        command:
        - /bin/bash
        image: nicolaka/netshoot
        imagePullPolicy: Always
        name: netshoot
        resources: {}
      serviceAccount: whoami1
      serviceAccountName: whoami1
---
apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: whoami2
  name: whoami2
  namespace: default
spec:
  replicas: 1
  selector:
    matchLabels:
      app: whoami2
  template:
    metadata:
      labels:
        app: whoami2
    spec:
      automountServiceAccountToken: false
      containers:
      - image: containous/whoami
        imagePullPolicy: Always
        name: whoami
        ports:
        - containerPort: 80
          protocol: TCP
      - args:
        - -c
        - sleep 999999999
        command:
        - /bin/bash
        image: nicolaka/netshoot
        imagePullPolicy: Always
        name: netshoot
      serviceAccount: whoami2
      serviceAccountName: whoami2
---
apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: whoami3
  name: whoami3
  namespace: default
spec:
  replicas: 1
  selector:
    matchLabels:
      app: whoami3
  template:
    metadata:
      labels:
        app: whoami3
    spec:
      automountServiceAccountToken: false
      containers:
      - image: containous/whoami
        imagePullPolicy: Always
        name: whoami
        ports:
        - containerPort: 80
          protocol: TCP
      - args:
        - -c
        - sleep 999999999
        command:
        - /bin/bash
        image: nicolaka/netshoot
        imagePullPolicy: Always
        name: netshoot
      serviceAccount: whoami3
      serviceAccountName: whoami3
---
apiVersion: v1
kind: Service
metadata:
  labels:
    app: whoami1
  name: whoami1
  namespace: default
spec:
  ipFamilies:
  - IPv4
  ipFamilyPolicy: SingleStack
  ports:
  - port: 80
    protocol: TCP
    targetPort: 80
  selector:
    app: whoami1
  sessionAffinity: None
  type: ClusterIP
---
apiVersion: v1
kind: Service
metadata:
  labels:
    app: whoami2
  name: whoami2
  namespace: default
spec:
  ipFamilies:
  - IPv4
  ipFamilyPolicy: SingleStack
  ports:
  - port: 80
    protocol: TCP
    targetPort: 80
  selector:
    app: whoami2
  sessionAffinity: None
  type: ClusterIP
---
apiVersion: v1
kind: Service
metadata:
  labels:
    app: whoami3
  name: whoami3
  namespace: default
spec:
  ipFamilies:
  - IPv4
  ipFamilyPolicy: SingleStack
  ports:
  - port: 80
    protocol: TCP
    targetPort: 80
  selector:
    app: whoami3
  sessionAffinity: None
  type: ClusterIP

LinkerD-izing deployments

The deployments defined above haven't been LinkerD-ized yet! Let's use linkerd CLI tool to produce an edited version of the same YAML.

[test0|default] ferdi@DESKTOP-NL6I2OD:~/linkerdtest$ cat whoami.yml | linkerd inject - | tee whoami-injected.yml

Below there's an excerpt of the new YAML, detailing one of the updated Deployments:

---
apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: whoami1
  name: whoami1
  namespace: default
spec:
  replicas: 1
  selector:
    matchLabels:
      app: whoami1
  template:
    metadata:
      annotations:
        linkerd.io/inject: enabled
      labels:
        app: whoami1
    spec:
      automountServiceAccountToken: false
      containers:
      - image: containous/whoami
        imagePullPolicy: Always
        name: whoami
        ports:
        - containerPort: 80
          protocol: TCP
      - args:
        - -c
        - sleep 999999999
        command:
        - /bin/bash
        image: nicolaka/netshoot
        imagePullPolicy: Always
        name: netshoot
      serviceAccount: whoami1
      serviceAccountName: whoami1

Definining rules

We're going to define the firewall rules (LinkerD calls them ServerAuthorizations) first, and only after that, the corresponding targets (Servers for LinkerD).

This way, we're sure that our defined rules will be applied instantly after the creation of the Server* custom resource.

Identifying the destination (Server) by resource name

---
apiVersion: policy.linkerd.io/v1beta1
kind: ServerAuthorization
metadata:
  namespace: default
  name: whoami2-whoami1-auth
  labels:
    app.kubernetes.io/part-of: whoami
    app.kubernetes.io/name: whoami2-whoami1
spec:
  # the Server whoami1 can be contacted by Pods running with whoami2 ServiceAccount
  server:
    name: whoami1-server
  client:
    meshTLS:
      serviceAccounts:
        - name: whoami2

Identifying the destination (Server) by resource label(s)

---
apiVersion: policy.linkerd.io/v1beta1
kind: ServerAuthorization
metadata:
  namespace: default
  name: whoami3-whoami1-auth
  labels:
    app.kubernetes.io/part-of: whoami
    app.kubernetes.io/name: whoami3-whoami1
spec:
  # the Server labeled app=whoami1 can be contacted by Pods running with whoami2 ServiceAccount
  server:
    selector:
      matchLabels:
        app: whoami1
  client:
    meshTLS:
      serviceAccounts:
        - name: whoami3

Defining the Server (connection destination)

---
apiVersion: policy.linkerd.io/v1beta1
kind: Server
metadata:
  namespace: default
  name: whoami1-server
  labels:
    app: whoami1
spec:
  podSelector:
    matchLabels:
      app: whoami1
  port: 80
  proxyProtocol: HTTP/1

Testing the ServerAuthorizations/Server combination

These are my currently running Pods, for reference

[test0|default] ferdi@DESKTOP-NL6I2OD:~/linkerdtest$ kubectl get po
NAME                       READY   STATUS    RESTARTS   AGE
whoami1-6cccb5f954-mjmgg   3/3     Running   0          3h
whoami2-689d97cf87-7p5s7   3/3     Running   0          3h
whoami3-7689d5fbc6-7n7l9   3/3     Running   0          3h

From whoami2's sidecar container

[test0|default] ferdi@DESKTOP-NL6I2OD:~/linkerdtest$ kubectl exec -ti whoami2-689d97cf87-7p5s7 -c netshoot -- bash
bash-5.2# curl -v http://whoami1/
*   Trying 10.43.253.230:80...
* Connected to whoami1 (10.43.253.230) port 80 (#0)
> GET / HTTP/1.1
> Host: whoami1
> User-Agent: curl/7.86.0
> Accept: */*
>
* Mark bundle as not supporting multiuse
< HTTP/1.1 200 OK
< date: Sat, 10 Dec 2022 14:45:01 GMT
< content-length: 299
< content-type: text/plain; charset=utf-8
<
Hostname: whoami1-6cccb5f954-mjmgg
IP: 127.0.0.1
IP: 10.42.0.31
RemoteAddr: 10.42.0.31:57388
GET / HTTP/1.1
Host: whoami1
User-Agent: curl/7.86.0
Accept: */*
L5d-Client-Id: whoami2.default.serviceaccount.identity.linkerd.cluster.local
L5d-Dst-Canonical: whoami1.default.svc.cluster.local:80

* Connection #0 to host whoami1 left intact
bash-5.2#

Yeah! It works!

From whoami3's sidecar container

[test0|default] ferdi@DESKTOP-NL6I2OD:~/linkerdtest$ kubectl exec -ti whoami3-7689d5fbc6-7n7l9 -c netshoot -- bash
bash-5.2# curl -v http://whoami1
*   Trying 10.43.253.230:80...
* Connected to whoami1 (10.43.253.230) port 80 (#0)
> GET / HTTP/1.1
> Host: whoami1
> User-Agent: curl/7.86.0
> Accept: */*
>
* Mark bundle as not supporting multiuse
< HTTP/1.1 200 OK
< date: Sat, 10 Dec 2022 14:46:24 GMT
< content-length: 299
< content-type: text/plain; charset=utf-8
<
Hostname: whoami1-6cccb5f954-mjmgg
IP: 127.0.0.1
IP: 10.42.0.31
RemoteAddr: 10.42.0.31:51432
GET / HTTP/1.1
Host: whoami1
User-Agent: curl/7.86.0
Accept: */*
L5d-Client-Id: whoami3.default.serviceaccount.identity.linkerd.cluster.local
L5d-Dst-Canonical: whoami1.default.svc.cluster.local:80

* Connection #0 to host whoami1 left intact
bash-5.2#

This one, too

A connection from an unauthorized resource, within the cluster

Whoo-hoo, I'm a bad guy trying to reach our precious whoami1

[test0|default] ferdi@DESKTOP-NL6I2OD:~/linkerdtest$ kubectl run badguy -ti --rm --image=nicolaka/netshoot -- bash
If you don't see a command prompt, try pressing enter.
bash-5.2# curl -v http://whoami1
*   Trying 10.43.253.230:80...
* Connected to whoami1 (10.43.253.230) port 80 (#0)
> GET / HTTP/1.1
> Host: whoami1
> User-Agent: curl/7.86.0
> Accept: */*
>
* Mark bundle as not supporting multiuse
< HTTP/1.1 403 Forbidden
< content-length: 0
< date: Sat, 10 Dec 2022 14:49:24 GMT
<
* Connection #0 to host whoami1 left intact
bash-5.2#

... and I miserably fail to connect!

Ferdinando Simonetti's personal pages

Other articles

HAProxy + KeyDB on AKS - take two

Getting default values for KeyDB's Helm chart

Using a Microsoft AKS cluster to test Keydb's resilience with Python clients

Monitoring and logging for Kubernetes via Beats -> ElasticSearch (ECK or Elastic Cloud managed service), visualization with Kibana

Other articles

Getting default values for KeyDB's Helm chart

links

social