what is this
The admission control admission controller is essentially a piece of code. In the process of requesting the kubernetes api, the sequence is to go through authentication & authorization first, perform the admission operation , and then operate the target object. This admission code is in the apiserver and must be compiled into the binary to be executed.
When a request is made to the cluster, each admission control code is executed in a certain order. If an admission control rejects the request, the result of the entire request will be returned immediately, and the user will be prompted with the corresponding error message.
In some cases, the admission logic may change the target object in order to adapt to the application's configuration. In addition, the admission logic also changes some of the relevant resources for the requested operation.
Why do you need it?
In kubernetes, the prerequisite for the normal operation of some advanced features is that some admission modules are in the enable state. To sum up, for kubernetes apiserver, if the admission control module is not properly configured, it cannot be called a complete server, and some functions will not take effect normally.
How to start an admission module
There is a parameter in kubernetes apiserver: admission_control, whose value is a string of ordered list of admission modules connected by commas. After setting, a certain sequence of admission module calls can be performed before the object is operated.
What does each admission module do
AlwaysAdmit
Green light for all requests.
AlwaysDeny
Turn on a red light for all requests, mostly used in test environments.
DenyExecOnPrivileged
It will intercept all requests to execute commands on the privileged container. If your cluster supports privileged containers and you want to restrict users from executing commands on these privileged containers, it is strongly recommended to use it.
ServiceAccount
This plug-in automates serviceAccounts and is highly recommended if you want to use ServiceAccount objects. The description about serviceAccount is as follows:
A serviceAccount adds the corresponding authentication information for the process running in the pod. When this plugin is enabled in the admission module (enabled by default), then when a pod is created or modified, it will do the following:
- If the pod does not have a serviceAccount attribute, set the pod's serviceAccount attribute to "default";
- Make sure pods always exist using de serviceAccount;
- If LimitSecretReferences is set to true, when the pod references the Secret object but not the ServiceAccount object, discard the pod;
- If the pod does not contain any ImagePullSecrets, the ImagePullSecrets of the serviceAccount are added to the pod;
- If MountServiceAccountToken is true, add a VolumeMount to the container in the pod.
SecurityContextDeny
This plugin will disable all options defined in pods that use the SecurityContext. Description of SecurityContext:
SecurityContext defines OS-level security settings (uid, gid, capabilities, SELinux, etc.) in the container.
ResourceQuota
It will watch all requests to ensure that the containers listed at the ResourceQuota object in the namespace have no exceptions. If the ResourceQuota object is used in kubernetes, this plugin must be used to constrain the container.
It is recommended that this plugin is the last one in the admission control parameter list.
LimitRanger
It will observe all requests to ensure that the defined constraints are not violated, which are defined in the LimitRange object in the namespace. If you use LimitRange objects in kubernetes, you must use this plugin.
NamespaceExists
It observes all requests, and if a request attempts to create a namespace that does not exist, the request is rejected.
Is there a recommended order of plugins?
have!
--admission_control=NamespaceLifecycle,NamespaceExists,LimitRanger,SecurityContextDeny,ServiceAccount,ResourceQuota
https://segmentfault.com/a/1190000002920092