Network sec: rebrand and new cloud UX, IP filters in serverless #1785
Conversation
shainaraskas
changed the title
There was a problem hiding this comment.
Amazing work @shainaraskas to me it improves clarity as the terminology changes make sense. The reorganization also LGTM. With the minor fixes, it provides excellent documentation update.
There was a problem hiding this comment.
Amazing improvements here!! I love the new structure!
I have added some comments for your review, feel free to ignore any of them.
In general the majority of my comments are about:
-
You have used multiple times
by default all your deployments are accessible over the internetto mean thatall access is allowed, oris accessible without restrictions. The first statement is in my opinion not accurate or doesn't add any value (this is explained more in other comments). -
When dealing with
IP filtersthe termsIP filters,traffic filtersand even the usage of the wordrulesfeel a bit randomly used, and could be misleading.
Most probably I'm missing background in some of my comments, so feel free to correct me!
Co-authored-by: Edu González de la Herrán <[email protected]>
Co-authored-by: Edu González de la Herrán <[email protected]>
…to network-sec-core
There was a problem hiding this comment.
Considering network security is a wide topic, should we include in the introduction a link to TLS encryption / HTTPS in case the reader is interested on that topic more than filtering traffic?
|
|
||
| Traffic filtering allows you to limit how your deployments and clusters can be accessed. Add another layer of security to your installation and deployments by restricting inbound traffic to only the sources that you trust. | ||
| Network security allows you to control how your deployments and clusters can be accessed. Add another layer of security to your installation and deployments by restricting inbound traffic to only the sources that you trust. |
There was a problem hiding this comment.
We mention only inbound traffic in that introductory sentence. I think it's all right because the majority of features are to control inbound traffic, but we also control outbound traffic in some use cases (ECH, k8s network policies, not sure if in self-managed).
Not sure if it's worthy to mention both in this intro or just keep inbound. FYI :)
There was a problem hiding this comment.
In this doc I have some mixed feelings.
The repetition multiple times of IP filter policy or IP filtering rule set feels a bit weird, first of all because I don't understand or perceive the differences (if there are), and because in the API examples that's not clear either (you explain very well that the API hasn't implemented conceptual differences, though, which helps).
I try to understand this with the terminology table, but IP filter policy doesn't appear in the table...
What's the reason to have this so many times? To me it would feel better to leave one term always, even if in one of the products the same feature is named in a different way. Otherwise just explain it at the beginning and use one term.
Reading the or so many times makes me wonder.... are both the same? what do the writer wants to transmit with this?
There was a problem hiding this comment.
Update: after having learned by reading multiple times I see that the terms are equivalent.
- I think we just need to explain at the beginning of the page that a policy consists of multiple rules, and in ECE and the API examples these policies are still called
rule sets. - Also each rule relates with a source IP address or CIDR range, and they referred as the sources in the API.
Then in the text of the page we can probably rely on policies term only, as it's the newer term. Or keeping both, but with a clear note at the beginning of the page that clarifies that IP filter policy and IP filtering rule set mean the same from logical entity point of view.
| In {{ecloud}}, terminology related to network security has changed to more accurately reflect functionality. Terminology in the related APIs has not yet been updated. | ||
|
|
||
| | {{ecloud}} concept | API terminology | | ||
| | --- | --- | | ||
| | Network security | Traffic filters | | ||
| | Network security policy | Traffic filter or IP filtering rule set | | ||
| | IP filter source | IP filter rule | | ||
| | Private connection | Private link traffic filter | | ||
| | VPC filter | Private link filter source | | ||
|
|
There was a problem hiding this comment.
I think this section is a great idea but I have to say something.... I didn't understand it at first sight, and after spending time on it there are still unclear parts to me :(
Maybe we can discuss that in private, and as soon as I get a better view maybe I can propose something specific.
The note we have in the new landing page might help here to understand this better. It says:
- The network security feature was formerly referred to as traffic filtering.
- Network security policies were formerly referred to as traffic filter rules.
With that in mind, the exact terms used in this table don't match, which doesn't help.
I think some extra narrative + the table would be ideal here, or even use only narrative with the most important messages (I'm sharing here some examples).
It feels that users need to learn this, which isn't included in the page:
A policy consists of multiple rules (that's why it's called also a rule set), and each rule is associated with an IP address (that's why individual rules are referred as IP filter sources).
^^ Not sure if my understanding is totally accurate there.
Maybe after something like that we can describe the table to understand better the API examples.
This PR updates the core pages related to traffic filtering to reflect the new ux (issue: https://github.com/elastic/platform-docs-team/issues/682)
This is PR 1 of
2 or 3many. The first PR will capture the core changes needed to ship the feature. Subsequent PRs will update references to traffic filters other places in the docs, do any necessary API reference cleanup, etc.Followup PRs to merge right after:
any order after:
independent (ship anytime after the feature is released):
Summary
This PR is pretty big, so you can use the links below to review it
Key changes
Network security and network security policies
Pulled policy/rule logic out of this page and into dedicated pages for Elastic Cloud and ECE
IP filters
Rebranded as "IP filter network security policies"
Updated all flows impacted by UX changes
snippet: wayfinding to network security page
Private connections
repositioned them as a connectivity strategy with VCPE filtering optional for everything but Azure
used deployment aliases to test/connect privatelink for consistency
snippets: wayfinding to network security page, associate filter, private url structure, find endpoint, fleet
used deployment aliases to test/connect privatelink for consistency
snippets: wayfinding to network security page, associate filter, private url structure, find endpoint, fleet
used deployment aliases to test/connect privatelink for consistency
snippets: wayfinding to network security page, associate filter, private url structure, find endpoint, fleet
Remote clusters
Access deployments of another Elastic Cloud organization
deploy-manage/remote-clusters/ec-remote-cluster-other-ess.md
Secondary changes
todo: serverless reference doc URL
Updated references to traffic filters to "network security" or "IP filtering and private connections" as needed, added IP filtering to the list of security features for serverless
deploy-manage/_snippets/ecloud-security.md
snippets: security in elastic cloud, features for cluster communication and network security, feature comparison
snippets: features for cluster communication and network security, feature comparison
Open questions
Is the umbrella term for private connection filters "VCPE filtering" (e.g. "add a private connection, then filter traffic to your deployment using VCPE filters")? Will this term be used for GCP?ANSWER: It's "VPC filtering"
For Azure, is associating a private connection policy with a deployment required, or optional?ANSWER: technically optional but strongly recommended
For Azure inter-region private links, what region should the associated policy be created in?
ANSWER: same region as the deployment
SR TODO
[ ] more visibility to azure inter-region private links