Services and ports
Services can be placed in two groups based on the network interface they bind to. Services binding to the
localhost interface are only available from within the host. Services binding to the default host interface are available from outside the host and thus are subject to access restrictions.
Services binding to the default Host interface
|16443||API server||SSL encrypted. Clients need to present a valid password from a Static Password File.|
|10250||kubelet||Anonymous authentication is disabled. X509 client certificate is required.|
|10255||kubelet||Read only port for the Kubelet.|
|25000||cluster-agent||Proper token required to authorise actions.|
|12379||etcd||SSL encrypted. Client certificates required to connect.|
|10257||kube-controller||Serve HTTPS with authentication and authorization.|
|10259||kube-scheduler||Serve HTTPS with authentication and authorization.|
|19001||dqlite||SSL encrypted. Client certificates required to connect.|
Services binding to the localhost interface
|10248||kubelet||Localhost healthz endpoint.|
|10249||kube-proxy||Port for the metrics server to serve on.|
|10251||kube-schedule||Port on which to serve HTTP insecurely.|
|10252||kube-controller||Port on which to serve HTTP insecurely.|
|10256||kube-proxy||Port to bind the health check server.|
|2380||etcd||Used for peer connections.|
Containerd and etcd
Both these services are exposed through unix sockets.
Authentication and authorization
Upon deployment MicroK8s creates a Certificate Authority, a signed server certificate and a service account key file. These files are stored under
/var/snap/microk8s/current/certs/. Kubelet and the API server are aware of the same CA and so the signed server certificate is used by the API server to authenticate with kubelet (
Initially the server certificates will be issued for:
- localhost and all the ip addresses avaliable on the machine, typically it’s LAN address
- various mDNS addresses, such as kubernetes.default and kubernetes.default.svc.cluster.local
This will only allow Kubectl to access the API server locally, to access it through the internet and a real domain name you must add it to the file
/var/snap/microk8s/current/certs/csr.conf.template, for example:
[ alt_names ] DNS.1 = kubernetes DNS.2 = kubernetes.default DNS.3 = kubernetes.default.svc DNS.4 = kubernetes.default.svc.cluster DNS.5 = kubernetes.default.svc.cluster.local DNS.6 = mydomain.com
After changing, the
apiserver-kicker will automatically detect the difference, generate new certs and restart the apiserver. Your DNS server settings and
kubeconfig file must be updated appropriately.
Clients talking to the secure port of the API server (
16443), such as the Kubectl command line utility, have to be aware of the CA (
certificate-authority-data in user kubeconfig).
The authentication strategies enabled by default are:
- Static Token File with tokens in
- X509 Client Certs with the client CA file set to
Prior to version 1.19, the following strategy is also available:
- Static Password File with password tokens and usernames stored in
/var/snap/microk8s/current/credentials/ you can find the
client.config kubeconfig file used by
By default all authenticated requests are authorized as the api-server runs with
--authorization-mode=AlwaysAllow. Turning on RBAC is done through
microk8s enable rbac.
- Authentication strategies
- Role-based access control (RBAC)
Last updated 9 hours ago.