The default template deployment applies a trial license to the cluster to enable Elastic Stack features, including Security, for a trial period of 30 days.

As part of the trial, Security features including Basic Authentication are enabled, by configuring xpack.security.enabled: true in Elasticsearch configuration. This prevents anonymous access to the cluster.

The following parameters are used to configure initial user accounts

It is recommended after deployment to use the elastic superuser account to create the individual user accounts that will be needed for the users and applications that will interact with Elasticsearch and Kibana, then to use these accounts going forward.

Using SAML single sign-on (SSO) for Elasticsearch with Azure Active Directory (AAD) means that Elasticsearch does not need to be seeded with any user accounts from the directory. Instead, Elasticsearch is able to rely on the claims sent within a SAML token in response to successful authentication to determine identity and privileges.

To integrate SAML SSO, the following conditions must be satisfied:

SAML integration with AAD defines a SAML realm with the name saml_aad in the elasticsearch.yml configuration file. The Basic Authentication realm is also enabled, to provide access to the cluster through the built-in users configured as part of the template. The built-in users can be used to perform additional steps needed within Elasticsearch to complete the integration.

The following sections guide you through what is required to integrate SAML SSO with AAD for Elasticsearch and Kibana deployed through the ARM template.

{
  "appId": "<guid>",
  "appRoles": [
    {
      "allowedMemberTypes": [
        "User"
      ],
      "displayName": "User",
      "id": "<guid>",
      "isEnabled": true,
      "description": "User",
      "value": null
    },
    {
      "allowedMemberTypes": [
        "User"
      ],
      "displayName": "msiam_access",
      "id": "<guid>",
      "isEnabled": true,
      "description": "msiam_access",
      "value": null
    }
  ],
  ... etc.
}

