{"push_id":1841900886,"size":1,"distinct_size":1,"ref":"refs/heads/pluggable_secret_backend","head":"e776b92f262099c4751151243f894fdd5e640ad7","before":"dc7d83a469ef9688c19f23e50f12daff4b957132","commits":[{"sha":"e776b92f262099c4751151243f894fdd5e640ad7","author":{"name":"liron","email":"5898abdb7ce270066897a296c02265734f814e1f@twistlock.com"},"message":"Pluggable secret backend\n\nThis commit extends SwarmKit secret management with pluggable secret\nbackends support. The solution uses the existing docker plugin\nframework for loading plugins and the existing SwarmKit data backend for\nstoring them.\n\nThe approach is to add a new `driver` parameter to existing secrets,\nwhich defines whether the values are taken as is or fetched from one of\nthe secret plugins. The loading of secrets is done using the standard\ndocker plugin infrastructure, which is already accessible in SwarmKit\nand used in other flows (e.g., networking).\nThe fetched values are evaluated before assigning them to worker nodes,\nso the payload is not stored in the raft store.\n\nRemarks:\n* I've added support for mocking the plugin subsystem when settings up\nthe controlapi server.\nI preferred this approach over loading the full plugin subsystem in UT.\n\nWork still needed in this CR:\n- [ ] More unit tests (pending initial iteration)\n- [ ] Customized error handling (e.g., customize error string for Not\nFound)\n\nWork still needed to complete this feature:\n- [ ] Inject secrets as part of plugin initialization\n- [ ] CLI support in docker\n- [ ] Docs\n- [ ] Support scheduling plugins in swarm\nhttps://github.com/moby/moby/pull/33575\n\nSigned-off-by: liron <liron@twistlock.com>","distinct":true,"url":"https://api.github.com/repos/twistlock/swarmkit/commits/e776b92f262099c4751151243f894fdd5e640ad7"}]}
{"actor":{"display_login":"liron-l"}}