github.com/jingruilea/kubeedge@v1.2.0-beta.0.0.20200410162146-4bb8902b3879/docs/proposals/web-hook.md (about)

     1  ---
     2  title: Dynamic Admission Control
     3  status: implementable
     4  authors:
     5      - "@chendave"
     6      - "@fisherxu"
     7  approvers:
     8    - rohitsardesai83
     9    - fisherxu
    10  
    11  creation-date: 2019-07-19
    12  last-updated: 2019-09-11
    13  ---
    14  
    15  # Motivation
    16  As the evolving of the project, it is foreseeable more API and resouce will be added in the project. kubeedge so far lack of effective way of pre-processing for the object configuration, for example, whether the pod that is going to be created contains the unwanted label, should the specific configmap be protected from deletion etc.
    17  
    18  There is a concrete example on the github [issue 845](https://github.com/kubeedge/kubeedge/issues/845), the issue there cannot be addressed by [CRD validation](https://kubernetes.io/docs/tasks/access-kubernetes-api/custom-resources/custom-resource-definitions/#validation), so we need to explore other approach to achieve that purpose.
    19  
    20  
    21  ## Goals
    22  * A framework to enable admission control in kubeedge.
    23  * Address the edge cases where kubernetes CRD validation cannot accomplish.
    24  * Create basic integration testcases.
    25  
    26  ## Non-goals
    27  * Basic CRD validation should be done by [validation](https://kubernetes.io/docs/tasks/access-kubernetes-api/custom-resources/custom-resource-definitions/#validation).
    28  * Start from `Device` and `DeviceModel` other kinds of resource will be evaluated later and will not be included in the first alpha version.
    29  
    30  # Proposal
    31  Propose using Kubernetes [Dynamic Admission Control](https://kubernetes.io/docs/reference/access-authn-authz/extensible-admission-controllers) to determine whether to accept or deny the request, the decision is based on how is the policy is configured, this give us chance to validate the request before persisting the object.
    32  
    33  
    34  # Design Details
    35  
    36  ## Admission service
    37  
    38  Admission webhook is managed as an independent service, it could be built as an docker image and run as a standalone process, the feature could
    39  be opted in by creating a k8s service with the built docker image as the backed image.
    40  
    41  The entry point the service looks like this,
    42  
    43  ```golang
    44  func main() {
    45  	klog.InitFlags(nil)
    46  	pflag.CommandLine.AddGoFlagSet(flag.CommandLine)
    47  
    48  	command := app.NewAdmissionCommand()
    49  
    50  	if err := command.Execute(); err != nil {
    51  		os.Exit(1)
    52  	}
    53  }
    54  ```
    55  
    56  A set of sample manifest is maintained in the code base, end-user could define their own manifest if there is any different usecases.
    57  
    58  ```bash
    59  $ ls *.yaml
    60  clusterrolebinding.yaml  clusterrole.yaml  deployment.yaml  serviceaccount.yaml  service.yaml
    61  ```
    62  
    63  
    64  ## Register admission webhook for each configuration
    65  Rules could be centralized here, as an example, register one admission webhook as below,
    66  
    67  ```golang
    68  Webhooks: []admissionregistrationv1beta1.ValidatingWebhook{
    69  	{
    70  		Name: ValidateDeviceModelWebhookName,
    71  		Rules: []admissionregistrationv1beta1.RuleWithOperations{{
    72  			Operations: []admissionregistrationv1beta1.OperationType{
    73  				admissionregistrationv1beta1.Create,
    74  				admissionregistrationv1beta1.Update,
    75  			},
    76  			Rule: admissionregistrationv1beta1.Rule{
    77  				APIGroups:   []string{"devices.kubeedge.io"},
    78  				APIVersions: []string{"v1alpha1"},
    79  				Resources:   []string{"devicemodels"},
    80  			},
    81  		}},
    82  		ClientConfig: admissionregistrationv1beta1.WebhookClientConfig{
    83  			Service: &admissionregistrationv1beta1.ServiceReference{
    84  				Namespace: opt.AdmissionServiceNamespace,
    85  				Name:      opt.AdmissionServiceName,
    86  				Path:      strPtr("/devicemodels"),
    87  			},
    88  			CABundle: cabundle,
    89  		},
    90  		FailurePolicy: &ignorePolicy,
    91  	},
    92  },
    93  ...
    94  ```
    95  
    96  ## Resource validation
    97  The validation logic is registered as an http handler which responds to a specific HTTP request, each resource should have its own handler
    98  pre-registered, and the validation is done by the handler.
    99  
   100  ```golang
   101  http.HandleFunc("/devices", serveDevice)
   102  func serveDevice(w http.ResponseWriter, r *http.Request) {
   103  	serve(w, r, admitDevice)
   104  }
   105  ```
   106  
   107  ```golang
   108  func admitDevice(review admissionv1beta1.AdmissionReview) *admissionv1beta1.AdmissionResponse {
   109  //validation logic is done here
   110  }
   111  ```
   112  
   113  ## Certification management
   114  Need to generate another set of key / certificate, or reuse the existing key / certificate for API validation, see [Authenticate apiservers](https://kubernetes.io/docs/reference/access-authn-authz/extensible-admission-controllers/#authenticate-apiservers) for details.
   115  shell scripts will be provided to generate key / certificate.
   116  
   117  
   118  ## Basic integration test / unit testcases will be provided.
   119  Testcase will cover all the basic usages and will be enriched with time goes on.
   120  
   121  ## New dependency
   122  Below package is added as a new dependency.
   123  * k8s.io/api/admission