k3s/docs/design/admission_control.md

119 lines
4.1 KiB
Markdown
Raw Normal View History

2015-07-12 04:04:52 +00:00
<!-- BEGIN MUNGE: UNVERSIONED_WARNING -->
<!-- BEGIN STRIP_FOR_RELEASE -->
2015-07-16 17:02:26 +00:00
<img src="http://kubernetes.io/img/warning.png" alt="WARNING"
width="25" height="25">
<img src="http://kubernetes.io/img/warning.png" alt="WARNING"
width="25" height="25">
<img src="http://kubernetes.io/img/warning.png" alt="WARNING"
width="25" height="25">
<img src="http://kubernetes.io/img/warning.png" alt="WARNING"
width="25" height="25">
<img src="http://kubernetes.io/img/warning.png" alt="WARNING"
width="25" height="25">
<h2>PLEASE NOTE: This document applies to the HEAD of the source tree</h2>
If you are using a released version of Kubernetes, you should
refer to the docs that go with that version.
<strong>
2015-11-03 18:17:57 +00:00
The latest release of this document can be found
[here](http://releases.k8s.io/release-1.1/docs/design/admission_control.md).
2015-07-16 17:02:26 +00:00
Documentation for other releases can be found at
[releases.k8s.io](http://releases.k8s.io).
</strong>
--
2015-07-13 22:15:35 +00:00
2015-07-12 04:04:52 +00:00
<!-- END STRIP_FOR_RELEASE -->
<!-- END MUNGE: UNVERSIONED_WARNING -->
2015-07-17 22:35:41 +00:00
2014-11-19 15:17:12 +00:00
# Kubernetes Proposal - Admission Control
2015-02-20 15:44:02 +00:00
**Related PR:**
2014-11-19 15:17:12 +00:00
| Topic | Link |
| ----- | ---- |
| Separate validation from RESTStorage | http://issue.k8s.io/2977 |
2014-11-19 15:17:12 +00:00
## Background
High level goals:
* Enable an easy-to-use mechanism to provide admission control to cluster
* Enable a provider to support multiple admission control strategies or author their own
* Ensure any rejected request can propagate errors back to the caller with why the request failed
2014-12-15 19:32:32 +00:00
Authorization via policy is focused on answering if a user is authorized to perform an action.
2014-11-19 15:17:12 +00:00
Admission Control is focused on if the system will accept an authorized action.
2014-12-15 19:32:32 +00:00
Kubernetes may choose to dismiss an authorized action based on any number of admission control strategies.
2014-11-19 15:17:12 +00:00
2014-12-15 19:32:32 +00:00
This proposal documents the basic design, and describes how any number of admission control plug-ins could be injected.
2014-11-19 15:17:12 +00:00
2014-12-15 19:32:32 +00:00
Implementation of specific admission control strategies are handled in separate documents.
2014-11-19 15:17:12 +00:00
## kube-apiserver
The kube-apiserver takes the following OPTIONAL arguments to enable admission control
| Option | Behavior |
| ------ | -------- |
| admission-control | Comma-delimited, ordered list of admission control choices to invoke prior to modifying or deleting an object. |
| admission-control-config-file | File with admission control configuration parameters to boot-strap plug-in. |
2014-12-15 19:32:32 +00:00
An **AdmissionControl** plug-in is an implementation of the following interface:
2015-02-20 15:44:02 +00:00
```go
2014-12-15 19:32:32 +00:00
package admission
// Attributes is an interface used by a plug-in to make an admission decision on a individual request.
type Attributes interface {
GetNamespace() string
GetKind() string
GetOperation() string
GetObject() runtime.Object
}
// Interface is an abstract, pluggable interface for Admission Control decisions.
type Interface interface {
// Admit makes an admission decision based on the request attributes
// An error is returned if it denies the request.
Admit(a Attributes) (err error)
}
```
A **plug-in** must be compiled with the binary, and is registered as an available option by providing a name, and implementation
of admission.Interface.
2015-02-20 15:44:02 +00:00
```go
2014-12-15 19:32:32 +00:00
func init() {
2015-01-08 16:15:40 +00:00
admission.RegisterPlugin("AlwaysDeny", func(client client.Interface, config io.Reader) (admission.Interface, error) { return NewAlwaysDeny(), nil })
2014-12-15 19:32:32 +00:00
}
```
Invocation of admission control is handled by the **APIServer** and not individual **RESTStorage** implementations.
2015-08-04 06:00:48 +00:00
This design assumes that **Issue 297** is adopted, and as a consequence, the general framework of the APIServer request/response flow will ensure the following:
2014-12-15 19:32:32 +00:00
1. Incoming request
2. Authenticate user
3. Authorize user
2015-08-04 06:00:48 +00:00
4. If operation=create|update|delete|connect, then admission.Admit(requestAttributes)
- invoke each admission.Interface object in sequence
5. Case on the operation:
- If operation=create|update, then validate(object) and persist
- If operation=delete, delete the object
- If operation=connect, exec
2014-12-15 19:32:32 +00:00
If at any step, there is an error, the request is canceled.
2015-07-14 00:13:09 +00:00
<!-- BEGIN MUNGE: GENERATED_ANALYTICS -->
[![Analytics](https://kubernetes-site.appspot.com/UA-36037335-10/GitHub/docs/design/admission_control.md?pixel)]()
2015-07-14 00:13:09 +00:00
<!-- END MUNGE: GENERATED_ANALYTICS -->