Skip to content
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

Merged
merged 8 commits into from
Nov 1, 2019

Conversation

azasypkin
Copy link
Member

Migrate Encrypted Saved Objects plugin to the new platform.

NOTE: It'd be much easier to review PR commit by commit.

@azasypkin azasypkin added Team:Security Team focused on: Auth, Users, Roles, Spaces, Audit Logging, and more! Feature:NP Migration v7.6.0 labels Oct 31, 2019
@azasypkin azasypkin requested a review from a team as a code owner October 31, 2019 16:17
@azasypkin azasypkin requested a review from a team October 31, 2019 16:17
@elasticmachine
Copy link
Contributor

Pinging @elastic/kibana-security (Team:Security)

@azasypkin azasypkin added the release_note:skip Skip the PR/issue when compiling release notes label Oct 31, 2019
* @param audit Audit logger instance.
*/
constructor(
encryptionKey: string,
private readonly knownTypes: readonly string[],
Copy link
Member Author

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?

Copy link
Member

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?

Copy link
Member Author

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.

@azasypkin azasypkin force-pushed the issue-xxx-migrate-encrypted-so branch from 5380a52 to b051ef2 Compare October 31, 2019 16:30
@legrego legrego self-requested a review October 31, 2019 17:23
@azasypkin azasypkin force-pushed the issue-xxx-migrate-encrypted-so branch from b051ef2 to ef07b22 Compare October 31, 2019 17:40
@elasticmachine

This comment has been minimized.

@elasticmachine

This comment has been minimized.

@azasypkin azasypkin force-pushed the issue-xxx-migrate-encrypted-so branch from ef07b22 to cfc031c Compare October 31, 2019 20:21
@elasticmachine
Copy link
Contributor

💚 Build Succeeded

@azasypkin azasypkin requested a review from mikecote October 31, 2019 21:47
@azasypkin
Copy link
Member Author

@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 Changes in other plugins. commit

Thanks!

Copy link
Contributor

@mikecote mikecote left a 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!

Copy link
Member

@legrego legrego left a 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({
Copy link
Member

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.

Copy link
Member Author

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(
Copy link
Member

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?

Copy link
Member Author

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?

Copy link
Member

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'),
Copy link
Member

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.

Copy link
Member Author

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 🤷‍♂️

Copy link
Member

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 :)

Copy link
Member Author

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) {
Copy link
Member

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?

Suggested change
if (Object.keys(attributesAAD).length) {
if (!Object.keys(attributesAAD).length) {

Copy link
Member Author

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.

Copy link
Member

@legrego legrego left a 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

@elasticmachine
Copy link
Contributor

💚 Build Succeeded

@azasypkin azasypkin requested a review from legrego November 1, 2019 18:02
@azasypkin
Copy link
Member Author

@legrego PR is ready for the second pass, thanks!

Copy link
Member

@legrego legrego left a 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!

x-pack/plugins/encrypted_saved_objects/README.md Outdated Show resolved Hide resolved
@elasticmachine
Copy link
Contributor

💚 Build Succeeded

@azasypkin
Copy link
Member Author

7.x/7.6.0: 35615a3

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
backported Feature:NP Migration release_note:skip Skip the PR/issue when compiling release notes Team:Security Team focused on: Auth, Users, Roles, Spaces, Audit Logging, and more! v7.6.0
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants