Secure Kubernetes API allowing Gitlab integration

1
votes

I'd like to configure Kubernetes on a private machine to play around with Gitlab CI/CD tools. The purpose is merely experimenting with Gitlab for a few days.

Using this setup for production is out of question. I'd like your help to secure Kubernetes API. I don't need an hacker-proof solution, but at least I'd like the API not to be exposed to even naive malicious user. The machine is connected to a dedicated network so I can't imagine anything to be hacked other than an old just-reset machine which will be shutdown in a few days.

So far I have been able to setup Minikube, create a kube proxy and expose it to Gitlab. The integration has been successful.

However, I noticed that the Kubernetes API are exposed to anyone. For instance anyone can access https://my-ip.com:port/api/v1/namespaces/default/pods . How should I secure the APIs so that gitlab can connect to the cluster (following this method) but no one else without certificate nor token can access the cluster? I setup Gitlab with the CA Certificate and the Service Token but I guess it wouldn't have been needed since the Kubernetes API look public.

1
apisecuritykubernetesproxygitlab-ci
How about using iptables to allow only gitlab IP to access the api? - Marek Puchalski
Do you think Gitlab would use always the same IP from the connection to my cluster? I found online that the IP should be 172.65.251.78. I tried to expose the API using kubectl proxy --address=0.0.0.0 --accept-hosts="172\.65\.251\.78" but gitlab does not have access to them. Also, this way wound't other people be able to connect to my cluster through gitlab? - user1315621
There is most probably a range of IPs, not only one, you would need to take into account. And yes, people could connect to you if they had access to the gitlab servers. On the other hands you would eliminate all the crawlers making you invisible from automated scanners. - Marek Puchalski

1 Answers

0
votes

You don't have to use kube-proxy to expose the cluster. You should read Accessing services running on the cluster which is mentioning way of how to connect to cluster.

Access services through public IPs.

  • Use a service with type NodePort or LoadBalancer to make the service reachable outside the cluster. See the services and kubectl expose documentation.
  • Depending on your cluster environment, this may just expose the service to your corporate network, or it may expose it to the internet. Think about whether the service being exposed is secure. Does it do its own authentication?
  • Place pods behind services. To access one specific pod from a set of replicas, such as for debugging, place a unique label on the pod and create a new service which selects this label.
  • In most cases, it should not be necessary for application developer to directly access nodes via their nodeIPs.

Access services, nodes, or pods using the Proxy Verb.

  • Does apiserver authentication and authorization prior to accessing the remote service. Use this if the services are not secure enough to expose to the internet, or to gain access to ports on the node IP, or for debugging.
  • Proxies may cause problems for some web applications.
  • Only works for HTTP/HTTPS.
  • Described here.

Access from a node or pod in the cluster.

  • Run a pod, and then connect to a shell in it using kubectl exec. Connect to other nodes, pods, and services from that shell.
  • Some clusters may allow you to ssh to a node in the cluster. From there you may be able to access cluster services. This is a non-standard method, and will work on some clusters but not others. Browsers and other tools may or may not be installed. Cluster DNS may not work.

I also recommend reading Kubernetes Security 101: Risks and 29 Best Practices and Securely configure the Kubernetes API server.

For example change default namespace and use different namespaces to isolate applications. Use TLS and enable RBAC.