zuazo / ssh_authorized_keys-cookbook

Chef cookbook to create SSH authorized keys files in user home directories.
https://supermarket.chef.io/cookbooks/ssh_authorized_keys
Apache License 2.0
9 stars 17 forks source link

User cannot be lazily evaluated #9

Open cdown opened 7 years ago

cdown commented 7 years ago

When trying to evaluate a user which is a delayed resource, checks fail -- this check should be skipped if the user is being lazily evaluated:

For example:

ssh_authorize_key 'Main user' do
  user lazy { node['seedbox']['user'] }
  key lazy { node['seedbox']['user_ssh_pubkey'] }
end

results in

==> default: ================================================================================
==> default: Recipe Compile Error in /var/chef/cache/cookbooks/seedbox/recipes/default.rb
==> default: ================================================================================
==> default: 
==> default: 
==> default: Chef::Exceptions::ValidationFailed
==> default: ----------------------------------
==> default: ssh_authorize_key: user parameter must be a valid system user! You passed #<Chef::DelayedEvaluator:0x00000003302908@/var/chef/cache/cookbooks/seedbox/recipes/default.rb:11>.
==> default: 
==> default: 
==> default: Cookbook Trace:
==> default: ---------------
==> default:   /var/chef/cache/cookbooks/ssh_authorized_keys/libraries/resource_helpers.rb:51:in `assert_user'
==> default: 
==> default:   /var/chef/cache/cookbooks/ssh_authorized_keys/definitions/ssh_authorize_key.rb:26:in `block in from_file'
==> default: 
==> default:   /var/chef/cache/cookbooks/seedbox/recipes/default.rb:10:in `from_file'
==> default: 
==> default: 
==> default: Relevant File Content:
==> default: ----------------------
==> default: /var/chef/cache/cookbooks/ssh_authorized_keys/libraries/resource_helpers.rb:
==> default: 
==> default: 
==> default: 
==> default:  44:      # Asserts that the user name is correct.
==> default: 
==> default:  45:      #
==> default: 
==> default:  46:      # @param user [String] user name.
==> default: 
==> default:  47:      # @raise [Chef::Exceptions::ValidationFailed] if the user name is wrong.
==> default: 
==> default:  48:      # @return void
==> default: 
==> default:  49:      def assert_user(user)
==> default: 
==> default:  50:        return if user.is_a?(String) && !user.empty?
==> default: 
==> default:  51>>       fail Chef::Exceptions::ValidationFailed,
==> default:  52:             'ssh_authorize_key: user parameter must be a valid system user! '\
==> default:  53:             "You passed #{user.inspect}."
==> default:  54:      end
==> default:  55:  
==> default:  56:      # Asserts that the SSH public key is correct.
==> default:  57:      #
==> default:  58:      # @param key [String] public key in base64.
==> default:  59:      # @raise [Chef::Exceptions::ValidationFailed] if the key is wrong.
==> default:  60:      # @return void
==> default: 
==> default: Platform:
==> default: ---------
==> default: x86_64-linux
==> default: 
==> default: 
zuazo commented 7 years ago

ssh_authorize_key is a definition, not a resource. Calling it with a lazy property is not currently supported.

The reason is that these values are checked to be correct before creating the underlying file resource to avoid the generated authorized_keys file to be corrupted. AFAIK there is no way to check these lazy values without unlazying them.

cdown commented 7 years ago

So why not just skip the checks when they are lazy, and print a warning? Without lazy evaluation, this is unusable in an ecosystem where separate teams maintain separate attributes for their tiers

zuazo commented 7 years ago

But if we skip the checks, what's the purpose of this cookbook? I mean, creating a template file for a _ssh_authorizekey is too simple and I prefer to be this the purpose of the cookbook: To try to avoid generating an invalid file that could leave your server inaccessible.

Anyway, I'm going to leave this open in case someone wants to implement it.

wdeviers commented 2 years ago

For what it's worth, I have a different use-case for this that would have been helpful. We use LDAP auth and so the users might not actually exist as POSIX accounts at the time this gets evaluated (like on bootstrap).

That means they'll get created on the 2nd Chef run, but it also means I can't do kitchen tests with it. In order to make it work, I have to run nss_updatdb at compile time, which means I have to then run the entire support stack for that at compile time as well - create ldap.conf, install the packages, etc.

If we had a flag that said "ignore_user_not_exist" or something it would work equally well for me.