[Elastic Agent] Capabilities feature

[ruflin]

Recently a few features around which capabilities an Agent should support were discussed:

• Allowlist / Blocklist for inputs [Elastic Agent] Disable upgrade capability of Agent #21001
• Disable upgrade [Elastic Agent] Allowlist / Blocklist for inputs an Agent supports with Fleet #21000

I the future there will be more capabilities which either a user from Fleet or directly the administor of an Agent wants to enforce. Further examples are which output can be used, if a queue can be used, variables etc. For this it would be nice to have a generic capabilities feature in the Elastic Agent that we can extend. This issue is to discuss this feature.

For a system administrator to specify the capabilities the Agent has, I think there are at least 2 ways:

• Through config file
• Command line flag on start up

At first, I suggest we start with a capabilities config file. Putting capabilities in a separate config file still allows Fleet to take over the full config file but have the capabilities.yml separate.

The content of the file could look as following:

inputs.allow_list: logfile
inputs.block_list: syslog

# Just an example ...
upgrade.enabled: true
upgrade.bugfix_release: true
upgrade.major_release: false

It would be a flat list of config entries, each describing a capability.

[elasticmachine]

Pinging @elastic/ingest-management (Team:Ingest Management)

[ruflin]

@blakerouse @ph @michalpristas Would be great to get your thoughts on this.

[ph]

Could we have a unique syntax?

- allow: "inputs.logfile"
- deny: "inputs.syslog"
- allow: "upgrade.enabled"
- allow: "upgrade.bugfix_release"
- deny: "program.endpoint"

[ph]

I was suggesting the unique syntax/definition make it behave the same on everything and allow to expose capabilities as we good.

[ruflin]

@ph Not sure I follow. Would this be in a yaml file?

[ph]

@ruflin Just realized I was effectively cut off. What I would like to see is, it is possible to make it a unique syntax for defining capabilities. In the above example, it's a flat Keystore like structure, which is the same for anything vs some items are list vs some items are booleans. But maybe it's not possible.

[blakerouse]

I think we could do something like this. But a note would be there is cases for upgrade.enabled: true there that would still no be true. Setting update.enabled: true but being installed from the DEB/RPM would still not allow upgrading. But setting update.enabled: false would allow disabling upgrade. So it would really only be useful to disable updating.

[ph]

@blakerouse Agree on that.

[ruflin]

So in the deb/rpm case, the config value for upgrade would be compiled into the binary and could not be overwritten? The other option is, that we just ship different defaults for deb/rpm/docker and if a user really wants to change it, he can but it is not supported.

[ph]

So in the deb/rpm case, the config value for upgrade would be compiled into the binary and could not be overwritten? The other option is, that we just ship different defaults for deb/rpm/docker and if a user really wants to change it, he can but it is not supported.

I would not make another binary, I think for supportability the binary should always be the same. So we can use different default for DEB/RPM.

[ruflin]

Thinking more about capabilities, I think there are 2 layers here:

• Capabilities set on the Agent side: These have to be set on start of the Agent and cannot be changed
• Capabilities for an Agent set in Fleet: The set of capabilities can be further reduced in Fleet. With this even if an Agent has upgrade capability, it could be disabled for an Agent in Fleet. Or certain inputs for an Agent could be disabled so if a policy for an Agent is modified, certain integrations are not available. I wonder if these capability reductions should also be shipped down to the Agent or if it is a Fleet only feature.

[ph]

@ruflin "Capabilities for an Agent set in Fleet", I think the question is to answer is there any security implication for sending them to the Agent or having some "capabilities" executed in fleet allow for some optimization.

[ruflin]

@ph I'm not sure I follow, sorry :-(

[ph]

@ruflin Consider the use case of deploying the Elastic-Agent on a laptop, A user should not be able to prevent "endpoint-security" from running by settings "capabilities". But maybe its already taken care of by the permissions on the file and prevent local user to changes that.

[ruflin]

Got it. It means this users could restart the Agent and modify the file. We should at least be able to detect such changes in Fleet. I don't think we can fully prevent it.

[ph]

@ruflin Yes, maybe having a "compliance" checks that validate expected states or config vs that is on the machine. I was just pushing that problem on your side :)

[mostlyjason]

Can you explain how the allowlist and denylist interact when both are present? My initial thought is that an allowlist denies all inputs by default unless they are listed. The denylist is the opposite where all inputs are allowed by default except the ones listed. What is the default if they have both? Furthermore, what takes precedence when there is a conflict? Do we really need to support both?

[ruflin]

We should probably just start with one, not sure which one. I'm sure there also better syntax options then I proposed so perhaps we can work with conditions we already have instead. This works around the problem of having both. If both exists at the same time, it would probably be an invalid problem to work around the problem.

[ph]

@mostlyjason You have raised an excellent point... could we compare that to the firewall case?

In that case, you usually block all and just define allow rules. It's more verbose but it's really explicit and you don't risk to have unwanted things "slip"

[mostlyjason]

I think in the cloud use case they want to limit the inputs for security reasons, an allowlist is easier to lock down. When someone adds a new input type, we'd have to go back to update the denylist every time, and if we forget it could cause an unintended problem on cloud.

[ruflin]

@ph Going to close this issue as an initial version of capabilities is merged.