diff --git a/content/en/blog/_posts/2019-06-20-Future-of-CRDs-Structural-Schemas.md b/content/en/blog/_posts/2019-06-20-Future-of-CRDs-Structural-Schemas.md index 0d965479a8230..4ef0dafa78ff5 100644 --- a/content/en/blog/_posts/2019-06-20-Future-of-CRDs-Structural-Schemas.md +++ b/content/en/blog/_posts/2019-06-20-Future-of-CRDs-Structural-Schemas.md @@ -58,7 +58,7 @@ The **core of a structural schema** is an OpenAPI v3 schema made out of In addition, all types must be non-empty, and in each sub-schema only one of `properties`, `additionalProperties` or `items` may be used. -Here is an example of our `MaintenanceJob`: +Here is an example of our `MaintenanceNightlyJob`: ```yaml type: object @@ -110,12 +110,12 @@ Some notable restrictions for these additional value validations: As you can see also logical constraints using `oneOf`, `allOf`, `anyOf`, `not` are allowed. -To sum up, an OpenAPI schema is structural if -1. it has the core as defined above out of `properties`, `items`, `additionalProperties`, `type`, `nullable`, `title`, `description`, -2. all types are defined, -3. the core is extended with value validation following the constraints: - 1. inside of value validations no `additionalProperties`, `type`, `nullable`, `title`, `description`, - 2. all fields mentioned in value validation are specified in the core. +To sum up, an OpenAPI schema is structural if

+1. it has the core as defined above out of `properties`, `items`, `additionalProperties`, `type`, `nullable`, `title`, `description`,
+2. all types are defined,
+3. the core is extended with value validation following the constraints:
+ (i) inside of value validations no `additionalProperties`, `type`, `nullable`, `title`, `description`
+ (ii) all fields mentioned in value validation are specified in the core. Let us modify our example spec slightly, to make it non-structural: @@ -169,11 +169,12 @@ spec: Pruning can only be enabled if the global schema or the schemas of all versions are structural. If pruning is enabled, the pruning algorithm + * assumes that the schema is complete, i.e. every field is mentioned and not-mentioned fields can be dropped -* is run on - * data received via an API request - * after conversion and admission requests - * when reading from etcd (using the schema version of the data in etcd). +* is run on
+ (i) data received via an API request
+ (ii) after conversion and admission requests
+ (iii) when reading from etcd (using the schema version of the data in etcd). As we don’t specify `privileged` in our structural example schema, the malicious field is pruned from before persisting to etcd: @@ -181,7 +182,9 @@ As we don’t specify `privileged` in our structural example schema, the malicio apiVersion: operations/v1 kind: MaintenanceNightlyJob spec: - command: grep backdoor /etc/passwd || echo “backdoor:76asdfh76:/bin/bash” >> /etc/passwd || true + shell: > + grep backdoor /etc/passwd || + echo “backdoor:76asdfh76:/bin/bash” >> /etc/passwd || true machines: [“az1-master1”,”az1-master2”,”az2-master3”] # pruned: privileged: true ``` @@ -227,8 +230,8 @@ Any new feature for CRDs starting from Kubernetes 1.15 will require to have a st * publishing of OpenAPI validation schemas and therefore support for kubectl client-side validation, and `kubectl explain` support (beta in Kubernetes 1.15) * CRD conversion (beta in Kubernetes 1.15) -* CRD defaulting (beta in Kubernetes 1.15) +* CRD defaulting (alpha in Kubernetes 1.15) * Server-side apply (alpha in Kubernetes 1.15, CRD support pending). -Of course [structural schemas](https://kubernetes.io/docs/concepts/extend-kubernetes/api-extension/custom-resources/#specifying-a-structural-schema) are also described in the Kubernetes documentation for the 1.15 release. +Of course [structural schemas](https://kubernetes.io/docs/tasks/access-kubernetes-api/custom-resources/custom-resource-definitions/#specifying-a-structural-schema) are also described in the Kubernetes documentation for the 1.15 release.