Open a03nikki opened 2 years ago
@a03nikki aside from support for ECK (ease of packaging etc), would the users in these environments be hosting a http server to disk out the binaries and artifacts? is this (https://www.elastic.co/guide/en/fleet/current/air-gapped.html#host-artifact-registry) not a viable path for support in an air-gap environment?
Sure, but this issue is to deploy the elastic package registry (and probably the artifact registry too) as part of the ECK operator and implement custom resources to manage it.
I just found that ECK doesn't support this and after totally setting up fleet server and elastic agents, I'm going to have to either:
Option #2 seems extremely painful. It would be nice if it was just a part of the ECK operator...
So the answer to your question,
would the users in these environments be hosting a http server to disk out the binaries and artifacts?
The answer is no. Assume nothing, and give users like me a way to deploy both through the operator.
Proposal
ECK has the ability to run an Elastic Maps Server locally. We should be able to do the same for the Elastic Package Registry (EPR).
Use case. Why is this important?
The documentation for Fleet and Agent includes how to host your own Elastic Package Registry which involves running a docker container. It would be great if ECK could orchestrate the deployment of a EPR server.
This is important for air-gaped "off-line" and limited internet access environments. Internet access can be limited by any number of reasons including (a) low bandwidth, (b) policies of external internet access is denied until exception justified, (c) deployment processes that require assets be scanned, tested, and checked against CVE lists before being uploaded to an internal container or package registry for use, etc.