Kubernetes 101 : Securing the Kubernetes cluster - security parameters for the API-Server -
When we start the API server, we have the option to use flags to add or modify certain behaviors.
We could check the flags or the parameter that our API server is using by displaying the API server process using the below command:
When we set the anonymous-auth=false parameter to false. It means that the denied accesses are not accepted as anonymous but they get rejected.
Basic authentication is an easy way of authenticating users with passwords that never change. If we don't use the --basic-auth-file with the API-server, that way of authentication is not used
To secure the kubelet that is running on all the nodes with HTTPS we could set the --kubelet-https parameter to true.
Profiling is like a verbose mode, it makes lot of system details available, if we don't want to use it we set the --profiling parameter to false so as not to make critical information readily available.
The --enable-admission-plugins parameter enables different admission plugins to control access to resources, access to storage, ...
The AlwaysAdmit plugin tells the API server accepts all the request and it should not be in the --enable-admission-plugins list.
The API server uses HTTPS to communicate with the kubelet.
Setting the --kubelet-certificate-authority, --kubelet-client-key, and the kubelet-client-key makes sure that the HTTPS communication uses valid certificates.
The AlwaysPullImages admission controller keeps pods from running local images that are on the host that may contain malicious code.
We disable it using the --disable-admission-plugins API server parameter.
The SecurityContextDeny admission controller makes sure that pods don't modify the SecurityContext to get a privileged access.
It is used in combination with the --disable-admission-plugins parameter.
Whe we use the "--audit-log-path file" parameter to log requests, the file needs to be secured.
The authorization controllers check if users have the proper authorization.
By default the --authorization-mode it is set to AlwaysAllow, for security reason it should not be the case. Other secure option are - AlwaysDeny, Webhook, RBAC, ... -
Remark:
The AlwaysAllow and the AlwaysDeny are usually used for testing purposes.
Tokens last forever, and after updating the list of tokens in a file, the API server needs to be restarted. We could use a file with tokens with the --token-auth-file parameter. Tokens are not the best way for authenticating users.
When the parameter --service-account-lookup is set to "true", it tells the API server to check whether the an account exists in the cluster's database - etcd -.
We could also enable the PodSecurityPolicy admission controller using the --enable-admission-plugins parameter.
The PodSecurityPolicy manages security parameter for the pods.
The --service-account-key-file parameter is used to check the ServiceAccount tokens.
For checking the requests sent to the etcd server we could use the --etcd-certfile and --etcd-keyfile parameters.
For securing comminications with the etcd server we could set the --etcd-cafile which allows API server connect to the etcd server using the SSL protocol.
The --tls-cipher-suites is used to define the cipher suites for the cluster.
The --tls-min-version tells the APi Server about the minimun TLS version supported.
Enabling auditindg could be turned on using the parameter --feature-gates and setting it to AdvancedAuditing=true.
- In the API server's unit file if the API server is running as a systemd service
- In the API server Yaml file if the API server is running as a pod
To check all the enabled admission controllers plugins, we could run the below command:
Comments