[Fleet] Allow to install a package without the registry.

[ph]

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:

• Could we call an API?
• Could we drop a zip in the UI?
• Gold+

This feature is initially for developers but could be extended to every user.

---

Full implementation proposal: #70582 (comment)

7.10:

• Refactor EPM package handling & installation code (@skh [Ingest Manager] Install uploaded package #77986)
• Enhance epm-package saved object to include the package source (@skh [Ingest Manager] Install uploaded package #77986)
• Enhance EPM packages endpoint to accept an uploaded package in POST (@skh [Ingest Manager] Add route for package installation by upload #77044)

---

7.11:

• [Fleet] Use epm-packages saved object as main source of truth for installed packages [Fleet] Use epm-packages saved object as main source of truth for installed packages #81995 @neptunian
• [Fleet] Proposal: Store installed packages in cluster [Fleet] Proposal: Store installed packages in cluster #81110 @jfsiii
• [Fleet] Refactor package installation / upgrade / downgrade and error recovery / rollback [Fleet] Refactor package installation / upgrade / downgrade and error recovery / rollback #82007 @skh
• [Fleet] Add error handling: uploaded package missing from in-memory cache [Fleet] Add error handling: uploaded package missing from in-memory cache #82010 @skh
• Add package validator in typescript Add package validator in typescript package-spec#58 @jfsiii

[elasticmachine]

Pinging @elastic/ingest-management (Team:Ingest Management)

[exekias]

@mtojek @ycombinator @jsoriano this one should be interesting for the elastic-package tool

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

[jsoriano]

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:

• elastic-package can be used to develop, maintain and create packages (the final artifact is, or can be, a package).
• elastic-registry can be used to distribute packages.
• kibana uses packages, and can have different installation methods for that.

[ycombinator]

++ 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?

[mostlyjason]

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.

[ph]

@ycombinator I

It should be already behind auth, nothing related to ingest manager should be exposed.

[ycombinator]

It should be already behind auth, nothing related to ingest manager should be exposed.

Yes, of course it is, doh! 🤦

[skh]

Are there any safety or security considerations here?

Anything in Ingest Manager is only available for superuser users, so they can do pretty much everything in the dev console anyway, as @ph says.

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.