-
Notifications
You must be signed in to change notification settings - Fork 8.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Migrate Encrypted Saved Objects plugin to the new platform. #49890
Migrate Encrypted Saved Objects plugin to the new platform. #49890
Conversation
Pinging @elastic/kibana-security (Team:Security) |
* @param audit Audit logger instance. | ||
*/ | ||
constructor( | ||
encryptionKey: string, | ||
private readonly knownTypes: readonly string[], |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
note: this check didn't bring lots of value and it doesn't fit very well to NP since plugins will register their types during setup
that would make order of these operations important. So since SO client will return error for not known type anyway I decided to ditch this check. What do you think?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That makes sense to me. Since we're relying on specific behavior in a dependency for this functionality, what do you think about adding a functional test here to ensure that the public encryption/decryption endpoints behave correctly when this happens?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Somehow missed that comment, sorry. Yeah, it's a great idea, will add this test in a follow-up.
5380a52
to
b051ef2
Compare
b051ef2
to
ef07b22
Compare
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
ef07b22
to
cfc031c
Compare
💚 Build Succeeded |
@legrego it's better to review PR commit by commit, I tried to separate plain moves from changes. @mikecote I grouped all changes relevant to you in Thanks! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🙏This is awesome, thank you for doing this. Everything in that commit LGTM!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks really good! Just a couple of questions for you while I test this locally
}); | ||
... | ||
public setup(core: CoreSetup, { encryptedSavedObjects }: PluginSetupDependencies) { | ||
encrypted_saved_objects.registerType({ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: the parameter name here is encryptedSavedObjects
, but it's referenced on line 44 as `encrypted_saved_objects.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ha, will fix, thanks!
|
||
export const ConfigSchema = schema.object({ | ||
enabled: schema.boolean({ defaultValue: true }), | ||
encryptionKey: schema.conditional( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What do you think about renaming this from encryptionKey
to encryption_key
using the legacy deprecation system? Reading the full config path, xpack.encrypted_saved_objects.encryptionKey
looks rather inconsistent with the mixing of snake_case
and camelCase
. I know you didn't technically change this as part of this PR, but maybe the NP migration is a good time to start to make these types of things consistent?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, this bothers me as well, Kibana also isn't consistent in plugin IDs: it's a mix of snake_case
and camelCase
, even for NP plugins 😢 How do you feel about keeping encryptionKey
(to be consistent with security.encryptionKey
and reporting.encryptionKey
), but change plugin ID to encryptedSavedObjects
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How do you feel about keeping encryptionKey (to be consistent with security.encryptionKey and reporting.encryptionKey), but change plugin ID to encryptedSavedObjects?
That was actually going to be my original suggestion, but I changed my mind 😄
I'm struggling to find evidence of this, but I thought we were taking steps to move all settings (and therefore plugin ids) to snake_case
in order to be more consistent with Elasticsearch.
camelCase
is arguably easier for us on TS/JS though, because we have a linter rule that enforces camelCase
variable names, so any time you want to use a plugin, you'd have to do that conversion.
So in summary.... 🤷♂. If you don't want to make this change now, then maybe we can leave it as-is and try to have a broader discussion around naming?
export const ConfigSchema = schema.object({ | ||
enabled: schema.boolean({ defaultValue: true }), | ||
encryptionKey: schema.conditional( | ||
schema.contextRef('dist'), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
question I see that the security plugin also uses the dist
context ref, but core's http_config
is testing for dev
. Are those the only two contexts that you're aware of? Does it matter which context you test for in different scenarios? I can surmise that dist
is the built distribution, and dev
is presumably dev mode, but I just wanted to make sure I'm not missing any nuances here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Are those the only two contexts that you're aware of?
Core passes a bunch various context variables 1 and 2.
Does it matter which context you test for in different scenarios? I can surmise that dist is the built distribution, and dev is presumably dev mode, but I just wanted to make sure I'm not missing any nuances here.
Never thought about this to be honest, $dist
that we always had in the past (e.g. in legacy security and reporting plugins) sounds more appropriate for things like this since it's something we distribute to others, but 🤷♂️
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah, I see we have prod
as a context variable. I wonder if that would be more appropriate? Or would that complicate our functional test setup? It seems like we would always want prod
and dist
to behave the same way in terms of configuration, but maybe not? I'm splitting hairs, I can leave this alone :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm, these are all valid questions, let's ask Operations team!
Hey @elastic/kibana-operations can you please explain the conceptual difference between prod
and dist
Kibana "context flags" and when we should use one vs another? I see we historically used dist
for various cases (auto set encryption keys or disable advanced CORS settings if not "dist").
@@ -299,7 +295,7 @@ export class EncryptedSavedObjectsService { | |||
} | |||
|
|||
if (Object.keys(attributesAAD).length) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I know you didn't change this here, but is this check correct?
if (Object.keys(attributesAAD).length) { | |
if (!Object.keys(attributesAAD).length) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmmm, good catch! It looks like 🤦♂️ on my side, let me check.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let's be sure to update CODEOWNERS as well
💚 Build Succeeded |
@legrego PR is ready for the second pass, thanks! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM! Thanks for the changes!
Co-Authored-By: Larry Gregory <[email protected]>
💚 Build Succeeded |
7.x/7.6.0: 35615a3 |
Migrate Encrypted Saved Objects plugin to the new platform.
NOTE: It'd be much easier to review PR commit by commit.