Azure automation is great but one of the major features it has never had is the ability to give users access only to certain runbooks and not the whole automation account with every single runbook. Microsoft have now released the ability for us to assign permissions to individual runbooks for users or groups. As of writing this article the ability is only provided via powershell but i am sure a GUI version will be made available over the next few months.

In order to get this working there are two RBACs you need to apply, this first is give the users ability to run automation jobs which is set on the automation account (you only need to do this once) and the second is the ability for the users to see the runbook (you need to apply this to every runbook you want the users to see). Please also make sure that the users does not have read permission over the automation account resource group or they will be able to see all runbooks and run them.

 

Automation Job Operator – this is required once so the users or groups can run the runbooks and is set on automation account level

Automation Runbook Operator – this is required for every runbook you want the user or group to be able to see

Once you do this the users will be able to see individual runbooks only, i recommend you make a shared dashboard to make the user experience better.

This i what it will look like from a users perspective:

With HDInsight Standard cluster any user can SSH to the cluster nodes. In comparison HDInsight Premium cluster nodes by default restricts SSH access to two groups sudo and root. My initial assumption was that Microsoft may have done this for security reasons but then why allow the root user to login over SSH – this is something that most sysadmins disable.

HDInsight Premium cluster nodes have the following line in the /etc/ssh/sshd_config:

AllowGroups  sudo root

This line states that members of the group sudo and root (e.g. in the later case that’s the root user) are permitted to login via SSH. If you would like to allow any user to login via SSH simply remove this line.

A better approach is to create a group in AD (and ensure this group is synchronised to the HDInsight cluster – this is something that you must configure when you deploy the cluster) and use that instead.

There seems to be a limitation that AllowGroups does not work with AD groups other than those shown via id <username>. I suspect this behaviour may be due to a limitation with winbind – when using SSD and Realmd to domain join a Linux VM, the full group membership is shown for a user. Furthermore if your AD groups contain spaces then because the space character is used to separate users then this won’t work – you can partially work around this by using the asterisk character:

AllowGroups  sudo domain*users

This blog post explains how to enable LZO compression on a HDInsight cluster.

ARM Template

You will need to modify the ARM template configuration and under the clusterDefinition, configuration section:

•  Add core-site section and specify the codecs and compression codec class
• Add a mapred-site enable map output compression and the compression codec class

Install compression libraries on cluster nodes

You will also need to install the compression libraries on the cluster nodes.

On the point of compression libraries, if you are using snappy you will need to install the snappy compression libraries with:

This blog post describes how to display HDInsight cluster information when a user logs in via SSH.

Linux HDInsight clusters run Ubuntu, which allows you to customise the Message of the Day (MOTD) by placing scripts under /etc/update-motd.d and make the file executable.

The script has been published to GitHub https://github.com/vijayjt/AzureHDInsight/blob/master/script-actions/get-cluster-info.sh

This blog post discusses HDInsight premium which is currently in preview. HDInsight Premium adds the ability to domain join HDInsight clusters and Apache Ranger which can then be used to control access to databases/tables on HDInsight.

At the time of writing the documentation for HDInsight very poor and there are number of different limitations and issues with HDInsight Premium, most of which are not documented so I hope this post will help others.

Overview

HDInsight Premium allows you to join clusters to Azure AD Domain Services (AAD DS) domains. This then allows you to use accounts in your on-premise domain (provided you are synchronising users/groups via AAD Connect and have enabled password hash synchronisation) in HDInsight. Furthermore, you can then configure role based access control for Hive using Apache Ranger.

At the time of writing HDInsight is currently in Preview and has not GA’d – this means it is not backed by a full SLA. The Premium SKU is only available for “Hadoop” clusters – which do not come with Spark. However, HDInsight Premium with Spark clusters is available in private preview to a limited number of customers.

