Skip to content

Semantic of container.id and container.name #2057

@leogr

Description

@leogr

Motivation

Historically, when a syscall event occurs outside a container, the container.id field is set to host. Our ruleset has consistently followed this pattern: 👇

https://github.com/falcosecurity/rules/issues/new?permalink=https%3A%2F%2Fgithub.com%2Ffalcosecurity%2Frules%2Fblob%2Fb6ad37371923b28d4db399cf11bd4817f923c286%2Frules%2Ffalco_rules.yaml%23L226-L227

This behavior is also documented in the official documentation.

Although this design decision is opinionated, it works since a container ID cannot be host.

The container.name field currently follows the same pattern: 👇
https://github.com/incertum/libs/blame/master/userspace/libsinsp/filterchecks.cpp#L6232-L6236

However, using container.name = host is unsafe because a container could be named host.

Overall, the current approach could lead to confusion or errors.

Feature

To resolve this issue for non-container cases, we propose two backward-incompatible solutions:

  1. Leave container.name unset (like other container.* fields) and continue using container.id=host.
  2. Leave both container.id and container.name unset. This would make not container.id exists work correctly (assuming the empty value problem will also be fixed).

Alternatives

Doing nothing is not an option, as container.name = host could be misleading.

Additional context

This change would be a major breaking change and should be targeted for Falco 1.0.

Also note the empty value problem (a.k.a. the issue) is orthogonal to this issue. Still, it should be taken into consideration

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type

    Projects

    No projects

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions