Implements 'Key concepts' developer documentation for Encrypted Saved Objects #184334
Conversation
jeramysoucy
added
Team:Security
|
Pinging @elastic/kibana-security (Team:Security) |
jeramysoucy
added
release_note:skip
| an Saved Object type, all related business logic for that type must be capable of gracefully and appropriately handling an object with or without the attribute in both | ||
| the current and previous version of Kibana. Some of the advice here is applicable to any Saved Object type migration. | ||
|
|
||
| | Change to ESO | Encrypted? | In AAD? | General Guidance | |
There was a problem hiding this comment.
Thanks! I hope it gets used! 🤞
…ument links. Fixes typo.
|
@elastic/kibana-core Is there anything we should add or change? We'd also like your general feedback on readability. |
| included values requires re-encryption, which means the entire object must be provided when updating to avoid corrupting the object. If an ESO is corrupted by | ||
| a partial update, it will be effectively undecryptable. Currently, there is nothing preventing or limiting partial updates of ESOs (see open GitHub issue | ||
| [50256](https://github.com/elastic/kibana/issues/50256)), so this requires consistent diligence from developers utilizing ESOs. |
There was a problem hiding this comment.
(unrelated to the PR) TIL. I'll reply on the linked issue to reopen the discussion. Things have changed since 2019, we're now doing client-side updates, meaning that we do fetch the attributes from ES for partial updates, so this should be addressable (but maybe it requires encryption to be a first class citizen of the SOR first/.
| Saved Object Descriptor (see <DocLink id="kibDevDocsEncryptedSavedObjectsIntro" section="aad" text="AAD"/>). In theory, the space id will never change for a | ||
| `'multiple-isolated'`, which makes it a reasonable candidate for an AAD field. |
There was a problem hiding this comment.
I also debated including some explanation regarding whether adding spaceId to AAD is offering any real protection in this case.
"...but it would also require some additional management to ensure it contributes to protecting the data. For example, if an object is moved to a different space maliciously (or accidentally) in order to try to gain access to its encrypted attributes, the spaceId attribute does not necessarily reflect the space the object resides in, and on its own provides no mechanism to guarantee the object has not moved. Some additional mechanism to override the attribute's value with the object's current namespace prior to attempting decryption would add protection."
But I don't know if this is just too much, or if what I am saying here is even feasible to implement.
There was a problem hiding this comment.
I am going to merge the doc as-is, and potentially address this in an update.
Closes #176097
Summary
Adds 'Key concepts' developer documentation for Encrypted Saved Objects, covering the basic theory, usage, and maintenance for encrypted saved objects in Kibana.