-
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
Beats Management plugin: migrate server-side code #70930
Beats Management plugin: migrate server-side code #70930
Conversation
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 FTR test suite (x-pack/test/api_integration/apis/beats
) is passing, unfortunately it doesn't cover all the endpoints.
success: false, | ||
error: { code: 400, message: 'Invalid enrollment token' }, | ||
statusCode: 400, | ||
error: 'Bad Request', | ||
message: 'Invalid enrollment token', |
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 legacy plugin was using custom body payload for error responses, which is not possible with KP. The client-side code actually don't care about this format changes, as the body of an error response is never accessed.
export function wrapRouteWithSecurity<P, Q, B>( | ||
{ | ||
requiredLicense = [], |
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.
Extracted/adapted from x-pack/legacy/plugins/beats_management/server/lib/framework.ts#wrapRouteWithSecurity
export class KibanaBackendFrameworkAdapter implements BackendFrameworkAdapter { | ||
public readonly internalUser = internalUser; | ||
public info: null | FrameworkInfo = null; |
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.
Too many changes to keep file track, but this was x-pack/legacy/plugins/beats_management/server/lib/adapters/framework/kibana_framework_adapter.ts
/* | ||
import Joi from 'joi'; | ||
import { FrameworkRequest } from '../../lib/adapters/framework/adapter_types'; | ||
import { CMServerLibs } from '../../lib/types'; |
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 kept the legacy route registration commented in the route files to ease the diff when reviewing. I will remove them all before merging
// TODO: fixme eventually, need to access `info.remoteAddress` from KibanaRequest. | ||
const legacyRequest = ensureRawRequest(request); |
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 need to access legacyRequest.info.remoteAddress
, which is not exposed on KibanaRequest
. I discussed with @restrry of the possibility to add it to core API. However as this plugin is the only one having this need and knowing that it will be removed for 8.0, I'm just using the private ensureRawRequest
utility here.
I can implement the 'correct' way if that's preferable.
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.
Josh added one in #71019
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.
Ended up implementing it differently, so that PR no longer adds this API. I'm fine with this implementation for now and if other plugins (that aren't about to get deleted) also need this, we can re-evaluate adding it then.
headers: Joi.object({ | ||
'kbn-beats-access-token': Joi.string().required(), | ||
}).options({ allowUnknown: true }), |
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 misleading kbn-beats-access-token
token validation is actually doing nothing, as the object is not .required()
. Also, the header is not used in the route handler, and neither the FTR test suite nor the client-side API are sending the header, which make me think this was just bad copypasta.
All that to say: the fact that this validation is not present on the KP handler is not a mistake.
// TODO: write to Kibana audit log file | ||
router.put( |
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 just kept the TODO comments unchanged.
body: schema.nullable( | ||
schema.object({ | ||
num_tokens: schema.number({ defaultValue: DEFAULT_NUM_TOKENS, min: 1 }), | ||
}) | ||
), |
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.
TIL an empty payload is null
, not undefined
for hapi.
Pinging @elastic/kibana-platform (Team:Platform) |
@ph @justinkambic would you mind sparing some time to perform a quick user testing of the plugin's functionalities? |
This look targetting for 7.10 so I will give it a shot after FF? is that okay with you?/ |
@ph yea, it's planned for 7.10, so after FF is perfectly fine. Thanks a lot. |
…anagement-server-2
@ph @justinkambic do you think you'll have the capacity to take a look in the next few weeks? |
…anagement-server-2
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.
Review summary
I primarily reviewed the front-end changes, which are more-or-less an update to the imports to account for file migration. Nothing stood out to me on that account. I did look over server code as well, everything seems to be working as I'd expect, and the code migration largely made sense.
I attempted to utilize each of this plugin's routes while doing my functional review as well.
Functional summary
My functional review consisted of:
- Enroll a beat
- Create a tag
- Create config block for Filebeat to tail a log
- Create an output config block for ES access
- Attach a tag to a beat
- Create and attach multiple tags to beats
- Remove tag from beat
- Run Filebeat and ingest data, ensure my logs are indexed
- Delete a tag
- Unenroll the beat
Bugs
- I did notice some weirdness when it came to deleting tags. It seems that when a tag is selected and deleted from the list, all the other tags are dropped from the list except the one deleted. Re-fetching of the available tags does show that the deleted one is gone and the rest remain, but it's definitely an unsettling UX. I'm not sure if this is how the table already behaves in master.
- A similar behavior when unenrolling beats. I unenrolled my Filebeat and the UI didn't reflect the change appropriately. After refresh the list displayed no items, like I would expect. Again, this bug might already be in master and not a side effect of this change.
@justinkambic thanks a lot of the review. Regarding the refresh bugs, I just checked master, and can confirm they are already present on our master branch. Looking at the client-side migration PR from @joshdover , it looks like it was even present before we migrated the client-side code, as the action handlers for the various table did not really change. So I guess this is 'alright'. I can open a follow-up issue to track this if we feel like it's necessary. |
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.
Reviewed the key integration points & all route code. Wasn't able to find inconsistencies with the old routes that could create issues. Of course there's plenty of opportunity for improvement in this plugin, but not worth the effort since it will be sunset soon. Integration with Core APIs LGTM.
Do you mind go ahead and renaming this plugin's id to beatsManagement
so we can do away with that deprecation log?
if (user.kind !== 'authenticated') { | ||
return response.forbidden({ | ||
body: { | ||
message: `Request must be authenticated`, | ||
}, | ||
}); | ||
} |
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'm not even sure this is necessary since this is the default behavior? Maybe not worth changing the original implementation 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.
Yea, honestly I tried to reduce the changes as much as possible, so the 'security' handler wrapper may have some redundancy with core's defaults, but I feel like it's not worth doing any additional changes.
I think this is a question more for the Ingest team if they want someone to fix it. Given that we know these issues exist, perhaps it would be a good idea to track them in an issue and make Ingest aware of them. |
💚 Build SucceededBuild metrics@kbn/optimizer bundle module count
async chunks size
page load bundle size
History
To update your PR or re-run it, just comment with: |
* move all the legacy codebase to KP plugin * fix imports * add empty handler context & rename routes folder * start migrating routes * migrate rest of the routes * migrate adapters * remove beats from legacy xpack plugin * use nullable + replace response.custom * fix wrapRouteWithSecurity, remove incorrect header validation * remove comment * updating generated plugin list * fix typos in doc * adapt readme too. * remove old commented routes from route files * remove eslint disabling * use camel case for plugin id * update generated doc Co-authored-by: Josh Dover <[email protected]> # Conflicts: # x-pack/legacy/plugins/beats_management/server/rest_api/beats/configuration.ts # x-pack/legacy/plugins/beats_management/server/rest_api/configurations/upsert.ts
* move all the legacy codebase to KP plugin * fix imports * add empty handler context & rename routes folder * start migrating routes * migrate rest of the routes * migrate adapters * remove beats from legacy xpack plugin * use nullable + replace response.custom * fix wrapRouteWithSecurity, remove incorrect header validation * remove comment * updating generated plugin list * fix typos in doc * adapt readme too. * remove old commented routes from route files * remove eslint disabling * use camel case for plugin id * update generated doc Co-authored-by: Josh Dover <[email protected]> # Conflicts: # x-pack/legacy/plugins/beats_management/server/rest_api/beats/configuration.ts # x-pack/legacy/plugins/beats_management/server/rest_api/configurations/upsert.ts
Summary
Fix #67980
Checklist