Skip to content

Bootstrap entitlements for testing #129268

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

Open
wants to merge 40 commits into
base: main
Choose a base branch
from

Conversation

prdoyle
Copy link
Contributor

@prdoyle prdoyle commented Jun 11, 2025

Add entitlement enforcement during ordinary unit tests.

This does not yet cover tests that run ES nodes; only ordinary unit tests.

See ES-11597.

@prdoyle prdoyle self-assigned this Jun 11, 2025
@prdoyle prdoyle added >test Issues or PRs that are addressing/adding tests test-windows Trigger CI checks on Windows auto-backport Automatically create backport pull requests when merged v8.19.0 v9.1.0 :Core/Infra/Entitlements Entitlements infrastructure labels Jun 11, 2025
@prdoyle prdoyle force-pushed the bootstrap-entitlements-for-testing branch 4 times, most recently from e1166dc to d331569 Compare June 17, 2025 12:34
prdoyle added 4 commits June 17, 2025 09:15
…source.

Using getResource makes this sensitive to unrelated classpath entries,
such as the entitlement bridge library, that get prepended to the classpath.
Using the root logger makes this sensitive to unrelated
logging, such as from the entitlement library.
…titlements.

Taking the actual module name from the class doesn't work in tests,
where those classes are loaded from the classpath and so their module
info is misleading.
@prdoyle prdoyle force-pushed the bootstrap-entitlements-for-testing branch 2 times, most recently from 7bcefba to ba15751 Compare June 17, 2025 14:37
@elasticsearchmachine
Copy link
Collaborator

Pinging @elastic/es-core-infra (Team:Core/Infra)

Copy link
Contributor

@ldematte ldematte left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this looks good; I've skipped configureEntitlements as I have far from the necessary gradle knowledge.
My main concern is with TestPolicyManager/PolicyManager (see comments)

boolean isTriviallyAllowingTestCode;

/**
* We don't have modules in tests, so we can't use the inherited map of entitlements per module.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is a thing that might be confusing, in the future and/or while debugging.
In general, there are a lot of other things in PolicyManager that do not make sense in TestPolicyManager, e.g. everything related to modules like SYSTEM_LAYER_MODULES, SERVER_LAYER_MODULES, etc.)
Can we split this better? E.g. make PolicyManager abstract and move everything that is not common to TestPolicyManager to another subclass ProductionPolicyManager (or ElasticsearchPolicyManager)?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Or any other thing really; you know I usually prefer to avoid inheritance, and inject strategies into a common class. I suggested another subclass here as it seems to be the easier approach.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Composition > inheritance of abstract classes > inheritance of concrete classes. 😂

That's a great suggestion.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thinking back... I think the reason I didn't do this in the first place was that my goal was to avoid adding complexity to production code solely for the sake of testing. From the POV of the production code, the refactoring we've already done can be justified as a way to separate concerns and have different responsibilities in different classes, which is a desirable property even without testing; but I felt like there's no reason to have an AbstractPolicyManager superclass to PolicyManager besides testing, so I shied away from it.

I don't feel strongly about it though.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Technically we would just shuffle code around, moving some things from PolicyManager to AbstractPolicyManager, but...

avoid adding complexity to production code solely for the sake of testing

Yes, that's true and it's always a good principle; however we do this all the time in ES :) not a justification, just a point. It's true that we would add some complexity to production code, but we would separate a concern; the concrete PolicyManager would be effectively a ModuleBasedPolicyManager, if you think about it: I believe the things that will be moved there that we don't want/need to share with the TestPolicyManager are those related to modules.
And I'd weigh in the "clarity" (or confusion) of having unused stuff in TestPolicyManager, especially if someone is debugging a entitlement exception in a unit test.

We can maybe try it in a separate PR (even a follow-up if we are tight in time to close this)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok that all makes sense. Let's do this in another PR.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

BTW I love the name ModuleBasedPolicyManager.

@@ -18,6 +18,7 @@ org.apache.httpcomponents.httpasyncclient:
- manage_threads
unboundid.ldapsdk:
- set_https_connection_properties # TODO: review if we need this once we have proper test coverage
- inbound_network # For com.unboundid.ldap.listener.LDAPListener
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Really? Is this something we use? Looks like an unnecessary security hazard...

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure. It was definitely exercised by the unit test.

I wonder who would know. Does our team own x-pack-core?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's kind of unrelated, so if a test hits it it's worth adding it. But I think this is an anomaly, and needs to be investigate (later -- I'm completely fine adding this now to make progress!)
By whoever "owns" x-pack-code, which is going to be really tricky. I guess since this is related to authN/authZ this should be security?

@prdoyle prdoyle force-pushed the bootstrap-entitlements-for-testing branch 2 times, most recently from b7e4315 to 6c1b7fd Compare June 18, 2025 14:42
prdoyle and others added 5 commits June 18, 2025 11:32
These are alread set in ElasticsearchJavaBasePlugin.
For serverless, those project dependencies don't exist, and we'll need
to add the dependencies differently, using Maven coordinates.
It's typically a very very long string, which made Windows angry.
@prdoyle prdoyle force-pushed the bootstrap-entitlements-for-testing branch from 6c1abaf to 26baece Compare June 18, 2025 17:37
@prdoyle prdoyle force-pushed the bootstrap-entitlements-for-testing branch from c8b1f17 to b2bbf94 Compare June 18, 2025 19:19
@prdoyle prdoyle force-pushed the bootstrap-entitlements-for-testing branch from a81059a to 4c9acbb Compare June 20, 2025 12:36
prdoyle and others added 4 commits June 20, 2025 10:21
@prdoyle prdoyle enabled auto-merge (squash) June 20, 2025 16:19
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
auto-backport Automatically create backport pull requests when merged :Core/Infra/Entitlements Entitlements infrastructure Team:Core/Infra Meta label for core/infra team >test Issues or PRs that are addressing/adding tests test-windows Trigger CI checks on Windows v8.19.0 v9.1.0
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants