A common scenario when configuring an environment is that certain elements of the scripts may need to be executed using a specific user’s credentials. If you’ve looked at the documentation for the various means of execution within Chef you might have noticed the “user”, “domain” and “password” parameters.

The “powershell_script” action is particularly useful when setting up Windows environments.

Alt

These parameters are intended to allow you to specify the user credentials to run the embedded PowerShell within. The problem is that Chef just recently added support for lighting up these parameters. In fact, this feature was added in the latest release 12.19.33 released on 2/22/2017. When Chef is running as a service (as it does with OpsWorks), this feature requires that the user Chef runs as has the “SeAssignPrimaryTokenPrivlege”.

You can check whether the user has this privilege by running this command:

# Check if the user has 'SeAssignPrimaryTokenPrivilege' rights

Chef::ReservedNames::Win32::Security.get_account_right('<user>').include?('SeAssignPrimaryTokenPrivilege')

You can grant this privilege to the user by running this command:

# Add 'SeAssignPrimaryTokenPrivilege' for the user

Chef::ReservedNames::Win32::Security.add_account_right('<user>', 'SeAssignPrimaryTokenPrivilege')

That is, if OpsWorks used the latest version of Chef. It doesn’t. In fact, OpsWorks is very clear that it runs Chef version 12.2. To be clear, Chef version 12.2 was released on March 26, 2015. Why OpsWorks uses such a ridiculously old version of Chef Client still boggles the mind but, well, there it is.

If you talk to AWS Helpdesk, they will give you boilerplate answers that “the features are coming”.

So what are your options?

One option you have is to change the user that the Chef service runs as on OpsWorks instances.

Alt

Once you pull open the local services on the instance

Alt

You can specify a different account, maybe a service account setup within Active Directory and in the necessary groups to perform the required actions.

Alt

This overcomes the issue of being able to run certain code as a specific user, however, in cases where you are unable to use a single service account with all the necessary privileges to perform all OpsWorks actions there is another option: Opsworks for Chef Automate. This option would allow you to use any version of Chef you so desired but would require additional work in setting up your Chef environment and if you’ve already made significant investments in using the out-of-the-box OpsWorks Chef environment you will most likely have significant re-work.

For my client’s situation, we have made significant investments in using out-of-box OpsWorks Chef, are on an extremely tight timeline. Therefore we will be leveraging a single service account and waiting until AWS updates their out-of-the-box Chef offering. However, since its been close to two years since an update to the Chef client in OpsWorks for Windows, I won’t be holding my breath.