@@ -201,6 +201,11 @@ This is a set of options that can be put in any of the above definitions, with t
201201 # This defaults to `false`
202202 interactiveSudo = false;
203203
204+ # Whether to enable the sops integration for password based sudo on the remote host. Useful when using non-root sshUsers.
205+ # This defaults to not beeing used.
206+ sudoFile = ./path.yaml;
207+ sudoSecret = "secret";
208+
204209 # This is an optional list of arguments that will be passed to SSH.
205210 sshOpts = [ "-p" "2121" ];
206211
@@ -238,6 +243,28 @@ This is a set of options that can be put in any of the above definitions, with t
238243
239244Some of these options can be provided during ` deploy ` invocation to override default values or values provided in your flake, see ` deploy --help ` .
240245
246+ ### Sudo on remote host
247+
248+ There are two different ways to supply a password for elevating privileges on the remote host, but only one can be used at a time.
249+ The first is ` interactiveSudo ` , where the user will get prompted for a password while running the deployment.
250+ The other option is to use sops to provide the secrets.
251+
252+ #### Sops
253+
254+ In order to use the [ sops] ( https://github.com/getsops/sops ) integration ` sudoFile ` as well as ` sudoSecret ` have to be specified for a node.
255+ While running the deployment ` sops ` is used to decrypt the path ` sudoFile ` and search for ` sudoSecret ` within the file.
256+ When specifying the ` sudoSecret ` you can address the key as specified below:
257+
258+ ``` yaml
259+ password :
260+ test : 123
261+ password_test_user : abc
262+ ` ` `
263+
264+ You can refer to the password ` 123` as `password/test` and `abc` as `password_test_user`.
265+ Keep in mind that we only handle nested secrets with strings, numbers and boolean.
266+ For an example please see the [sops example](./examples/sops).
267+
241268# # About Serokell
242269
243270deploy-rs is maintained and funded with ❤️ by [Serokell](https://serokell.io/).
0 commit comments