Ssl communication between kubernetes services

Linkerd General Discussion
1

Hello, after asissting Kubecon2024 I started som PoC with linkerd. I’ll explain my use case quickly. I have one namespace. Users have a kiosk application inside this environment. That kiosk has a browser (firefox), so they can use some application inside the namespace. For security reasons the only entrypoint for the applications is via the kiosk application. The kiosk must reach a nextcloud application with the domain https nextcloud.company . com. The kiosk pod already has a way to understand “where is” https:// nextcloud. company . com via ‘HostAliases’ configuration in the deployment. I’m injecting the certificates using nginx-proxy containers with the certifcates of “* company . com*” . I have another service that must communicate using https from the nextcloud deployment to the onlyoffice deployment, The nextcloud deployment needs to reach https onlyoffice . company . com and viceversa. The thing is that I need to inject the hostaliases for services to provide the nginx-proxy/certificates to be able to use the services and the communication between services, The consequense of adding this injection of nginx-proxy containers and host aliases everywhere. I installed linkerd that provides the mutualTLS feature but I don’t know how to use it and I don’t know if linkerd will help me to avoid nginx-proxy/certifcates injection, if linkerd will help me only to identify communication and secure communication between pods but not “the user communication itself”. Again this is an airgapped namespace users can only reach the kiosks, applications can’t reach Ingress outside the cluster. So far the deployments works fine with this manual injection but I want to deploy this using some automation and avoiding manual intervention. Thanks in advance

2

Good questions @jonathan.hernandez . I have a few questions re: the setup if you don’t mind elaborating when you get a chance:

  1. Are nextcloud and onlyoffice both in the same cluster where the Kiosk pop is and running as containerized apps?
  2. How are you currently separating and segregating users for RBAC/security purposes if they’re all dumped into the same entrypoint namespace?
  3. Do you need the browser communication also to be secured between the kiosk and nextcloud app via Linkerd (i.e., the browser will have to trust the Linkerd-issued self-signed certs)?
3

Hello Alen, thank you for the quick response.

  1. Yes. nextcloud is a deployment from a helm chart. onlyoffice is a deployment from a helm chart and kiosk app is a deployment from a helm chart as well. All of them are deployed in the same namespace, lets call it nextcloud.

  2. Users are using novnc service/route provided by the kiosk helm chart. For example user jonathan has a deployment/route. User alen has a different deployment/route, everything is handled by helm charts and values. I’m creating the credentials in the Admin interface from nextcloud deployment. We are not using yet RBAC/security purposes. If I run the command: helm list -n nextcloud, it looks like:
    helm list -n nextcloud
    NAME NAMESPACE REVISION UPDATED STATUS CHART APP VERSION
    documentserver nextcloud 4 2024-02-28 20:06:16.001145 +0400 +04 deployed docs-4.0.0 8.0.0
    k-admin nextcloud 1 2024-02-28 19:52:50.024364 +0400 +04 deployed kiosk-desktop-0.1.0 1.0
    k1 nextcloud 1 2024-02-28 20:18:57.693275 +0400 +04 deployed kiosk-desktop-0.1.0 1.0
    k2 nextcloud 1 2024-02-28 20:19:25.675984 +0400 +04 deployed kiosk-desktop-0.1.0 1.0
    k3 nextcloud 1 2024-02-28 20:19:30.866672 +0400 +04 deployed kiosk-desktop-0.1.0 1.0
    k4 nextcloud 1 2024-02-28 20:19:50.285124 +0400 +04 deployed kiosk-desktop-0.1.0 1.0
    k5 nextcloud 1 2024-02-28 20:20:29.933621 +0400 +04 deployed kiosk-desktop-0.1.0 1.0
    k6 nextcloud 1 2024-02-28 20:20:35.212377 +0400 +04 deployed kiosk-desktop-0.1.0 1.0
    k8 nextcloud 1 2024-02-28 20:20:59.186621 +0400 +04 deployed kiosk-desktop-0.1.0 1.0
    nextcloud nextcloud 1 2024-02-28 15:25:29.355075 +0400 +04 deployed nextcloud-4.5.10 28.0.1
    Each k-* represents a user in the kiosk.

  3. Users enters via route/url their own kiosk like https:// kiosk-789c18 . company . com . As I mentioned each user has a different route with a different “token” kiosk-85533e, kiosk-24XXXX, that is hanldled by the values on the kiosk helm chart.
    After the user enters to the kios. It has access to a firefox browser. The user puts https:// nextcloud . company . com in the browser so the user can interact with the application. If in your own browser (no kiosk) you try to reach that url (https:// nextcloud . company. com ) is not reachable because is the nextcloud service is not exposed as a route. Is exposed via nginx-proxy inside the nextcloud namespace. The only service reachable by route is the one from the kiosks.
    The services nextcloud and onlyoffice, they need to talk with each other in the same namespace. I’m doing a trick to use hostAliases to redirect every service to its own nginx-proxy. So I have two nginx proxies. one for nextcloud, the other one for onlyoffice. both are https. This is an example of the nginx-proxy configmap
    apiVersion: v1
    kind: ConfigMap
    metadata:
    name: nginx-config-office
    data:
    nginx.conf: |
    server {
    listen 443 ssl;
    server_name nextcloud-office. company . com;
    ssl_certificate /etc/nginx/certs/tls.crt;
    ssl_certificate_key /etc/nginx/certs/tls.key;
    client_max_body_size 10G;
    location / {
    proxy_pass http:// onlyoffice .nextcloud. svc. cluster. local: 8888;
    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto $scheme;

         # WebSocket support
     proxy_http_version 1.1;
     proxy_set_header Upgrade $http_upgrade;
     proxy_set_header Connection "upgrade";
 }

    }

I’m separating the urls because posting here only allows me to put two urls :sweat_smile: