Add support for kubernetes device-ownership-from-security-context

[vigh-m]

Description of changes:

• Add default support for the new setting being introduced in
  • feat: Add kubernetes device ownership bottlerocket-settings-sdk#69
  • Use kubernetes device-ownership setting bottlerocket-core-kit#329
• Add migration for the new setting

Testing done:

• The setting shows up as expected in an AMI built using this settings-sdk

  # apiclient get settings.kubernetes.device-ownership-from-security-context
  {
    "settings": {
      "kubernetes": {
        "device-ownership-from-security-context": false
      }
    }
  }
  

• Changing the setting works as defined:

  [root@admin]# apiclient set settings.kubernetes.device-ownership-from-security-context="true"
  [root@admin]# apiclient get settings.kubernetes.device-ownership-from-security-context
  {
    "settings": {
      "kubernetes": {
        "device-ownership-from-security-context": true
      }
    }
  }
  [root@admin]# sheltie cat /etc/containerd/config.toml | grep device
  device_ownership_from_security_context = true
  

• The setting has the desired effect on device ownership

  • When true:

    # kubectl exec -it single-node-test -- bash
    ubuntu@single-node-test:/$ ls -lah /dev/ | grep neuron
    crw-------. 1 ubuntu 2000 244, 0 Dec 20 00:25 neuron0
    

  • When false:

    # kubectl exec -it single-node-test -- bash
    ubuntu@single-node-test:/$ ls -lah /dev/ | grep neuron
    crw-------. 1 root root 244, 0 Dec 19 20:03 neuron0
    

• migration testing

Terms of contribution:

By submitting this pull request, I agree that this contribution is dual-licensed under the terms of both the Apache License, version 2.0, and the MIT license.

[ytsssun]

You will also want to add migration for the affected services so that the containerd service gets restarted upon migration.

Reference this code - https://github.com/bottlerocket-os/bottlerocket/blob/develop/sources/settings-migrations/v1.23.0/nvidia-container-runtime-metadata/src/main.rs#L7-L10

[vigh-m]

That makes sense.

Should the Metadata Migration be in addition to the existing SettingsMigration or in place of it?

From my read of the migration logic for AddMetadataMigration it looks like it only removes the affected-services and not the actual setting from the datastore.