Allow to define custom agents in system test configuration files #1765
Conversation
Add none deploy folder into auditd_manager package
This will allow to leverage the new custom definitions added in #1765, without forcing the packages to define a service deployer. This is useful when the only requirement to test the package is a running agent, for example when collecting information from the system where it is running.
Currently, the error in this step is caused because the previous Elastic Agent created by the previous package tested has not been unenrolled and removed from Fleet. This could be solved by forcefully removing those agents after each test (without waiting to be acknowledge it by the agent itself). This is done in #1771 |
| # if it is not a list, rename it back to error.message | ||
| - set: | ||
| field: error.message | ||
| copy_from: auditd.warnings | ||
| ignore_empty_value: true | ||
| if: ctx?.auditd?.warnings != null && !(ctx.auditd.warnings instanceof List) |
There was a problem hiding this comment.
Added this new step in the pipeline to detect if there is just one warning (string)
Adding this would make fail this test package when ELASTIC_PACKAGE_TEST_ENABLE_INDEPENDENT_AGENT is false, since this will use the Elastic Agent from the stack that does not have the required capabilities.
Should we skip this test package in the CI scripts ? @jsoriano
There was a problem hiding this comment.
Should we skip this test package in the CI scripts ? @jsoriano
Yeah, we will need to find a way to test this package only when independent agents are enabled.
There was a problem hiding this comment.
Added an exception in the test script to not test auditd_manager_independent_agent when using the Elastic Agent from the stack.
| agent: | ||
| user: "root" | ||
| # shared_pid_address_space: true ? | ||
| pid_mode: "host" | ||
| capabilities: | ||
| - AUDIT_CONTROL | ||
| - AUDIT_READ |
There was a problem hiding this comment.
Currently, this file allows additional properties. However, it probably would be better to at least add agent field as an object in this file. WDYT ?
There was a problem hiding this comment.
Created PR for this : elastic/package-spec#739
mrodm
force-pushed
the
independent_custom_agents
branch
from
22d0abd to
97f085d
Compare
| # shared_pid_address_space: true ? | ||
| pid_mode: "host" |
There was a problem hiding this comment.
This setting looks like that it is more related to docker runtime.
It is needed to specify somehow this setting for auditd_manager package to keep the same behavior. That setting is present in the current configuration:
Should it be added here even if it is more docker related ? or maybe do we need to add a map for docker specific settings ?
agent:
user: root
runtime: docker
capabilities:
- AUDIT_CONTROL
- AUDIT_READ
docker:
pid_mode: host
Maybe it can be changed the name of this field to use_host_pid_namespace: true
WDYT @jsoriano ?
There was a problem hiding this comment.
PID namespacing is not specific of docker, so I would not use an specific docker variable. Not sure about the variable name to use but I wouldn't use a boolean because there can be more than one option.
internal/agentdeployer/info.go
Outdated
| // Capabilities is a list of the capabilities needed to run the Elastic Agent process | ||
| Capabilities []string |
There was a problem hiding this comment.
Nit. Maybe we can call this LinuxCapabilities to avoid confusion with other capabilities.
| // Capabilities is a list of the capabilities needed to run the Elastic Agent process | |
| Capabilities []string | |
| // LinuxCapabilities is a list of the capabilities needed to run the Elastic Agent process | |
| LinuxCapabilities []string |
There was a problem hiding this comment.
Agreed, do you think it should be updated that naming in the configuration file for system tests ? @jsoriano
Currently, those settings in the configuration file looks like:
agent:
runtime: docker
user: "root"
pid_mode: "host"
capabilities:
- AUDIT_CONTROL
- AUDIT_READ runtime: docker
user: "root"
pid_mode: "host"
- capabilities:
+ linux_capabilities:
- AUDIT_CONTROL
- AUDIT_READThere was a problem hiding this comment.
Yes, call them linux_capabilities in the config.
💚 Build Succeeded
History
cc @mrodm |
Relates #787
In this PR, it is added into the system test configuration files first fields in order to run custom agents with different parameters (capabilities, pid mode, user...). This is just taken into account when independent agents are enabled.
A new test package has been added to test this
auditd_manager_independent_agent.