feat(object): add object sse_customer_key_wo#3619
feat(object): add object sse_customer_key_wo#3619estellesoulard wants to merge 4 commits intomainfrom
Conversation
github-actions
bot
added
the
object
Codecov Report❌ Patch coverage is Additional details and impacted files@@ Coverage Diff @@
## master #3619 +/- ##
=========================================
- Coverage 2.32% 2.32% -0.01%
=========================================
Files 450 450
Lines 49153 49200 +47
=========================================
- Hits 1144 1142 -2
- Misses 47919 47967 +48
- Partials 90 91 +1 ☔ View full report in Codecov by Sentry. |
estellesoulard
force-pushed
the
feat/add-object-sse-key-wo
branch
from
b1d8448 to
d40c260
Compare
| datasource.FixDatasourceSchemaFlags(dsSchema, true, "bucket", "key") | ||
|
|
||
| datasource.AddOptionalFieldsToSchema(dsSchema, "region", "project_id") | ||
| datasource.AddOptionalFieldsToSchema(dsSchema, "region", "project_id", "sse_customer_key") |
There was a problem hiding this comment.
Note: Currently we could not get an sse_customer_key encrypted datasource (the key is required to build the proper s3 HeadObject call headers)
| // Add encryption headers if present (similar to resourceObjectRead) | ||
| // Only the regular (non Write Only) sse_customer_key can be set. | ||
| // Data sources cannot read objects encrypted with write-only keys | ||
| // since the actual key is not available in the data source configuration. | ||
| // Data sources cannot have WriteOnly attributes. Making it available would | ||
| // set the key in the state. |
There was a problem hiding this comment.
This limitation is why I am considering not merging this PR at all. Is this restriction (not being able to query the datasource specifically for sse_customer_key_wo encrypted objects) something we are OK with ? We might as well have a dedicated Ephemeral Resource at that point.
| // The only way to get an encrypted object is to provide the sse_customer_key. For a sse_customer_key_wo, | ||
| // datasources cannot have Write Only attributes, so we have to pass it as a regular sse_customer_key. | ||
| // This is not ideal, as the key is then set in the state, making the Write Only useless... | ||
| // Querying objects encrypted with a sse_customer_key_wo is discouraged. |
There was a problem hiding this comment.
This limitation is why I am considering not merging this PR at all. Is this restriction (not being able to query the datasource specifically for sse_customer_key_wo encrypted objects) something we are OK with ? We might as well have a dedicated Ephemeral Resource at that point.
| // Object was encrypted with write-only key, but we can't read it back | ||
| // since the actual key is not stored in state. This is expected behavior. | ||
| // Skip the HeadObject call and return partial state |
There was a problem hiding this comment.
This limitation is why I am considering not merging this PR at all. Is this restriction (having a partial state return specifically for sse_customer_key_wo encrypted objects create/update) something we are OK with ? We might as well have a dedicated Ephemeral Resource at that point.
3 participants
Leaving this PR as draft as the inherent limitations of having a Write Only encryption key have a big impact on the functionality. S3 object HEAD calls require the key, but the key being WriteOnly means it won't be available. This causes the following limitations :