-
Notifications
You must be signed in to change notification settings - Fork 25.3k
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
base: main
Are you sure you want to change the base?
Conversation
e1166dc
to
d331569
Compare
…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.
7bcefba
to
ba15751
Compare
Pinging @elastic/es-core-infra (Team:Core/Infra) |
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 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)
build-tools/src/main/java/org/elasticsearch/gradle/test/TestBuildInfoPlugin.java
Outdated
Show resolved
Hide resolved
server/src/test/java/org/elasticsearch/bootstrap/WithoutEntitlementsMetaTests.java
Show resolved
Hide resolved
...ramework/src/main/java/org/elasticsearch/entitlement/bootstrap/TestEntitlementBootstrap.java
Outdated
Show resolved
Hide resolved
boolean isTriviallyAllowingTestCode; | ||
|
||
/** | ||
* We don't have modules in tests, so we can't use the inherited map of entitlements per module. |
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.
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
)?
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.
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.
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.
Composition > inheritance of abstract classes > inheritance of concrete classes. 😂
That's a great suggestion.
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 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.
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.
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)
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 that all makes sense. Let's do this in another PR.
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.
BTW I love the name ModuleBasedPolicyManager
.
.../framework/src/main/java/org/elasticsearch/entitlement/runtime/policy/TestPolicyManager.java
Show resolved
Hide resolved
@@ -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 |
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.
Really? Is this something we use? Looks like an unnecessary security hazard...
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'm not sure. It was definitely exercised by the unit test.
I wonder who would know. Does our team own x-pack-core?
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.
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?
b7e4315
to
6c1b7fd
Compare
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.
6c1abaf
to
26baece
Compare
c8b1f17
to
b2bbf94
Compare
a81059a
to
4c9acbb
Compare
We already get the "needle" in the form of a URI, so this skips a step, and has the benefit of also working on Windows.
Add entitlement enforcement during ordinary unit tests.
This does not yet cover tests that run ES nodes; only ordinary unit tests.
See ES-11597.