Like I explained before in my comments, it would provide us 2 things:
No-one (say even someone with OpenStack admin role who has access to the internal endpoint) could swap the data through the locations API. They would need write access to the actual storage to do so. With Ceph which is clearly our biggest worry here, the location points to a snapshot that is read-only and would require again location update on the image to be modified closing even that vector.
The users would have mechanism to verify the image data (by downloading it, for example with glanceclient). Regardless if their preferred consumption method does that as part of the deployment workflow. This would be available for all images available to them; being it public, community or shared.
Like I said earlier, we made very poor assumptions when we expected this issue to just go away by deployment model advice during OSSN-0065 and lots of those assumptions were relying on the image having checksum and it being verified. We could at least make sure to have the hash calculated and verify it during all of our own operations and we can do that without breaking the current legitimate use cases.
My main concern is that we effectively reissue OSSN-0065, nothing changes as we sweep the security holes under the carpet again because it's convenient to push the responsibility to the operators.
Like I explained before in my comments, it would provide us 2 things:
No-one (say even someone with OpenStack admin role who has access to the internal endpoint) could swap the data through the locations API. They would need write access to the actual storage to do so. With Ceph which is clearly our biggest worry here, the location points to a snapshot that is read-only and would require again location update on the image to be modified closing even that vector.
The users would have mechanism to verify the image data (by downloading it, for example with glanceclient). Regardless if their preferred consumption method does that as part of the deployment workflow. This would be available for all images available to them; being it public, community or shared.
Like I said earlier, we made very poor assumptions when we expected this issue to just go away by deployment model advice during OSSN-0065 and lots of those assumptions were relying on the image having checksum and it being verified. We could at least make sure to have the hash calculated and verify it during all of our own operations and we can do that without breaking the current legitimate use cases.
My main concern is that we effectively reissue OSSN-0065, nothing changes as we sweep the security holes under the carpet again because it's convenient to push the responsibility to the operators.