diff --git a/docs/integrations-index.asciidoc b/docs/integrations-index.asciidoc index 842d898759d..af6d2ef65e5 100644 --- a/docs/integrations-index.asciidoc +++ b/docs/integrations-index.asciidoc @@ -80,7 +80,7 @@ include::input-apm.asciidoc[] include::configure/index.asciidoc[leveloffset=+1] -include::secure-agent-communication.asciidoc[] +include::secure-comms.asciidoc[] include::monitor-apm-server.asciidoc[] @@ -131,9 +131,6 @@ include::./legacy/overview.asciidoc[] include::./legacy/getting-started-apm-server.asciidoc[] -:beat-specific-security: {docdir}/legacy/security.asciidoc -include::{libbeat-dir}/shared-securing-beat.asciidoc[leveloffset=+1] - // include::./legacy/breaking-changes.asciidoc[leveloffset=+1] include::./legacy/redirects.asciidoc[] diff --git a/docs/legacy/api-keys.asciidoc b/docs/legacy/api-keys.asciidoc index 82edb7cf64c..8093843c674 100644 --- a/docs/legacy/api-keys.asciidoc +++ b/docs/legacy/api-keys.asciidoc @@ -1,6 +1,6 @@ [role="xpack"] [[beats-api-keys]] -== Grant access using API keys +=== Grant access using API keys Instead of using usernames and passwords, you can use API keys to grant access to {es} resources. You can set API keys to expire at a certain time, @@ -16,7 +16,7 @@ You can create as many API keys per user as necessary. [float] [[beats-api-key-publish]] -=== Create an API key for writing events +==== Create an API key for writing events In {kib}, navigate to **{stack-manage-app}** > **API keys** and click **Create API key**. @@ -63,7 +63,7 @@ output.elasticsearch: [float] [[beats-api-key-monitor]] -=== Create an API key for monitoring +==== Create an API key for monitoring In {kib}, navigate to **{stack-manage-app}** > **API keys** and click **Create API key**. @@ -107,7 +107,7 @@ monitoring.elasticsearch: [float] [[beats-api-key-es]] -=== Create an API key with {es} APIs +==== Create an API key with {es} APIs You can also use {es}'s {ref}/security-api-create-api-key.html[Create API key API] to create a new API key. For example: @@ -140,7 +140,7 @@ See the {ref}/security-api-create-api-key.html[Create API key] reference for mor [[learn-more-api-keys]] [float] -=== Learn more about API keys +==== Learn more about API keys See the {es} API key documentation for more information: diff --git a/docs/legacy/copied-from-beats/docs/security/linux-seccomp.asciidoc b/docs/legacy/copied-from-beats/docs/security/linux-seccomp.asciidoc deleted file mode 100644 index e14032c29a5..00000000000 --- a/docs/legacy/copied-from-beats/docs/security/linux-seccomp.asciidoc +++ /dev/null @@ -1,93 +0,0 @@ -[[linux-seccomp]] -== Use Linux Secure Computing Mode (seccomp) - -beta[] - -On Linux 3.17 and later, {beatname_uc} can take advantage of secure computing -mode, also known as seccomp. Seccomp restricts the system calls that a process -can issue. Specifically {beatname_uc} can load a seccomp BPF filter at process -start-up that drops the privileges to invoke specific system calls. Once a -filter is loaded by the process it cannot be removed. - -The kernel exposes a large number of system calls that are not used by -{beatname_uc}. By installing a seccomp filter, you can limit the total kernel -surface exposed to {beatname_uc} (principle of least privilege). This minimizes -the impact of unknown vulnerabilities that might be found in the process. - -The filter is expressed as a Berkeley Packet Filter (BPF) program. The BPF -program is generated based on a policy defined by {beatname_uc}. The policy -can be customized through configuration as well. - -A seccomp policy is architecture specific due to the fact that system calls vary -by architecture. {beatname_uc} includes an allowlist seccomp policy for the -AMD64 and 386 architectures. You can view those policies -https://github.com/elastic/beats/tree/{branch}/libbeat/common/seccomp[here]. - -[float] -[[seccomp-policy-config]] -=== Seccomp Policy Configuration - -The seccomp policy can be customized through the configuration policy. This is -an example blocklist policy that prohibits `execve`, `execveat`, `fork`, and -`vfork` syscalls. - -[source,yaml] ----- -seccomp: - default_action: allow <1> - syscalls: - - action: errno <2> - names: <3> - - execve - - execveat - - fork - - vfork ----- -<1> If the system call being invoked by the process does not match one of the -names below then it will be allowed. -<2> If the system call being invoked matches one of the names below then an -error will be returned to caller. This is known as a blocklist policy. -<3> These are system calls being prohibited. - -These are the configuration options for a seccomp policy. - -*`enabled`*:: On Linux, this option is enabled by default. To disable seccomp -filter loading, set this option to `false`. - -*`default_action`*:: The default action to take when none of the defined system -calls match. See <> for the full list of -values. This is required. - -*`syscalls`*:: Each object in this list must contain an `action` and a list of -system call `names`. The list must contain at least one item. - -*`names`*:: A list of system call names. The system call name must exist for -the runtime architecture, otherwise an error will be logged and the filter will -not be installed. At least one system call must be defined. - -[[seccomp-policy-config-action]] -*`action`*:: The action to take when any of the system calls listed in `names` -is executed. This is required. These are the available action values. The -actions that are available depend on the kernel version. - -- `errno` - The system call will return `EPERM` (permission denied) to the - caller. -- `trace` - The kernel will notify a `ptrace` tracer. If no tracer is present - then the system call fails with `ENOSYS` (function not implemented). -- `trap` - The kernel will send a `SIGSYS` signal to the calling thread and not - execute the system call. The Go runtime will exit. -- `kill_thread` - The kernel will immediately terminate the thread. Other - threads will continue to execute. -- `kill_process` - The kernel will terminate the process. Available in Linux - 4.14 and later. -- `log` - The kernel will log the system call before executing it. Available in - Linux 4.14 and later. (This does not go to the Beat's log.) -- `allow` - The kernel will allow the system call to execute. - -[float] -=== {auditbeat} Reports Seccomp Violations - -You can use {auditbeat} to report any seccomp violations that occur on the system. -The kernel generates an event for each violation and {auditbeat} reports the -event. The `event.action` value will be `violated-seccomp-policy` and the event -will contain information about the process and system call. diff --git a/docs/legacy/copied-from-beats/docs/shared-securing-beat.asciidoc b/docs/legacy/copied-from-beats/docs/shared-securing-beat.asciidoc deleted file mode 100644 index c887f31708d..00000000000 --- a/docs/legacy/copied-from-beats/docs/shared-securing-beat.asciidoc +++ /dev/null @@ -1,63 +0,0 @@ -[id="securing-{beatname_lc}"] -= Secure {beatname_uc} - -++++ -Secure -++++ - -The following topics provide information about securing the {beatname_uc} -process and connecting to a cluster that has {security-features} enabled. - -You can use role-based access control and optionally, API keys to grant {beatname_uc} users access to -secured resources. - -* <> -* <>. - -After privileged users have been created, use authentication to connect to a secured Elastic cluster. - -* <> -ifndef::no-output-logstash[] -* <> -endif::[] - -ifdef::apm-server[] -For secure communication between APM Server and APM Agents, see <>. -endif::[] - -ifndef::serverless[] -ifndef::win_only[] -On Linux, {beatname_uc} can take advantage of secure computing mode to restrict the -system calls that a process can issue. - -* <> -endif::[] -endif::[] - -// APM HTTPS information -ifdef::beat-specific-security[] -include::{beat-specific-security}[] -endif::[] - - - -ifdef::apm-server[] -// APM privileges -include::{docdir}/legacy/feature-roles.asciidoc[] -// APM API keys -include::{docdir}/legacy/api-keys.asciidoc[] -endif::[] - -ifndef::apm-server[] -// Beat privileges -include::./security/users.asciidoc[] -// Beat API keys -include::./security/api-keys.asciidoc[] -endif::[] - -// Linux Seccomp -ifndef::serverless[] -ifndef::win_only[] -include::./security/linux-seccomp.asciidoc[] -endif::[] -endif::[] diff --git a/docs/legacy/feature-roles.asciidoc b/docs/legacy/feature-roles.asciidoc index 4e1cfba1774..8b60c1abdb0 100644 --- a/docs/legacy/feature-roles.asciidoc +++ b/docs/legacy/feature-roles.asciidoc @@ -1,6 +1,37 @@ -[role="xpack"] +[[secure-comms-stack]] +== Secure communication with the {stack} + +++++ +With the {stack} +++++ + +NOTE: This documentation only applies to the APM Server binary. + +Use role-based access control or API keys to grant APM Server users access to secured resources. + +* <> +* <>. + +After privileged users have been created, use authentication to connect to a secured Elastic cluster. + +* <> +* <> + +For secure communication between APM Server and APM Agents, see <>. + +A reference of all available <> is also available. + +[float] +[[security-overview]] +=== Security Overview + +APM Server exposes an HTTP endpoint, and as with anything that opens ports on your servers, +you should be careful about who can connect to it. +Firewall rules are recommended to ensure only authorized systems can connect. + +[float] [[feature-roles]] -== Grant users access to secured resources +=== Feature roles You can use role-based access control to grant users access to secured resources. The roles that you set up depend on your organization's security @@ -322,31 +353,3 @@ See {kibana-ref}/apm-app-central-config-user.html[{apm-app} central configuratio // ++++ // CONTENT - -//// -*********************************** *********************************** -*********************************** *********************************** -//// - -[[more-security-roles]] -=== Additional APM users and roles - -In addition to the {beatname_uc} users described in this documentation, -you'll likely need to create users for other APM tasks: - -* An {kibana-ref}/apm-app-reader.html[APM reader], for {kib} users who need to view the {apm-app}, -or create and edit visualizations that access +{beat_default_index_prefix}-*+ data. -* Various {kibana-ref}/apm-app-api-user.html[{apm-app} API users], -for interacting with the APIs exposed by the {apm-app}. - -[float] -[[learn-more-security]] -=== Learn more about users and roles - -Want to learn more about creating users and roles? See -{ref}/secure-cluster.html[Secure a cluster]. Also see: - -* {ref}/security-privileges.html[Security privileges] for a description of -available privileges -* {ref}/built-in-roles.html[Built-in roles] for a description of roles that -you can assign to users diff --git a/docs/legacy/security.asciidoc b/docs/legacy/security.asciidoc deleted file mode 100644 index 57b6a8767a3..00000000000 --- a/docs/legacy/security.asciidoc +++ /dev/null @@ -1,9 +0,0 @@ -A reference of all available <> is also available. - -[float] -[[security-overview]] -== Security Overview - -APM Server exposes an HTTP endpoint, and as with anything that opens ports on your servers, -you should be careful about who can connect to it. -Firewall rules are recommended to ensure only authorized systems can connect. diff --git a/docs/secure-agent-communication.asciidoc b/docs/secure-agent-communication.asciidoc index 7af978e148b..e2fca3bee18 100644 --- a/docs/secure-agent-communication.asciidoc +++ b/docs/secure-agent-communication.asciidoc @@ -1,6 +1,10 @@ [[secure-agent-communication]] == Secure communication with APM agents +++++ +With APM agents +++++ + Communication between APM agents and {agent} can be both encrypted and authenticated. It is strongly recommended to use both TLS encryption and authentication as secrets are sent as plain text. diff --git a/docs/secure-comms.asciidoc b/docs/secure-comms.asciidoc new file mode 100644 index 00000000000..60b665936f5 --- /dev/null +++ b/docs/secure-comms.asciidoc @@ -0,0 +1,22 @@ +[[securing-apm-server]] +== Secure communication with the {stack} + +++++ +Secure communication +++++ + +The following topics provide information about securing the APM Server +process and connecting securely to APM agents and the {stack}. + +* <> +* <> + +:leveloffset: +1 +include::secure-agent-communication.asciidoc[] + +// APM privileges +include::{docdir}/legacy/feature-roles.asciidoc[] + +// APM API keys +include::{docdir}/legacy/api-keys.asciidoc[] +:leveloffset: -1 \ No newline at end of file