FaktorZ uses a single admission chain for Kubernetes and FaktorZ
resources. This changed from
and before where we had separate admission chains. This means that the top-level
admissionConfig.pluginConfig element can now contain the admission plug-in
configuration, which used to be contained in
kubernetesMasterConfig.admissionConfig.pluginConfig should be moved and
Also, starting in
all the supported admission plug-ins are ordered in the single chain for you.
You should no longer set
admissionConfig.pluginOrderOverride or the
kubernetesMasterConfig.admissionConfig.pluginOrderOverride. Instead, you
should enable plug-ins that are off by default by either adding their
plug-in-specific configuration, or adding a
disable: false (2)
||Admission plug-in name.
||Indicates that a plug-in should be enabled. It is optional and shown here only for reference.
disable to true will disable an admission plug-in that defaults to on.
Admission plug-ins are commonly used to help enforce security on the API server.
Be careful when disabling them.
If you were previously using
admissionConfig elements that cannot be safely
combined into a single admission chain, you will get a warning in your API
server logs and your API server will start with two separate admission chains
for legacy compatibility. Update your
admissionConfig to resolve the