-
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
Gracefully handle decryption errors during ESO migrations #105968
Gracefully handle decryption errors during ESO migrations #105968
Conversation
@@ -15,121 +15,185 @@ import { migrationMocks } from 'src/core/server/mocks'; | |||
const context = migrationMocks.createContext(); | |||
const encryptedSavedObjectsSetup = encryptedSavedObjectsMock.createSetup(); | |||
|
|||
describe('7.10.0', () => { | |||
describe('successful migrations', () => { |
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.
Recommend reviewing this with Hide whitespace changes
turned on for more meaningful diffs.
Pinging @elastic/kibana-alerting-services (Team:Alerting Services) |
Pinging @elastic/kibana-security (Team:Security) |
@elasticmachine merge upstream |
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.
Haven't tried this yet, but code LGTM.
One thing - we have some existing FT that look like they are testing migrated objects, so it seems like there's a possibility for us to add one for this? Or I guess two - one for rules, one for connectors? Not quite sure how these are run, maybe it's not possible to create such a test case?
Feels like there's a follow-on for this - it would be nice to mark un-decryptable connectors the same way we mark imported connectors, with the "missing secrets" property. That way, we can be a little more pro-active to the user regarding the state of the objects, without having to wait for them to be executed to find out there's a problem. But I don't think we really have a property like that for alerting rules, and I suspect they are a bigger worry than connectors.
And to handle that, we'd need to have the ESO plugin also return back an indication that the migration didn't couldn't decrypt, so we would know when we could set the "missing secrets" property, and the equivalent of what that would be for a rule.
It's also probably the case that we'd like to be even MORE pro-active than I suggested, via something like a Notification Center message providing migration issues.
So, I think this is pretty good for what we can reasonably handle today, and it will be good to see this in practice to see if we even need to do more work here, and if there are better ways of informing the user what has happened.
ACK: going to review this PR today, or tomorrow CET morning at the latest |
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.
The general idea looks good to me, I left few nits and questions. I also left one concern that I'd like to think about a bit more, but didn't want to hold the review completely.
x-pack/plugins/encrypted_saved_objects/server/create_migration.ts
Outdated
Show resolved
Hide resolved
x-pack/plugins/encrypted_saved_objects/server/create_migration.ts
Outdated
Show resolved
Hide resolved
x-pack/plugins/encrypted_saved_objects/server/create_migration.ts
Outdated
Show resolved
Hide resolved
x-pack/plugins/encrypted_saved_objects/server/create_migration.ts
Outdated
Show resolved
Hide resolved
x-pack/plugins/encrypted_saved_objects/server/create_migration.ts
Outdated
Show resolved
Hide resolved
x-pack/plugins/encrypted_saved_objects/server/create_migration.ts
Outdated
Show resolved
Hide resolved
x-pack/plugins/encrypted_saved_objects/server/create_migration.ts
Outdated
Show resolved
Hide resolved
x-pack/plugins/encrypted_saved_objects/server/create_migration.ts
Outdated
Show resolved
Hide resolved
...ck/test/encrypted_saved_objects_api_integration/fixtures/api_consumer_plugin/server/index.ts
Outdated
Show resolved
Hide resolved
…ing/decrypt-error-on-migration-eso
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 with green CI. Thanks a lot for the patience while making necessary adjustments!
Special 🏅 for the good test coverage 🙂
…ing/decrypt-error-on-migration-eso
@pmuellr There have been some changes since your review, would you mind re-reviewing? Specifically, I updated |
} = await this.context.encryptedSavedObjectsClient.getDecryptedAsInternalUser<RawAlert>( | ||
'alert', | ||
alertId, | ||
{ namespace } | ||
); | ||
|
||
return apiKey; | ||
if (!attributes.hasOwnProperty('apiKey')) { |
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.
Sounds like you're testing with no security right now (IRL), so I guess we'll find out if we have this property set for "no security" scenarios! I'm guessing there's a good chance we never set the field, and so we might not have that property, and so we wouldn't want to throw an error, but return null instead. Not sure.
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 was just a quick look in the task_runner - I'll do a full re-review though ...
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.
@pmuellr Finally was able to verify that with security turned off, the apiKey field exists and is set to null. I ran my test migration after changing the encryption key and verified that there were no decryption failures during the migration (because there's nothing to decrypt) and so the apiKey field remains null and the rule runs fine after migration.
That being said, I am going to wait for this PR to be merged and test again after that. It seems like that should fix the unhandled promise rejection and then it won't matter if the api key is null or undefined.
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.
Fleet changes 🚀
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.
re-review of the action/alerting parts here; still LGTM, left a nit comment regarding object destructuring
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
…ing/decrypt-error-on-migration-eso
Was able to revert changes to alerting task runner (in this commit after this PR got merged. Rules without an |
@elasticmachine merge upstream |
💚 Build SucceededMetrics [docs]Public APIs missing comments
Public APIs missing exports
History
To update your PR or re-run it, just comment with: cc @ymao1 |
💚 Backport successful
This backport PR will be merged automatically after passing CI. |
…5968) * Updating unit tests * Fixing types * Updating readme and adding warning message * Updating README * PR fixes * collapsing args to create migration fn * Adding functional tests * Adding comment to functional test * Adding stripOrDecryptAttributesSync * Using stripOrDecryptAttributesSync * Fixing unit tests * PR fixes * PR fixes * Moving validation of apikey existence in alerting task runner * Cleanup * Reverting changes to alerting task runner * PR fixes Co-authored-by: Kibana Machine <[email protected]>
…107051) * Updating unit tests * Fixing types * Updating readme and adding warning message * Updating README * PR fixes * collapsing args to create migration fn * Adding functional tests * Adding comment to functional test * Adding stripOrDecryptAttributesSync * Using stripOrDecryptAttributesSync * Fixing unit tests * PR fixes * PR fixes * Moving validation of apikey existence in alerting task runner * Cleanup * Reverting changes to alerting task runner * PR fixes Co-authored-by: Kibana Machine <[email protected]> Co-authored-by: ymao1 <[email protected]>
…5968) * Updating unit tests * Fixing types * Updating readme and adding warning message * Updating README * PR fixes * collapsing args to create migration fn * Adding functional tests * Adding comment to functional test * Adding stripOrDecryptAttributesSync * Using stripOrDecryptAttributesSync * Fixing unit tests * PR fixes * PR fixes * Moving validation of apikey existence in alerting task runner * Cleanup * Reverting changes to alerting task runner * PR fixes Co-authored-by: Kibana Machine <[email protected]>
Resolves #101582
Summary
shouldMigrateIfDecryptionFails
flag. If this flag is set tofalse
or undefined, decryption errors will be thrown (this is the previous behavior). If the flag is set totrue
, decryption errors will be caught, encrypted attributes will be stripped and the migration function will be applied to the stripped document.shouldMigrateIfDecryptionFails
totrue
and to log and throw any errors thrown during migration. While the original issue specifically mentioned decryption errors, the try/catch block in these migration functions would actually swallow any error during migration (decryption, migrating, encryption) and skip migrating the saved object.To verify
yarn es snapshot --ssl --license trial -E path.data=../data
to run ES so that you can test the migrations.xpack.encryptedSavedObjects.encryptionKey
set in your kibana.ymlxpack.encryptedSavedObjects.encryptionKey
in your kibana.yml. Start up Kibana.updatedAt
andnotifyWhen
fieldshasAuth
fieldisMissingSecrets
fieldChecklist
Delete any items that are not applicable to this PR.