SSH Access to Kuberenetes clusters for K8S Scans via UI.

[metahertz]

New feature motivation

It is best practice to not expose Kubernetes API endpoints directly to the internet.

Solution Proposed

A common access method for remote teams is to access via a SSH bastion using Public/Private keys.
The following example is from a recent CNCF hackathon run by ControlPlane, where teams were given access to the Kubernetes infra with the following SSH config:

Host bastion xx.xx.20.99
    Hostname xx.xx.20.99
    User player
    RequestTTY force
    ForwardAgent yes
    IdentityFile simulator_rsa
    UserKnownHostsFile simulator_known_hosts

In this example, all KubeCtl commands were run from the bastion terminal, but we could easily instead configure a port forward through the SSH tunnel allowing the prowler scanner to access the tunelled cluster through a modified kubeconfig.

Host bastion xx.xx.20.99
    Hostname xx.xx.20.99
    User bastion
    LocalForward 30001 customers.kubernetes.cluster:6443
    IdentityFile simulator_rsa
    UserKnownHostsFile simulator_known_hosts

With a Kubeconfig on the prowler side as follows:

apiVersion: v1
kind: Config
clusters:
- cluster:
    certificate-authority-data: <redacted>
    #OLD server: https://customers.kubernetes.cluster:6443
    server: https://127.0.0.1:30001

Describe alternatives you've considered

1. We could also offer an API endpoint with our infrastructure IP ranges, allowing users to programatically lock down their Kubernetes API endpoints to just those IP's used by the prowler SaaS infrastructure, similar to AWS's IP range JSON here: https://ip-ranges.amazonaws.com/ip-ranges.json
2. We could also offer popular software-defined-vpn endpoints to allow prowler SaaS to take part as an endpoint in the customers VPN, for example, a tailscale connector which would then allow the customer to give 'Prowlers' endpoint on their VPN access to their Kubernetes API.

Additional context

No response

[jfagoagas]

I think both ideas are great and covers different use cases regarding how the Kubernetes cluster is configured in terms of access:

1. Always works since only requires giving access to several CIDRs, also having a endpoint to get it would be great to import and have it always updated.
2. That'd require work for each VPN vendor but as a Tailscale supporter I'd love to have it!

[plejik]

I now service ( paralus ) where it generate config for k8s and then you deploy it on your k8s cluster , could it be an option as well ( k8s goes itself to prowler secure endpoint or some rabbit/sns/kafka and get command same way).
P.S ussually k8s has access to internel itself, and it could be easy way to firewall prowler endpoint that multiply k8s clusters

[NissesSenap]

What @plejik wrote. I, much rather have a cronjob running within the cluster.

If you want to support trigger a scan from the UI in the SaaS i guess you could also supply a deployment that runs within the cluster with an ingress that you can talk to from the SaaS solution.
But personally, I would just trigger the cronjob manually instead of having an extra ingress I have to care about.