Skip to content
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

Minor fixes for least privilege environments #209

Merged
merged 6 commits into from
Aug 14, 2024

Conversation

schnatterer
Copy link
Member

@schnatterer schnatterer commented Jul 24, 2024

A collection of fixes that are necessary to run GOP in environments without cluster-admin privileges.

@schnatterer schnatterer changed the title Get clusterBindAddress only when necessary Minor fixes for least privilege environments Jul 25, 2024
@schnatterer schnatterer force-pushed the feature/cluster-bind-address-on-demand branch 2 times, most recently from c5073e8 to 3015d2e Compare July 25, 2024 13:04
@schnatterer schnatterer force-pushed the feature/cluster-bind-address-on-demand branch 7 times, most recently from c013e8b to 30d57b2 Compare August 12, 2024 14:22
Getting it always might cause the following error on clusters with
non-admin privileges:

nodes is forbidden: User "xyz" cannot list resource "nodes" in API group
 "" at the cluster scope

The change removes the need to query the clusterBindAddress at the
beginning.

This way envs with less privileges get the option to either run GOP
inside k8s or pass external jenkins and scmm urls.
Otherwise, applying GOP fails with 404.
Failed on Jenkins, likely due to a network glitch.

[2024-08-08T08:30:48.982Z]  139 | >>> RUN gpg --batch --keyserver hkps://keys.openpgp.org --recv-keys 5ED46A6721D365587791E2AA783FCD8E58BCAFBA # madler@alumni.caltech.edu

[2024-08-08T08:30:48.982Z]  140 |     RUN gpg --batch --verify zlib.tar.gz.asc zlib.tar.gz

[2024-08-08T08:30:48.982Z]  141 |     RUN mkdir zlib && tar -xvzf zlib.tar.gz -C zlib --strip-components 1 && \

[2024-08-08T08:30:48.982Z] --------------------

[2024-08-08T08:30:48.982Z] ERROR: failed to solve: process "/bin/sh -c gpg --batch --keyserver hkps://keys.openpgp.org --recv-keys 5ED46A6721D365587791E2AA783FCD8E58BCAFBA # madler@alumni.caltech.edu" did not complete successfully: exit code: 2
That is, run groovy scrips in dev image without prior compilation,
overcoming the issue that Micronaut's dependency injection relies on
statically compiled class files with seems incompatible with groovy
scripting/interpretation (without prior compilation).

The Micronaut Classloader relies on compiled classes being loaded by
java classloader.

ApplicationContext.run()
..
SoftServiceLocader.collectDynamicServices()

Class.forName()
This uses the Java classloader which does not know the Groovy-only
classes when interpreting (scripting) without prior compilation.

This can be overcome by keeping the $xyz classes created by Micronaut's
annotation processor inside the dev image and setting the Groovy
classloader like so:

ApplicationContext.run(Thread.currentThread().contextClassLoader).

However, with TRACE logs enabled for "io.micronaut.context" we can
then see stacktraces like this in the log.

NoClassDefFoundError: com/cloudogu/gitops/jenkins/GlobalPropertyManager
at com.cloudogu.gitops.jenkins.$GlobalPropertyManager$Definition$Reference.getBeanType(Unknown Source)

Eventually we fail with
No bean of type [com.cloudogu.gitops.config.ApplicationConfigurator] exists. Make sure the bean is not disabled by bean requirements (enable trace logging for 'io.micronaut.context.condition' to check) and if the bean is enabled then ensure the class is declared a bean and annotation processing is enabled (for Java and Kotlin the 'micronaut-inject-java' dependency should be configured as an annotation processor).
at io.micronaut.context.DefaultBeanContext.newNoSuchBeanException(DefaultBeanContext.java:2773)
at io.micronaut.context.DefaultApplicationContext.newNoSuchBeanException(DefaultApplicationContext.java:292)
at io.micronaut.context.DefaultBeanContext.resolveBeanRegistration(DefaultBeanContext.java:2735)

So we choose the pragmatic workaround of instantiating all classes
manually when running the dev image.
Harder to maintain, but at least a working solution.
This is helpful when running GOP as scripts from dev image but the JAR
resides somewhere else.

For example, when applying GOP from a Jenkins job with docker.image
.inside but mounting your own Groovy Scripts or when running locally

CLASSPATH=target/xyz.jar scripts/apply-ng.sh
@schnatterer schnatterer force-pushed the feature/cluster-bind-address-on-demand branch from 30d57b2 to 8f91192 Compare August 14, 2024 11:30
@pmarkiewka pmarkiewka merged commit 30237ab into main Aug 14, 2024
1 check passed
@pmarkiewka pmarkiewka deleted the feature/cluster-bind-address-on-demand branch August 14, 2024 14:14
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants