Skip to content

Add support for setting capabilities on the app binary#1271

Merged
imjasonh merged 3 commits intoko-build:mainfrom
mejedi:capabilities
Apr 3, 2024
Merged

Add support for setting capabilities on the app binary#1271
imjasonh merged 3 commits intoko-build:mainfrom
mejedi:capabilities

Conversation

@mejedi
Copy link
Contributor

@mejedi mejedi commented Apr 2, 2024

This patchset adds linux_capabilities under builds section in .ko.yaml. Ex:

builds:
- id: my-app
  dir: ./cmd
  main: ./myapp
  linux_capabilities: bpf perfmon net_admin

A bit of trivia on capabilities: unless running the app as root user, Docker's --cap-add alone is insufficient.
Requested capabilities are AND-combined with capabilities granted to the app binary (intentionally simplified, see man capabilities for the full discourse).

A running program has multiple sets of capabilities. The most important ones are effective (used by the kernel for permission checks) and permitted (a "stash" of capabilities an app can promote to effective). Likewise, file capabilities capture multiple sets of capabilities, permitted being the most important.

linux_capabilities: bpf perfmon net_admin

The config above sets permitted capabilities on the app binary to bpf, perfmon, and net_admin. When the app is launched, this set is AND-combined with capabilities requested via --cap-add and the result becomes the running app's permitted capabilities. The app should verify if it got all required capabilities and promote permitted capabilities to effective.

File capabilities have a bit that tells the kernel to automatically promote permitted to effective. The downside is that the program will fail to start with generic EPERM error if some capabilities weren't granted. In order to access this feature, and to make transition from Dockerfile easier, we also support the full setcap syntax in linux_capabilities, e.g.:

linux_capabilities: bpf,perfmon,net_admin=ep

Fixes #1246

Copy link
Member

@imjasonh imjasonh left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This looks really good! Thanks for the exhaustive test cases, that makes reviewing this for correctness a lot easier.

Just a few code style things, nothing major.

mejedi added 3 commits April 3, 2024 11:05
Build.Config contains LdFlags and Flags, both arrays of strings. For
user convenience it should be possible to specify a single string
instead. FlagArray (Flags) and StringArray (LdFlags) implement
YAMLUnmarshaller interface to handle custom parsing logic.

Since build.Config is loaded via viper/mapstructure and not the YAML
parser, YAMLUnmarshaller interface was ignored.

Wire things up.

Signed-off-by: Nick Zavaritsky <mejedi@gmail.com>
Signed-off-by: Nick Zavaritsky <mejedi@gmail.com>
Signed-off-by: Nick Zavaritsky <mejedi@gmail.com>
@mejedi
Copy link
Contributor Author

mejedi commented Apr 3, 2024

@imjasonh

Just a few code style things, nothing major.

Thank you for taking a look! I've implemented suggestions and fixed issues reported by linters.

@imjasonh imjasonh enabled auto-merge (rebase) April 3, 2024 12:47
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Support setting capabilities on the app binary

2 participants