diff options
author | John McCrae <john.mccrae@progress.com> | 2023-03-02 06:21:36 -0800 |
---|---|---|
committer | GitHub <noreply@github.com> | 2023-03-02 06:21:36 -0800 |
commit | 97a5d19165ca3e4f83814f44a1171fe04a592894 (patch) | |
tree | 84accc8f36645cd2243324a8a65b2840011e29ef /chef-config/lib/chef-config/config.rb | |
parent | 02bcb3fa523feee6334a5e68bc4e5b64b7b30253 (diff) | |
parent | 9f8c667ae2b0ccdd9fa0a77a7d215aaf2df98c5f (diff) | |
download | chef-97a5d19165ca3e4f83814f44a1171fe04a592894.tar.gz |
Merge pull request #13552 from chef/jfm/chef18_cert_retrieval2
Correcting cert retrieval issues for multiple user scenarios
Diffstat (limited to 'chef-config/lib/chef-config/config.rb')
-rw-r--r-- | chef-config/lib/chef-config/config.rb | 10 |
1 files changed, 10 insertions, 0 deletions
diff --git a/chef-config/lib/chef-config/config.rb b/chef-config/lib/chef-config/config.rb index 2932fdc82f..6b6d9de427 100644 --- a/chef-config/lib/chef-config/config.rb +++ b/chef-config/lib/chef-config/config.rb @@ -778,6 +778,16 @@ module ChefConfig # Then the public key from the new cert is pushed to Chef Server for authentication default :migrate_key_to_keystore, false + # When we move certs into the certstore, we need to manage multi-user scenarios. + # This flag is used in conjunction with 'migrate_key_to_keystore'. If 2 users, Bob and Terri, are using + # this node, we need a means to separate the private keys of each user. Alternately, if an Admin + # configures the node and then relies on a system account to run chef afterward, we need a second + # method for that. Setting this in the client.rb file with a "user" flag will cause chef to create + # and manage separate private keys. We look for this flag to be set to "user" to manage distinct users keys with, + # However, if that key is set to anything else, we assume that keys are to be stored in the LocalMachine store. + # Leaving this key omitted has the same effect as setting it to anything other than "user" + default :auth_key_registry_type, nil + # When registering the client, should we allow the client key location to # be a symlink? eg: /etc/chef/client.pem -> /etc/chef/prod-client.pem # If the path of the key goes through a directory like /tmp this should |