Image Signing Enforcement is changing resource image references

[wmlynch]

What commit ID of Portieris did you experience the problem with?

Portieris release v0.10.0

What went wrong?

Before Portieris Enablement:
    kubectl -n kube-system get deploy vpn --no-headers -o custom-columns=:.spec.template.spec.containers[*].image
    registry.ng.bluemix.net/armada-master/vpn-client:2.4.6-r3-IKS-301
After Portiers Enablement with Image Signing Enforcement Policy:
    kubectl -n kube-system get deploy vpn --no-headers -o custom-columns=:.spec.template.spec.containers[*].image
    registry.ng.bluemix.net/armada-master/vpn-client@sha256:eadf26e519faf3bd8c156d567430d265e084f1395f6bf68eddec5640e38281f6

What should have happened differently?

How can it be reproduced?

Any other relevant information

[sjhx]

I would assert that this is a necessary and fundamental part of the function of Portieris, it is done in order to ensure that the admitted images are the ones that are run regardless of external updates such as registry pushes or tag re-assignments.

There are existing issues looking to maintain a trace back to the image referance as originally admitted. #114

I understand the "want" is that this does not happen but I don't see a pathway to that currently.

[sjhx]

Elaborating the concern here, if there is a deployment technology which has a reconciliation loop which looks at the deployed image reference and finding it mutated with the image digest believes it is not the desired state and so begins an update "fight" driving api server, portieris, and registry or signature store traffic.

[sjhx]

Current thinking is that we should introduce and option to not mutate, while it considerably weakens the enforcement there is still value and allows the introduction of Portieris where it would otherwise be impossible. This needs to be a policy option rather than a runtime option since different images/namespaces may want different settings.