Add validation rule to ensure security capability depending on security-rule assets #820
Conversation
This validation rule checks if there is any security-rule asset in kibana folder. If there is any, then security capability must be defined as part of the package manifest.
mrodm
changed the title
|
test integrations |
|
Created or updated PR in integrations repository to test this version. Check elastic/integrations#11453 |
|
/test |
This version allows us to report also skipped tests.
| - junit-annotate#v2.4.1: | ||
| artifacts: "*.xml" | ||
| - junit-annotate#v2.5.0: | ||
| artifacts: "build/test-results/*.xml" |
There was a problem hiding this comment.
Ensures that this step just downloads and process the XML files from the unit test steps (linux and windows).
| if !slices.Contains(capabilities, "security") { | ||
| return specerrors.ValidationErrors{ | ||
| specerrors.NewStructuredErrorf("found security rule assets in package but security capability is missing in package manifest"), | ||
| } | ||
| } |
There was a problem hiding this comment.
Should we check that none of the observability capabilities are defined too?https://github.com/elastic/kibana/blob/77102c1854bba7253da5363168e8aafb66a34579/config/serverless.oblt.yml#L145
As this validation is defined now, it just enforces to be present security capability.
There was a problem hiding this comment.
Something like:
if slices.Contains(capabilities, "observability") || slices.Contains(capabilities, "apm") || slices.Contains(capabilities, "uptime") {
return specerrors.ValidationErrors{
specerrors.NewStructuredErrorf("found security rule assets in package but observability capabilities are defined in package manifest"),
}
}The issue here is if those capabilities are modified in Kibana or a new one is added.
There was a problem hiding this comment.
Or maybe ensure that just one capability is defined, and that one is "security" ?
Currently, it is just allowed "security":
https://github.com/elastic/kibana/blob/6f4346e4e6f61cf67db50fbe7ce0836c0317cc09/config/serverless.security.yml#L77
That would need to update good_v2 and good_v3 packages (manifests) to just have security capability.
|
/test |
💚 Build Succeeded
History
cc @mrodm |
What does this PR do?
Add a new validation rule to ensure that security capability is added in the manifest if there is any security-rule asset (in Kibana folder).
Additional changes:
Why is it important?
Currently, there are just two packages using security-rule assets. Both packages have defined the security capability.
This PR ensures that packages containing this kind of security-rule assets are not listed as available to be installed in Observability Serverless projects.
Checklist
test/packagesthat prove my change is effective.spec/changelog.yml.Related issues