Kibana: Neutral-naming in Kibana

[streamich]

Elastic has decided to move away from white/black-list terms to more inclusive allow/deny-list, this issue tracks places in Kibana we need to refactor for allow/deny-list:

Allow list:

• whitelist in HTTP server xsrf @elastic/kibana-platform (will be removed with 8.0 release)
• [ ] requestHeadersWhitelist in Elasticsearch client @elastic/kibana-platform https://github.com/elastic/kibana/pull/71610 (waiting for https://github.com/elastic/kibana/issues/71398#issuecomment-658888476)
• [ ] referrerWhitelist in HTTP server @elastic/kibana-platform https://github.com/elastic/kibana/pull/71625 (waiting for https://github.com/elastic/kibana/issues/71398#issuecomment-658888476)
• [x] in packages/kbn-config-schema/src/types/string_type.ts @elastic/kibana-platform https://github.com/elastic/kibana/pull/71607
• [ ] LICENSE_WHITELIST and DEV_ONLY_LICENSE_WHITELIST, and mockModulesWhitelist and other in /src/dev @elastic/kibana-operations
• [x] "whitelist" in actions_config.test.ts tests and whitelistError in actions plugin @elastic/kibana-alerting-services #71630
• [x] whitelistUrlSchemes in field formats @elastic/kibana-app-arch https://github.com/elastic/kibana/pull/71400
• [x] "whitelist" in src/core/MIGRATION.md @elastic/kibana-platform https://github.com/elastic/kibana/pull/71607
• [x] in kibana_utils plugin @elastic/kibana-app-arch https://github.com/elastic/kibana/pull/71400
• [x] whitelistUrlSchemes in security_solution plugin @elastic/siem https://github.com/elastic/kibana/pull/71858
• [x] filterWhitelist in uptime plugin @elastic/uptime
• requestHeadersWhitelist and referrerWhitelist @elastic/kibana-operations
• [x] in docs/maps/connect-to-ems.asciidoc @elastic/kibana-gis
• [x] xpack.actions.urlWhitelistConfigurationError translation @elastic/kibana-alerting-services #71630
• [x] in docs/user/alerting/index.asciidoc @elastic/kibana-alerting-services elastic/kibana#71630
• [x] xpack.snapshotRestore.repositoryForm.typeReadonly.urlWhitelistDescription translation in snapshot_restore plugin @elastic/es-ui https://github.com/elastic/kibana/pull/71438
• [x] URL "whitelist" for Graph in docs/management/advanced-options.asciidoc @elastic/kibana-app https://github.com/elastic/kibana/pull/71416

Deny list:

• [x] blacklist in get_root_properties_objects.ts @elastic/kibana-platform https://github.com/elastic/kibana/pull/71607
• [x] blacklist in /server/elasticsearch/client/mocks.ts @elastic/kibana-platform https://github.com/elastic/kibana/pull/71607
• [x] BlacklistForm and blacklist (in serialize.js) in Graph @elastic/kibana-app https://github.com/elastic/kibana/pull/71416
• [x] KBN_SCREENSHOT_HEADER_BLACKLIST and KBN_SCREENSHOT_HEADER_BLACKLIST_STARTS_WITH_PATTERN @elastic/kibana-reporting-services https://github.com/elastic/kibana/pull/77371
• [x] blacklist in sanitize_name.js @elastic/kibana-canvas
• [ ] actionsBlacklist in security_solution plugin ~@elastic/kibana-security~ @elastic/siem

[pgayvallet]

I got a couple questions:

• To which version(s) should this be backported?

• Do we have any consensus on new terminology / naming, for consistency?

In names (more specifically user facing config properties)

elasticsearch.requestHeadersWhitelist -> elasticsearch.requestHeadersAllowlist or elasticsearch.allowedRequestHeaders ?

when used as a verb:

This is used to whitelist the key -> This is used to allow the key or This is used to allowlist the key

[restrry]

I'd go with elasticsearch.allowedRequestHeaders, which sounds more natural and simplifies reading.

[clintandrewhall]

If it helps anyone else, I think a lot of these don't need to be "replace white and black with allow and disallow". For example, in https://github.com/elastic/kibana/pull/71522, I noticed blacklist was easily replaced with invalid. YMMV.

[jbudz]

I hate to combine two issues, but changing kibana.yml settings is a big enough hassle that it may be worth doing the snake case and stack consistency check as part of this.

[lcawl]

FYI There's some work going on to come up with a project plan to get consistency on this refactoring as much as possible across the stack. Don't have a link yet, but coming soon.

[pgayvallet]

@jbudz I guess I should put https://github.com/elastic/kibana/pull/71625 and https://github.com/elastic/kibana/pull/71610. on standby then?

[peterschretlen]

@pgayvallet yes let's hold off for now. It's amazing to see the activity this issue, but we also want to be consistent and careful with both the names, especially any changes that might affect docs, BWC, etc.

If there are internal code references we can change I think we can go ahead. Otherwise as @lcawl mentioned there's a coordinated effort being organized for neutral naming across engineering. Especially if we're going to be deprecating settings let's make sure everyone is aligned on consistent change so we only have to change it once.

[peterschretlen]

Corresponding elasticsearch issue: https://github.com/elastic/elasticsearch/issues/58087

[cnasikas]

• To which version(s) should this be backported?

I have the same question. What do you think?

[joshdover]

* [ ]  `whitelist` in HTTP server xsrf @elastic/kibana-platform

We decided not to rename this once since it is already deprecated and slated to be removed in 8.0

[paulb-elastic]

Zube action closed this, so re-opening

[elasticmachine]

Pinging @elastic/kibana-app-services (Team:AppServices)