Encryption Feature: Expose 'X-Encrypted-Data' header
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
OpenStack Object Storage (swift) |
In Progress
|
Wishlist
|
Unassigned |
Bug Description
We worked pretty hard when implementing encryption to make sure that a user couldn't tell if a Swift Operator chose to use encryption or not. But it turns out some other notable object storage systems always drop something like "x-amz-
While the scope of the encryption feature as it is implemented today probably *prefers* the use case where the user should not need to know or care if data is encrypted - it doesn't *preclude* the use case where an operator would like to expose the information, or a user might want to know it.
Use-case:
Not all of the object data in swift is encrypted (added to existing cluster), so when I GET/HEAD i'd like to know this information.
Use-Case:
If a Swift deployment/solution is ever certified by ICD503 compliance or something, a user who's data requires this certification or something similar may need to audit to say "Yup, see my data says it's encrypted right there - CHEAAACKAH"
Probably the encryption middleware should add a Backend header in the response anytime it decrypts something (or maybe in the PUT response too?), then by default there'd be no change in behavior, but a keymaster implementation (or any other middleware like swift3) *could* translate the backend header to something user visible or even add a toggle for the translation behavior.
Nice idea. We have in the past looked for any "crypto-meta" to indicate whether encryption was involved in any part. One complication is that you can have the body unencrypted, while having the metadata encrypted. This would happen if a POST is issued while having encryption in the pipeline against an existing unecrypted object. I suppose the encrypted flag that may be added would ensure that all related information is encrypted if the use case is for some sort of compliance.
There are a couple trello cards for encryption follow-up that are about only providing keys if there is a need for them. If changes are made in the keymaaster for this which would help to determine when exactly keys are needed, then this could be a related patch.