What would you like to be added?

Validation for capabilities added to the security context of containers should be improved to make it easier to schedule containers with the expected capabilities.

/sig apps

OPTION 1: CAP_/cap_ prefix is be forbidden

• example capabilities that would be allowed:
  • SYS_ADMIN (uppercase capability)
  • sys_admin (lowercase capability)
  • INVALID_CAPABILITY (non-existent capability, without forbidden prefix)
• example capabilities that would be rejected:
  • CAP_SYS_ADMIN
  • cap_sys_admin

OPTION 2: Only capabilities from a select list of capabilities should be allowed, in both upper- and lowercase

• example capabilities that would be allowed:
  • SYS_ADMIN (uppercase capability)
  • sys_admin (lowercase capability)
• example capabilities that would be rejected:
  • CAP_SYS_ADMIN
  • cap_sys_admin
  • INVALID_CAPABILITY (non-existent capability)
  • ...

In my opinion Option 2 is preferred, since it will only allow scheduling of containers, that receive the expected capability.

ℹ️ Open to create a PR if this proposal is accepted. I'd also like to take this opportunity to improve capability validation, so it's no longer required to define the string in each location, but have a case insensitive check somewhere.

Why is this needed?

⚠️ Currently only uppercase capabilities are validated correctly in the security context, while lowercase capabilities add the same capability to the container.

The following pod manifest was used to create containers with specific capabilities added and then the current capabilities of the created container were logged using capsh --print:

apiVersion: v1
kind: Pod
metadata:
  name: test
spec:
  containers:
  - name: alpine
    image: alpine
    command: ['sh', '-c', 'apk add -U libcap && capsh --print']
    securityContext:
      capabilities:
        drop:
        - "ALL"
        add:
        - "SYS_ADMIN"
        # - "sys_admin"
        # - "cap_sys_admin"
        # - "CAP_SYS_ADMIN"
        # - "INVALID_CAPABILITY"

...
Current: cap_sys_admin=ep
Bounding set =cap_sys_admin
Ambient set =
Current IAB: !cap_chown,!cap_dac_override,!cap_dac_read_search,!cap_fowner,!cap_fsetid,!cap_kill,!cap_setgid,!cap_setuid,!cap_setpcap,!cap_linux_immutable,!cap_net_bind_service,!cap_net_broadcast,!cap_net_adm
Securebits: 00/0x0/1'b0 (no-new-privs=0)
 secure-noroot: no (unlocked)
 secure-no-suid-fixup: no (unlocked)
 secure-keep-caps: no (unlocked)
 secure-no-ambient-raise: no (unlocked)
uid=0(root) euid=0(root)
gid=0(root)
groups=0(root),1(bin),2(daemon),3(sys),4(adm),6(disk),10(wheel),11(floppy),20(dialout),26(tape),27(video)
Guessed mode: HYBRID (4)

Result of adding different capabilities to the container's security context:

• ✅ SYS_ADMIN: container has expected cap_sys_admin capability
• ✅ sys_admin: container has expected cap_sys_admin capability
• ❌ CAP_SYS_ADMIN: container missing expected cap_sys_admin capability
• ❌ cap_sys_admin: container missing expected cap_sys_admin capability
• ❌ INVALID_CAPABILITY: container scheduled with invalid capability (unknown/invalid capability)