The domain-joining feature relies on Azure AD Domain Services (AADDS) – which provisions a Microsoft managed read-only domain controller. Until recently it was only possible to deploy AAD DS to a classic VNET which then required a VNET peering connection to the ARM VNET containing your HDInsight cluster (this obviously requires your VNETs are in the same region).

AD Connect and Password Synchronisation

Azure AD Domain Services

Enabling SSL/TLS for AAD DS

Management Server

OUs

Cluster Domain Join Account

DNS

Issues and Limitations

Apache Zeppelin supports integration with Active Directory/LDAP via the Shiro pluggable authentication module.

Configuration files

Configuration file	Settings	Description
zeppelin-config	zeppelin.anonymous.allowed: false	This disables anonymous access to Zeppelin
zeppelin-env	The shiro_ini_content setting should be configured with the following: [users] # List of users with their password allowed to access Zeppelin. # To use a different strategy (LDAP / Database / …) check the shiro doc at http://shiro.apache.org/configuration.html#Configuration-INI Sections # LDAP configuration, for user Authentication, currently tested for single Realm [main] activeDirectoryRealm = org.apache.zeppelin.server.ActiveDirectoryGroupRealm activeDirectoryRealm.systemUsername = CN=<service account tbc>,CN=Users,DC=my,DC=domain,DC=com activeDirectoryRealm.systemPassword = <not the password> #activeDirectoryRealm.hadoopSecurityCredentialPath = jceks://use r/zeppelin/zeppelin.jceks activeDirectoryRealm.searchBase = CN=Users,DC=my,,DC=domain,DC=com activeDirectoryRealm.url = ldap://<domain controller fqdn>:389 #activeDirectoryRealm.groupRolesMap = ‘tbc’ #activeDirectoryRealm.authorizationCachingEnabled = true shiro.loginUrl = /api/login [urls] # anon means the access is anonymous. # authcBasic means Basic Auth Security # To enfore security, comment the line below and uncomment the next one /** = authc	The first few lines under main defines the user account and password to use to connect to the domain controller. We then define the search base path to use when looking up users/groups. We  then define the domain controller to connect to. The last line enables authentication for all URLs.

• Through the Ambari web interface or;
• You can make these changes at cluster deployment time with ARM template HDInsight bootstrap configuration, although these configuration files are not officially listed in the Microsoft documentation it is possible to configure these in an ARM template (in the clusterDefinition, configurations section).

The only problem is you will not likely want to add the password to the ARM template so you could add the password via the Ambari web interface post deployment or inject it into the template at runtime.

This post describes a way of creating user specific databases on HDInsight standard. This uses a similar technique as described in a previous post.

Overview

• First create a CSV file
  • The first line should contain the header name dbname
  • The subsequent lines should contain the
• Store the CSV file on the default Azure Storage account
• Attach the Storage account to the HDInsight cluster
• Deploy the cluster with an ARM template that uses a custom script
• The script
  • Determines the cluster name
  • Based on the cluster name it looks for a file named <clustername>-user-db-list.csv on the storage account
  • Copies the file to the node and iterates through the lines in the file and iterates through the file to create the databases in the file

Future improvements

As mentioned in a previous blog post on HDInsight standard, Microsoft modify the PAM configuration (at least this is the case on HDInsight 3.5) such that when you create a user and try to set the password you are asked to set the password twice.

The gist below can be used to reset the PAM configuration. In the code below the various PAM configuration files have been gzipped and base64 encoded.

This technique of using gzip compressed and base64 encoded files is very useful when running script actions on HDInsight or even configuring VMs via custom script actions on Linux.

The code creates files:

• common-account
• common-auth
• common-password
• common-session
• common-session-noninteractive

These should replace the ones in /etc/pam.d/

HDInsight is a semi-managed Hadoop cluster on the Microsoft Azure cloud. Although the standard version isn’t geared towards multiple users from a security perspective I recently had to figure out a way to create local users across the cluster at cluster build time. This blog post describes one way you could do this.

Overview

The way we will create users on the cluster at boot time is:

