ereslibre
commented
3 years ago Thank you for your report @darren-bell-nanthealth!
We are producing this kind of "surgical" patches already. The problem in your case seems to be the usage of an outdated rust SDK. I tried to push your policy dependencies to use policy-sdk-rust 0.2.3 and did a related change:
diff --git a/Cargo.toml b/Cargo.toml
index d694974..85cca39 100644
--- a/Cargo.toml
+++ b/Cargo.toml
@@ -11,7 +11,7 @@ crate-type = ["cdylib"]
[dependencies]
k8s-openapi = { version = "0.11.0", features = ["v1_20"] }
-kubewarden-policy-sdk = "0.1.0"
+kubewarden-policy-sdk = "0.2.3"
serde = { version = "1.0", features = ["derive"] }
serde_json = "1.0"
wapc-guest = "0.4.0"
diff --git a/src/lib.rs b/src/lib.rs
index 88ec3b1..762b901 100644
--- a/src/lib.rs
+++ b/src/lib.rs
@@ -33,7 +33,7 @@ fn validate(payload: &[u8]) -> CallResult {
// NOTE 3
let mutated_object =
serde_json::to_value(mutated_ingress_with_annotations_and_tls).unwrap();
- mutate_request(&mutated_object)
+ mutate_request(mutated_object)
}
Err(_) => {
// We were forwarded a request we cannot unmarshal orNow, I execute your policy after building with make:
ereslibre@desktop ~/kubewarden-istio-ingress-mutation (main)> kwctl run --settings-json '{"secret":"supersecret"}' --request-path test_data/6_full_admission_review.json target/wasm32-unknown-unknown/release/istio_ingress_mutation.wasm | jq -r .patch | base64 -d | jq
[
{
"op": "add",
"path": "/metadata/annotations/kubewarden.policy.ingress~1inspected",
"value": "true"
},
{
"op": "add",
"path": "/metadata/annotations/nginx.ingress.kubernetes.io~1service-upstream",
"value": "true"
},
{
"op": "add",
"path": "/metadata/annotations/nginx.ingress.kubernetes.io~1upstream-vhost",
"value": "kelp-kelp-svc.default.svc.cluster.local"
},
{
"op": "add",
"path": "/spec/tls",
"value": [
{
"hosts": [
"dtkt.navimedix.com",
"dtkt1.navimedix.com"
],
"secretName": "external-ingress-secret"
}
]
}
]And this should work fine.
Just a comment regarding the way you tried to reproduce the issue: take into account that when mutation webhooks are executed, the object is not yet stored in etcd, so not the same rules apply if you use kubectl patch, that works against a persisted object that is enforced coherence by the API server, and so, many fields are immutable.
Thank you for your report, please close it if this solved your problem, and thank you for the amazing feedback :clap:
darren-bell-nanthealth
While writing a policy to mutate an ingress resource, I noticed that the resource was not being mutated after it was being applied to the cluster. To further test I used the kwctl to inspect the patch that KW was generating.
Steps to Reproduce
The following input file was used as test data test_data/6_full_admission_review.json
Which produced
The 64bit decoded value being:
However where I try to manually apply this JSONPatch
I get the following response back from the cluster
Context (Environment)
Kubernetes - 1.19.4 kwctl 0.1.6
Possible Solution
I believe the issues lie with trying to replace the entire resource using the "/" path. I tried replacing this with nothing i.e. "", and the request came back as invalid.
Essentially I don't think that K8s will allow you to change things in the metadata such as name, namespace, etc as this could make things very unpredictable. Such behaviour would be feasible if the whole resource document can be replaced.
Possibly a better approach would be a surgical approach to generating the patches required. Instead of replacing the entire document with a single patch. It may be better to generate several patches. An example of such an implementation taking a current and desired state, then generating many patches, can be found here https://json-patch-builder-online.github.io/. I believe that it is using the following library to generate the patches https://github.com/Starcounter-Jack/JSON-Patch