-
Notifications
You must be signed in to change notification settings - Fork 775
feat: Add package registry to eck #8800
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
base: main
Are you sure you want to change the base?
Conversation
✅ Snyk checks have passed. No issues have been found so far.
💻 Catch issues earlier using the plugins for VS Code, JetBrains IDEs, Visual Studio, and Eclipse. |
🔍 Preview links for changed docs |
jsoriano
left a comment
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.
Took a quick look from the side of the team maintaining Package Registry.
It looks great, thanks for adding support for package registry in ECK, this will help many users.
Added some comments, please let us know if you need a more in-depth review from our side.
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.
Pull Request Overview
This PR adds Elastic Package Registry (EPR) support to ECK, introducing a new CRD for deploying EPR instances and enabling Kibana to reference EPR instances for Fleet package management.
- Adds
ElasticPackageRegistryCRD with controller to manage EPR deployments - Enables Kibana to associate with EPR instances via
packageRegistryReffield - Implements TLS certificate handling and CA mounting for secure communication between Kibana and EPR
Reviewed Changes
Copilot reviewed 60 out of 61 changed files in this pull request and generated 3 comments.
Show a summary per file
| File | Description |
|---|---|
pkg/apis/epr/v1alpha1/ |
New API definitions for ElasticPackageRegistry CRD |
pkg/controller/packageregistry/ |
Controller implementation for managing EPR resources |
pkg/controller/association/controller/kibana_epr.go |
Association controller for Kibana-EPR relationships |
pkg/apis/kibana/v1/kibana_types.go |
Adds packageRegistryRef field and EPR association support |
pkg/controller/kibana/ |
Updates Kibana controller to handle EPR associations and CA certificates |
test/e2e/ |
E2E tests for EPR functionality and associations |
Comments suppressed due to low confidence (1)
pkg/controller/kibana/pod_test.go:1
- The comment on line 67 says 'readinessProbe is the readiness probe for the maps container' but this function is in the packageregistry controller and should refer to the package registry container.
// Copyright Elasticsearch B.V. and/or licensed to Elasticsearch B.V. under one
Tip: Customize your code reviews with copilot-instructions.md. Create the file or learn how to get started.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
The suffix should handle this when |
Signed-off-by: Michael Montgomery <[email protected]>
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.
Did not manage to finish my review today. Wanted to leave some first feedback regardless. My first test on OCP GKE with the regular lite image failed btw see below.
Also it would probably good to resolve the comment threads that have been addressed. It is otherwise really hard to review with 126 comments on this PR.
| }, | ||
| Privileged: ptr.To(false), | ||
| ReadOnlyRootFilesystem: ptr.To(true), | ||
| RunAsNonRoot: ptr.To(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.
Error: container has runAsNonRoot and image will run as root (pod: "registry-epr-95b44664b-8rx5p_default(8d9e317f-1201-4a6b-8087-81b2e7d5e3cb)", container: package-registry)
docker image inspect ...
"Config": {
"User": "0",
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.
Openshift 4.20:
❯ kc version
Client Version: v1.32.0
Kustomize Version: v5.5.0
Server Version: v1.33.5
❯ oc version
Client Version: 4.19.12
Kustomize Version: v5.5.0
Server Version: 4.20.1
Kubernetes Version: v1.33.5
❯ kc get pod -n elastic
NAME READY STATUS RESTARTS AGE
elasticsearch-es-default-0 1/1 Running 0 5m32s
kibana-kb-688cc567dc-djs4g 1/1 Running 0 5m30s
registry-epr-798dcbb6d8-vvk5m 1/1 Running 0 5m35s
❯ kc get pod -n elastic registry-epr-798dcbb6d8-vvk5m -o yaml | yq '.spec.containers[].image'
docker.elastic.co/package-registry/distribution:lite-9.2.0
❯ docker images | grep package
docker.elastic.co/package-registry/distribution:lite-9.2.0 be2c7fb983b1 13.7GB 0B
docker.elastic.co/package-registry/distribution:lite-ubi ec9a9bd7c594 14.1GB 0B
# so the non-UBI image is root:
❯ docker inspect be2c7fb983b1 | jq '.[].Config' | grep User
"User": "0",
# the UBI image is not root:
❯ docker inspect ec9a9bd7c594 | jq '.[].Config' | grep User
(none)
Annotations on running pod:
seccomp.security.alpha.kubernetes.io/pod: runtime/default
security.openshift.io/validated-scc-subject-type: user
Security Context:
securityContext:
allowPrivilegeEscalation: false
capabilities:
drop:
- ALL
privileged: false
readOnlyRootFilesystem: true
runAsNonRoot: true
runAsUser: 1000730000
seccompProfile:
type: RuntimeDefault
Why am I not running into the same issue as you @pebrc ? I'm clearly missing something.
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.
thinking out loud here; you are not running in the same issue because in ocp a random UID non-zero is set by default (runAsUser: 1000730000). On the contrary, in k8s where I and @pebrc faced this error, the UID uses the image's one which is 0, if you don't specify runAsUser?
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.
Ok, I replicated this in a gke environment, not an openshift environment (which I thought openshift was the more restrictive, hence my testing there to replicate this)
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.
Apologies. I must have mixed up kubecontexts.
deploy/eck-stack/charts/eck-package-registry/templates/NOTES.txt
Outdated
Show resolved
Hide resolved
| return "", false, err | ||
| } | ||
| eprVersionResponse := &eprVersionResponse{} | ||
| ver, isServerless, err := info.Version("/api/epr/v1/internal/version", eprVersionResponse) |
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.
How stable is that internal API? Is there no public API we can use?
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.
some extra thoughts on that; AFAICT this path /api/epr/v1/internal/version doesn't exist at the elastic package registry service, e.g. here. It reminds me of a kibana service path but even there I get a 404. Also, do we rely support an external EPR for Kibana? AFAIK EPR doesn't need a username password and association.GetUnmanagedAssociationConnectionInfoFromSecret will look for these
| continue | ||
| } | ||
| if assoc.AssociationType() == commonv1.PackageRegistryAssociationType { | ||
| // EPR is version-agnostic, skip version compatibility check |
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.
Is that really true? Can we run any EPR with any Kibana version? I have doubts
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 am not sure if this indeed true, but since docker.elastic.co/package-registry/distribution image publishes tags following the stack version I would say to stick to how we handle versions of other stack components
Signed-off-by: Michael Montgomery <[email protected]>
Signed-off-by: Michael Montgomery <[email protected]>
Resolves #8925
Elastic Package Registry (EPR) has been highly requested to be added to ECK.
EPR does not have any references since it does not require a license nor any other application.
The following was implemented for EPR
xpack.fleet.registryUrland set the environment variableNODE_EXTRA_CA_CERTSto the path of EPR's CA which is mountedNODE_EXTRA_CA_CERTSwith a mount the controller will combine the certs appending the EPR's CA to the users specified CAThis was tested with and without setting
NODE_EXTRA_CA_CERTSusing the below manifest