-
Notifications
You must be signed in to change notification settings - Fork 24.9k
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
[Connector APIs] Enforce index prefix for managed connectors #117778
base: main
Are you sure you want to change the base?
[Connector APIs] Enforce index prefix for managed connectors #117778
Conversation
ConnectorStatus status = getConnectorStatusFromSearchResult(connector); | ||
|
||
// If connector was connected already, change its status to CONFIGURED as we need to re-connect | ||
if (status == ConnectorStatus.CONNECTED) { |
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 realised we would always set status CONFIGURED
once changing the is_native
flag - it's likely wrong, we got here because I copied logic from Kibana initially https://github.com/elastic/kibana/pull/175536/files
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.
nice catch.
- match: { results.0.id: "connector-a" } | ||
- match: { results.0.index_name: "search-1-test" } | ||
- match: { results.0.language: "pl" } | ||
- match: { results.0.id: "connector-b" } |
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.
content-
index is first alphabetically so order of list API
results changes (we sort by index_name by default)
Pinging @elastic/search-eng (Team:SearchOrg) |
Pinging @elastic/search-extract-and-transform (Team:Search - Extract & Transform) |
Rest compatibility failing because it's not a backward compatible change |
the relevant backwards compatibility change proposal is here: https://github.com/elastic/dev/issues/2932 |
This is a workaround for failing bcc changes #118260 (should be merged and backported first) |
@elasticmachine merge upstream |
@elasticmachine merge upstream |
Hi @jedrazb, I've created a changelog YAML for you. |
…of github.com:jedrazb/elasticsearch into connector-apis-add-native-connector-index-name-checks
@@ -91,8 +91,6 @@ tests: | |||
- class: org.elasticsearch.search.StressSearchServiceReaperIT | |||
method: testStressReaper | |||
issue: https://github.com/elastic/elasticsearch/issues/115816 | |||
- class: org.elasticsearch.xpack.application.connector.ConnectorIndexServiceTests |
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.
The ConnectorIndexServiceTests
has been running fine for almost a year, I saw seemingly unrelated issue in the failed buildkite run that led to muting 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.
Looks reasonable to me. Are there any BWC cases that we should be aware of/test? Also are there any docs updates required?
...c/main/java/org/elasticsearch/xpack/application/connector/action/ConnectorActionRequest.java
Show resolved
Hide resolved
...c/main/java/org/elasticsearch/xpack/application/connector/action/ConnectorActionRequest.java
Show resolved
Hide resolved
// Ensure attached content index is prefixed correctly | ||
if (isNative && indexName != null && isValidManagedConnectorIndexName(indexName) == false) { |
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.
// Ensure attached content index is prefixed correctly | |
if (isNative && indexName != null && isValidManagedConnectorIndexName(indexName) == false) { | |
// Ensure attached content index is prefixed correctly | |
boolean doesNotHaveContentPrefix = indexName != null && isValidManagedConnectorIndexName(indexName) == false | |
if (isNative && doesNotHaveContentPrefix) { |
Rationale: Cognitive load is what matters: complex conditionals
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.
Good read! Thank you for linking
|
||
// If connector was connected already, change its status to CONFIGURED as we need to re-connect | ||
if (status == ConnectorStatus.CONNECTED) { | ||
status = ConnectorStatus.CONFIGURED; |
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.
Should this transition be guarded/validated through ConnectorStateMachine?
Changes
For
9.x
, Connectors will be deployed in an agentless environment. This means the Fleet service account will now be responsible for generating API keys, enabling the connector to read/write from connector state indices and interact with thecontent
index (where data is synced by connector from the 3rd party data source).To maintain granular permissions and avoid granting the Fleet service account access to all indices (e.g.,
*
), it has been decided to restrict content index names to those prefixed withcontent-*
.This PR introduces restrictions and validations to ensure that Elastic-managed connectors (with
isNative: true
flag) can only attach to indices with thecontent-
prefix. We validate index name on:content-
then update the connector to native connector)Additionally, the
ConnectorIndexServiceTests
have been unmuted. These tests have been stable for about a year. A few flaky runs (IMO not related to our test logic) had caused them to be muted earlier, but they now run successfully. We need to keep them active.BCC approval
Relates to
[Search Connectors] introduce "content-*" prefix requirement for Elastic-managed connectors
dev issue that got green light from bcc.Verification