{
  "appId": "<guid>",
  "appRoles": [
    {
      "allowedMemberTypes": [
        "User"
      ],
      "displayName": "Superuser",
      "id": "18d14569-c3bd-439b-9a66-3a2aee01d14d",
      "isEnabled": true,
      "description": "Superuser with administrator access",
      "value": "superuser"
    },
    ... other roles
  ],
  ... etc.

With Azure Active Directory configured, the following parameters can be used to configure Elasticsearch for SAML SSO

For a production environment, it’s strongly recommended to also configure SSL/TLS for communication with Kibana using kibanaCertBlob and kibanaKeyBlob parameters. Consult the Transport Layer Security section for further details on configuring SSL/TLS for Elasticsearch and Kibana.

An example of a minimum deployment is

Azure CLI 2.0.

template_version=7.3.1
template_base_uri="https://raw.githubusercontent.com/elastic/azure-marketplace/$template_version/src/"

# certificates for SSL/TLS
http_cert=$(base64 /mnt/c/http.p12)
kibana_cert=$(base64 /mnt/c/kibana.crt)
kibana_key=$(base64 /mnt/c/kibana.key)

resource_group="<resource group>"
location="<location>"

# App Federation Metadata Url of the Enterprise application
metadata_uri="https://login.microsoftonline.com/<guid>/federationmetadata/2007-06/federationmetadata.xml?appid=<guid>"

az group create --name $resource_group --location $location

az group deployment create \
    --resource-group $resource_group \
    --template-uri $template_base_uri/mainTemplate.json \
    --parameters _artifactsLocation=$template_base_uri \
        esClusterName=elasticsearch \
        esHttpCertBlob=$http_cert \
        adminUsername=russ \
        authenticationType=password \
        adminPassword=Password1234 \
        securityBootstrapPassword=BootstrapPassword123 \
        securityAdminPassword=AdminPassword123 \
        securityKibanaPassword=KibanaPassword123 \
        securityLogstashPassword=LogstashPassword123 \
        securityBeatsPassword=BeatsPassword123 \
        securityApmPassword=ApmPassword123 \
        securityRemoteMonitoringPassword=RemoteMonitoringPassword123 \
        kibanaCertBlob=$kibana_cert \
        kibanaKeyBlob=$kibana_key \
        samlMetadataUri=$metadata_uri

Azure PowerShell.

$templateVersion = "7.3.1"
$templateBaseUri = "https://raw.githubusercontent.com/elastic/azure-marketplace/$templateVersion/src/"

# certificates for SSL/TLS
$httpCert = [Convert]::ToBase64String([IO.File]::ReadAllBytes("C:\http-cert.pfx"))
$kibanaCert = [Convert]::ToBase64String([IO.File]::ReadAllBytes("C:\kibana.crt"))
$kibanaKey = [Convert]::ToBase64String([IO.File]::ReadAllBytes("C:\kibana.key"))

$resourceGroup = "<resource group>"
$location = "<location>"

# App Federation Metadata Url of the Enterprise application
$metadataUri="https://login.microsoftonline.com/<guid>/federationmetadata/2007-06/federationmetadata.xml?appid=<guid>"

$parameters = @{
    "_artifactsLocation"= $templateBaseUri
    "esClusterName" = "elasticsearch"
    "esHttpCertBlob" = $httpCert
    "adminUsername" = "russ"
    "authenticationType" = "password"
    "adminPassword" = "Password1234"
    "securityBootstrapPassword" = "BootstrapPassword123"
    "securityAdminPassword" = "AdminPassword123"
    "securityKibanaPassword" = "KibanaPassword123"
    "securityLogstashPassword" = "LogstashPassword123"
    "securityBeatsPassword" = "BeatsPassword123"
    "securityApmPassword" = "ApmPassword123"
    "securityRemoteMonitoringPassword" = "RemoteMonitoringPassword123"
    "kibanaCertBlob" = $kibanaCert
    "kibanaKeyBlob" = $kibanaKey
    "samlMetadataUri" = $metadataUri
}

New-AzureRmResourceGroup -Name $resourceGroup -Location $location

New-AzureRmResourceGroupDeployment -ResourceGroupName $resourceGroup `
  -TemplateUri "$templateBaseUri/mainTemplate.json" `
  -TemplateParameterObject $parameters

After cluster deployment, if you didn’t provide a value for the samlServiceProviderUri, copy the kibana output and paste this value into the Identifier (EntityID) field for the Enterprise application within AAD. Also paste this value into the Reply URL field, followed by /api/security/v1/saml.

With the cluster deployed, the Role Mapping APIs are used to configure rules to define how roles received in the SAML token map to roles within Elasticsearch. A SAML realm called saml_aad is configured when samlMetadataUri parameter is provided, and maps the SAML role claim to the groups attribute.

Since SAML SSO integration also configures Basic Authentication access, role mappings can be added using the elastic superuser account. The role mappings that you define will vary depending on the roles that you defined in the appRoles array in the Enterprise Application Manifest, but as two examples to demonstrate

PUT /_xpack/security/role_mapping/saml-kibana-user
{
  "roles": [ "kibana_user" ],
  "enabled": true,
  "rules": {
    "field": { "realm.name": "saml_aad" } 
  }
}

will give the kibana_user role to any user authenticated through the saml_aad SAML realm, and

PUT /_xpack/security/role_mapping/saml-superuser
{
  "roles": [ "superuser" ],
  "enabled": true,
  "rules": {
    "all": [
      { "field": { "realm.name": "saml_aad" } }, 
      { "field": { "groups": "superuser" } } 
    ]
  }
}

Transport Layer Securityedit

It is strongly recommended that you secure communication when using the template in production. Elastic Stack Security can provide Authentication and Role Based Access control, and Transport Layer Security (TLS) can be configured for both Elasticsearch and Kibana.

You can secure HTTP communication to the cluster with TLS on the HTTP layer of Elasticsearch. You would typically want to do this when also deploying an external loadbalancer or Application Gateway, but you can also do this when deploying only Kibana, to secure internal traffic between Kibana and Elasticsearch through the internal load balancer.

Configuring TLS for the HTTP layer requires xPackPlugins be set to Yes for 5.x versions, 6.x versions less than 6.8.0 and 7.x versions less than 7.1.0. With xPackPlugins set to Yes, a trial license will be applied to the cluster, which allows TLS to be configured on these versions.

The following parameters can be used

Typically, esHttpCertBlob parameter would be used with a certificate associated with a domain configured with a CNAME DNS record pointing to the public domain name or IP address of the external load balancer or Application Gateway.

As an alternative to esHttpCertBlob and esHttpCertPassword, the following parameters can be used

openssl pkcs12 -in http_cert.p12 -out http_public_cert.cer -nokeys

You can secure communication between nodes in the cluster with TLS on the Transport layer of Elasticsearch. Configuring TLS for the Transport layer requires xPackPlugins be set to Yes for 5.x versions, 6.x versions less than 6.8.0 and 7.x versions less than 7.1.0. With xPackPlugins set to Yes, a trial license will be applied to the cluster, which allows TLS to be configured on these versions.

The following parameters can be used

One way to generate a PKCS#12 archive containing a CA certificate and key is using Elastic’s certutil command utility.

You can secure communication between the browser and Kibana with TLS with the following parameters

All certificates and PKCS#12 archives must be passed as base 64 encoded string values. A base 64 encoded value can be obtained using