-
Notifications
You must be signed in to change notification settings - Fork 8.2k
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
[Fleet] Allow to install a package without the registry. #70582
Comments
Pinging @elastic/ingest-management (Team:Ingest Management) |
@mtojek @ycombinator @jsoriano this one should be interesting for the I understand that a zip in the UI would end up hitting an API too, so +1 on having an API at least to allow us to do this from the command line |
This would be great yes, so package development can be done without a registry, and having a independent definition of the package becomes more important. Also this will allow to have a clearer view of each component:
|
++ for having an API for reasons mentioned by others. Are there any safety or security considerations here? Do we want to put such an API behind auth? Regardless of auth, we probably need safety checks to prevent overrides (so one user cannot override a package being used by others)? Or, if this is mainly a development concern (which it sounds like), perhaps we only enable this API in Kibana dev mode or behind an opt-in kibana.yml setting - then we don't need to worry about the safety/security issues as much? |
We'd like the option to run a local registry to be a Gold+ feature, and this would provide a backdoor. If we enable it in production, we may need to put a license restriction on it. Otherwise, we could limit it to development only mode. |
It should be already behind auth, nothing related to ingest manager should be exposed. |
Yes, of course it is, doh! 🤦 |
Anything in Ingest Manager is only available for However, EPM package installation code never got a real security audit, so if this feature will be enabled in cloud, I would say yes, there are security considerations, not for customer data but for our own hosted cloud environment. |
Here's my rough proposal what we need to change to allow direct package upload and installation. I've split it into two iterations, the first one would be for 7.10 because the feature is important for integrations developers. The second (and possible third, fourth) would come in later releases as necessary. Direct package upload7.10: First iteration, development use only, undocumentedFile upload
Changes to saved object 'epm-packages'
Changes to Package installation (can be done in parallel with Integrations page)
Changes to Integrations page (can be done in parallel with Package installation)
All other pages & API endpoints
7.11ff: Second iteration, more stable, probably still undocumentedFile upload
Package validation
Package installation
Integrations page
|
@skh I like that proposal, thanks for creating clear / steps and goals. for that. |
To potentially make it easier on the UI side, we could have a third tab "local" packages. On |
Are packages needed now after installation? |
Yes, to display them properly in the UI (screenshots & README, icons in case Kibana doesn't already have an icon for the technology). Right now this causes errors when the registry is unavailable. |
@skh @mostlyjason This draft looks good to me, although I believe there is one area not covered:
We're working on enabling the elastic-package tool for package development. It depends on the package-registry now. It would be cool to use the direct package upload feature, but I'm afraid we can't depend on features available for Gold users only. Supporting two options (with/without the package-registry) might not be the simplest option for maintenance. |
@mtojek At the moment most package development happens on clusters with a trial license so I would hope license does not really play a role here? |
@ruflin if we want to improve the user experience, we should consider the direct upload feature. It would eliminate dependency on the package-registry during development and simplify things. Unfortunately the Gold license seems to be a blocker here. |
Edited: support |
Seems like a substantial investment on something that's not shipped to customers? Can someone help explain the reason for this project and why its valuable? It seems like this is primarily about developer experience, but is there any potential for customer benefit? I always thought running a local registry is as easy as a docker image, but I'm not familiar with the technical reasons. |
Ok, let me play a customer here :) Might be a bit opinionated.
From integration developer perspective, total delivery time for new integration is shorter, the whole environment setup would be simpler, less prone to potential errors, out-of-syncs. No need to lose time to restarts and cleanups. Simply select the integration bundle (.zip) and install it.
companies that perform security reviews need to go over every dependency or service and reverify it/validate if it's inline with the security policy. If there is no registry at all or the Ingest Manager is in offline mode (or airgapped), the customer can install only relevant packages and doesn't have to care about policies. Also, the registry is yet another dependency that can break down. As I said, simpler design means less maintenance issues.
Docker images will be bigger and bigger every time we update packages, but this is a different issue on our side. At the beginning it won't be a problem for the customer, but they may be confused at some point on how many packages they HAVE to serve in their local setups, but won't use at all. |
Hey @jen-huang , @joshdover ! Do you it's possible to give this issue a higher priority? It's slipping through iteration by iteration. |
Note that we have tentatively moved #112095 to a stretch goal for 8.0, it may not land until 8.1 |
@jen-huang @kpollich could this issue be prioritized? |
+1 on this. We're pretty close here. I've been testing the upload endpoint out with my ingest pipeline monitoring POC and it mostly works, but there are a few issues (at least on 8.5.2 where I am testing):
|
Instead of having a UI to upload packages as a first step, lets add support for it in |
I opened the issue here for the elastic-package implementation: elastic/elastic-package#1084 Using elastic-package for the upload has the benefit that validation of the package can all happen on the elastic-package side for now and does not have to be reimplemented in Fleet. Fleet would just assume it is a valid package. |
I am closing this long-running issue in favor of #148599 which contains a summary of remaining tasks. |
@jen-huang Good to see we have a more detailed issue around what is still missing. It is a bit unfortunated that this issue got closed as a pretty long list of issues and docs reference this issue. Could we instead keep it open until the linked issue is resolved? There are 4 checkboxes in this initial issue which are still open and I don't see referenced in your new issue. These are more refactoring tasks but if I remember correctly, pretty foundational to make the new feature happening and stable. |
For development and testing purposes, there should be a way to directly install the package (whatever is generated to be deployed in the package storage, either exploded or as a tarball) without the registry.
We need to investigate how we want to do that:
This feature is initially for developers but could be extended to every user.
Full implementation proposal: #70582 (comment)
7.10:
epm-package
saved object to include the package source (@skh [Ingest Manager] Install uploaded package #77986)packages
endpoint to accept an uploaded package inPOST
(@skh [Ingest Manager] Add route for package installation by upload #77044)7.11:
The text was updated successfully, but these errors were encountered: