You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardexpand all lines: docs/en/ingest-management/elastic-agent/configuration/outputs/output-logstash.asciidoc
+5
Original file line number
Diff line number
Diff line change
@@ -32,6 +32,11 @@ To receive the events in {ls}, you also need to create a {ls} configuration pipe
32
32
The {ls} configuration pipeline listens for incoming {agent} connections,
33
33
processes received events, and then sends the events to {es}.
34
34
35
+
Please be aware that the structure of the documents sent from {agent} to {ls} must not be modified by the pipeline.
36
+
We recommend that the pipeline doesn’t edit or remove the fields and their contents.
37
+
Editing the structure of the documents coming from {agent} can prevent the {es} ingest pipelines associated to the integrations in use to work correctly.
38
+
We cannot guarantee that the {es} ingest pipelines associated to the integrations using {agent} can work with missing or modified fields.
39
+
35
40
The following {ls} pipeline definition example configures a pipeline that listens on port `5044` for
36
41
incoming {agent} connections and routes received events to {es}.
If your HTTP proxy requires authentication, you can include the
21
+
credentials in the URI, such as `https://username:password@your-nat-gateway.corp.net`,
22
+
only when using HTTPS.
23
+
20
24
== What information is sent to the {package-registry}?
21
25
22
26
In production environments, {kib}, through the {fleet} plugin, is the only service interacting with the {package-registry}. Communication happens when interacting with the Integrations UI, and when upgrading {kib}. The shared information is about discovery of Elastic packages and their available versions. In general, the only deployment-specific data that is shared is the {kib} version.
Review important information about the {fleet} and {agent} 8.17.2 release.
32
+
33
+
[discrete]
34
+
[[security-updates-8.17.2]]
35
+
=== Security updates
36
+
37
+
{fleet-server}::
38
+
* Upgrade `golang.org/x/net` to v0.34.0 and `golang.org/x/crypto` to v0.32.0. {fleet-server-pull}4405[#4405]
39
+
40
+
41
+
[discrete]
42
+
[[enhancements-8.17.2]]
43
+
=== Enhancements
44
+
45
+
{agent}::
46
+
* Upgrade NodeJS for Heartbeat to LTS v18.20.6. {agent-pull}6641[#6641]
47
+
48
+
[discrete]
49
+
[[bug-fixes-8.17.2]]
50
+
=== Bug fixes
51
+
52
+
{agent}::
53
+
* Emit variables even if provider data is empty from the start. {agent-pull}6598[#6598]
54
+
55
+
// end 8.17.2 relnotes
56
+
25
57
// begin 8.17.1 relnotes
26
58
27
59
[[release-notes-8.17.1]]
@@ -40,9 +72,26 @@ impact to your application.
40
72
{agent}::
41
73
* {agent} Docker images for {ecloud} have been reverted from having been based off of Ubuntu 24.04 to being based off of Ubuntu 20.04. This is to ensure compatibility with {ece}, support for new Wolfi-based images, and for GNU C Library (glibc) compatibility. {agent-pull}6393[#6393]
42
74
43
-
//*Impact* +
44
-
//<Describe how users should mitigate the change.> For more information, refer to {fleet-guide}/fleet-server.html[Fleet Server].
45
-
//====
75
+
[discrete]
76
+
[[known-issues-8.17.1]]
77
+
=== Known issues
78
+
79
+
[[known-issue-1671]]
80
+
.{kib} out of memory crashes on 1 GB {ecloud} {kib} instances using {elastic-sec} view
81
+
[%collapsible]
82
+
====
83
+
84
+
*Details*
85
+
86
+
{ecloud} deployments that use the smallest available {kib} instance size of 1 GB may crash due to out of memory errors when the Security UI is loaded.
87
+
88
+
*Impact* +
89
+
90
+
The root cause is inefficient memory allocation, and this is exacerbated when the prebuilt security rules package is installed on the initial load of the {elastic-sec} UI.
91
+
92
+
As a workaround, you can upgrade your deployment to 8.17.1 in which this issue has been resolved by https://github.com/elastic/kibana/pull/208869[#208869] and https://github.com/elastic/kibana/pull/208475[#208475].
Copy file name to clipboardexpand all lines: docs/en/ingest-management/security/fleet-roles-and-privileges.asciidoc
+31-13
Original file line number
Diff line number
Diff line change
@@ -7,39 +7,57 @@ Assigning the {kib} feature privileges `Fleet` and `Integrations` grants access
7
7
8
8
`all`:: Grants full read-write access.
9
9
`read`:: Grants read-only access.
10
+
`none`:: No access is granted.
10
11
12
+
Take advantage of these privilege settings by:
13
+
14
+
* <<fleet-roles-and-privileges-built-in,Using an {es} built-in role>>
15
+
* <<fleet-roles-and-privileges-create,Creating a new role>>
16
+
17
+
[discrete]
18
+
[[fleet-roles-and-privileges-built-in]]
19
+
== Built-in roles
20
+
21
+
{es} comes with built-in roles that include default privileges.
22
+
23
+
`editor`::
11
24
The built-in `editor` role grants the following privileges, supporting full read-write access to {fleet} and Integrations:
12
25
13
-
* {Fleet}: `All`
14
-
* Integrations: `All`
26
+
* {Fleet}: `all`
27
+
* Integrations: `all`
15
28
29
+
`viewer`::
16
30
The built-in `viewer` role grants the following privileges, supporting read-only access to {fleet} and Integrations:
17
31
18
-
* {Fleet}:: `None`
19
-
* Integrations:: `Read`
32
+
* {Fleet}: `read`
33
+
* Integrations: `read`
20
34
21
-
You can also create a new role that can be assigned to a userto grant access to {fleet} and Integrations.
35
+
You can also create a new role that can be assigned to a user, in order to grant more specific levels of access to {fleet} and Integrations.
22
36
23
37
[discrete]
24
38
[[fleet-roles-and-privileges-create]]
25
39
== Create a role for {fleet}
26
40
27
-
To create a new role with full access to use and manage {fleet} and Integrations:
41
+
To create a new role with access to {fleet} and Integrations:
28
42
29
43
. In {kib}, go to **Management -> Stack Management**.
30
44
. In the **Security** section, select **Roles**.
31
45
. Select **Create role**.
32
46
. Specify a name for the role.
33
47
. Leave the {es} settings at their defaults, or refer to {ref}/security-privileges.html[Security privileges] for descriptions of the available settings.
34
-
. In the {kib} section, select **Add Kibana privilege**.
35
-
. In the **Spaces** menu, select *** All Spaces**. Since many Integrations assets are shared across spaces, the users needs the {kib} privileges in all spaces.
48
+
. In the {kib} section, select **Assign to space**.
49
+
. In the **Spaces** menu, select *** All Spaces**. Since many Integrations assets are shared across spaces, the users need the {kib} privileges in all spaces.
36
50
. Expand the **Management** section.
37
-
. Set **Fleet** privileges to **All**.
38
-
. Set **Integrations** privileges to **All**.
51
+
. Choose the access level that you'd like the role to have with respect to {fleet} and integrations:
39
52
53
+
.. To grant the role full access to use and manage {fleet} and integrations, set both the **Fleet** and **Integrations** privileges to `All`.
54
+
+
40
55
[role="screenshot"]
41
-
image::images/kibana-fleet-privileges.png[Kibana privileges flyout showing Fleet and Integrations set to All]
56
+
image::images/kibana-fleet-privileges-all.png[Kibana privileges flyout showing Fleet and Integrations set to All]
42
57
43
-
To create a read-only user for Integrations, follow the same steps as above but set the **Fleet** privileges to **None** and the **Integrations** privileges to **Read**.
58
+
.. Similarly, to create a read-only user for {fleet} and Integrations, set both the **Fleet** and **Integrations** privileges to `Read`.
59
+
+
60
+
[role="screenshot"]
61
+
image::images/kibana-fleet-privileges-read.png[Kibana privileges flyout showing Fleet and Integrations set to All]
44
62
45
-
Read-only access to {fleet} is not currently supported but is planned for development in a later release.
63
+
Once you've created a new role you can assign it to any {es} user. You can edit the role at any time by returning to the **Roles** page in {kib}.
0 commit comments