• Create a CSV file containing usernames,user and group ids, shell etc.
• Store the CSV file on the default Azure Storage account
• Attach the Storage account to the HDInsight cluster
• Deploy the cluster with an ARM template that uses a custom script which creates the user accounts
• The script
  • Determines the cluster name
  • Based on the cluster name it looks for a file named <clustername>-user-list.csv on the storage account
  • Copies the file to the node and iterates through the lines in the file and:
    • Creates local OS users;
    • Create local OS groups for the users;
    • If the users is an admin user it adds them to sudoers;
    • Creates user accounts in Ambari – note that in a HDInsight standard cluster the user accounts in Ambari are separate to the OS level accounts;
    • Creates Pig and Oozie views if they do not already exist;
    • Adds the user to either the
      • clusteruser group which will have read only access to cluster stats/configuration and access to Hive views etc in Ambari
      • clusteradministrator which will have full access to manage everything through Ambari
      • grants access to various Ambari views to the aforementioned groups

The CSV file containing the user details includes the uid, we do this to ensure the users have the same uid across all nodes in the cluster.

The creation of Ambari users, groups, checking membership of the Ambari groups and creating views makes heavy use of the Ambari REST API.

At the moment the script lists all the storage accounts associated with the cluster and finds one that contains the string artifacts and looks on this storage account for the user list CSV file. The script needs to be improved by making the storage account and container names parameters.

I have uploaded the script to github here https://github.com/vijayjt/AzureHDInsight/blob/master/script-actions/create-local-users.sh

Ambari REST API

As mentioned the script makes heavy use of the Ambari REST API.

• Checking a user exists
  • We do this by calling the REST API endpoint http://${ACTIVEAMBARIHOST}:8080/api/v1/users
  • Then iterating to through the users returned to see if the username is in this list
  • Lines 2 – 16 in the gist shown below provides some example code for checking if a user exists in Ambari (this is an extract from the full script mentioned above).
• Check if a user is a member of an Ambari Group
  • We call the REST API endpoint http://${ACTIVEAMBARIHOST}:8080/api/v1/groups/${GROUP_TO_CHECK}/members
  • To obtain a list of users that are a member of the specified group
  • Then we iterate through the list to see if the user is in the list
• Adding a user to Ambari
  • As shown in line 88 of the gist, we make a post request to the endpoint http://${ACTIVEAMBARIHOST}:8080/api/v1/users with a JSON body that contains the username and password
• Adding a group to Ambari
  • As shown in line 91 of the gist, we make a post request to the endpoint http://${ACTIVEAMBARIHOST}:8080/api/v1/groups with a JSON body that contains the group name
• Adding a user to a group in Ambari
  • As shown in line 94 of the gist we make a post request to the endpoint http://${ACTIVEAMBARIHOST}:8080/api/v1/groups/${ambarigroup}/members with a JSON body that contains the username and group name

 

Important considerations

PAM Configuration

It should be noted that Microsoft do modify the pam configuration files which can lead to an issue where the passwd <username> command will prompt you twice because they have added kerberos related configuration items to PAM. I suspect they made this change for Azure HDInsight Premium which supports domain joined clusters but accidentally included this on Standard clusters as well. I will write a separate post on how to change the PAM configuration.

 

Force password change

When the account is created you should force the user to change their password shortly afterwards.

Security of user list file on Azure storage

What other options are there for provisioning users on HDInsight Standard?

Creating Azure AD Applications and Service Principals that use certificate based authentication is not quite as straightforward as you might expect.

The following article provides the instructions on how to do this https://docs.microsoft.com/en-us/azure/azure-resource-manager/resource-group-authenticate-service-principal#create-service-principal-with-self-signed-certificate

However, what if you want to use multiple certificates using the KeyCredentials parameter to New-AzureRmAdApplication? In this case you might guess from the following article that you could create an array of objects of type

Microsoft.Azure.Commands.Resources.Models.ActiveDirectory.PSADKeyCredential