From 9f8c667ae2b0ccdd9fa0a77a7d215aaf2df98c5f Mon Sep 17 00:00:00 2001 From: John McCrae Date: Sun, 5 Feb 2023 08:20:57 +0600 Subject: Correcting cert retrieval issues for multiple user scenarios Signed-off-by: John McCrae --- chef-config/lib/chef-config/config.rb | 10 ++++++++++ 1 file changed, 10 insertions(+) (limited to 'chef-config') 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 -- cgit v1.2.1