Add custom bundles and plugins to your deploymentedit

Follow these steps to upload custom bundles and plugins to your Elasticsearch clusters, so that it uses your custom bundles or plugins.

  • Update your Elasticsearch cluster in the advanced configuration editor:
  • For bundles, modify the user_bundles JSON attribute.
  • For plugins, modify the user_plugins JSON attribute.

Add custom plugins to your deploymentedit

  1. Log into the Cloud UI.
  2. From the Deployments page, select your deployment.

    Narrow the list by name, ID, or choose from several other filters. To further define the list, use a combination of filters.

  3. From your deployment menu, select Edit then go to the bottom of the page and click advanced Elasticsearch configuration.
  4. Within the plan find the user_plugins section. If you don’t see it, you can add it within the Elasticsearch umbrella as shown in the examples below.

      "elasticsearch": {
        ...
        "enabled_built_in_plugins": [],
        "user_bundles": [
          {.....
              ....
          } ] ,
        "user_plugins": [
          {
            "url" : "<some static non_expirable url>", 
            "name" : "plugin_name",
            "elasticsearch_version" : "<es_version>" 
          },
          {
            "url": "http://192.168.100.10:8080/my-custom-plugin.zip",
            "name": "my-custom-plugin",
            "elasticsearch_version": "7.1.1"
          }
        ]
    }

    The URL for the plugin must be always available. Make sure you host the plugin artifacts internally in a highly available environment.

    The version must match exactly your Elasticsearch version, such as 6.4.2. Wildcards (*) are not allowed.

    If the plugin URL becomes unreachable, (the URL changes at remote end, or connectivity to the remote web server has issues) you might encounter boot loops.

  5. Save your changes.
  6. To verify that all nodes have the plugins installed, use one of these commands: GET /_nodes/plugins?filter_path=nodes.*.plugins or GET _cat/plugins?v

Example: Custom LDAP bundleedit

This example adds a custom LDAP bundle for deployment level role-based access control (RBAC). To set platform level RBAC, see Configure RBAC.

  1. Prepare a custom bundle as a ZIP file that contains your keystore file with the private key and certificate inside of a truststore folder in the same way that you would on Elastic Cloud. This bundle allows all Elasticsearch containers to access the same keystore file through your ssl.truststore settings.
  2. Prepare your custom bundle ZIP file with a role mapping file stored in a mappings folder. The role mapping file should contain:

    admin:
      - "cn=administrators,ou=groups,dc=example,dc=com"
    readonly:
      - "cn=users,ou=groups,dc=example,dc=com"
  3. In the advanced configuration editor, update your new Elasticsearch cluster with the custom bundle you have just created. Modify the user_bundles JSON attribute as shown in the following example:

    {
      "cluster_name": "xxxxxxx",
      "plan": {
    
        ...
    
        "elasticsearch": {
          "version": "5.5.1",
          "user_bundles": [
            {
              "name": "ldap-cert",
              "url": "https://www.myurl.com/ldapcert.zip", 
              "elasticsearch_version": "5.5.1"
            },
            {
              "name": "role-mappings",
              "url": "https://www.myurl.com/role-mappings.zip",
              "elasticsearch_version": "5.5.1"
            }
          ]
        }
      }

    The URLs for the bundle ZIP files (ldapcert.zip and role-mappings.zip) must be always available. Make sure you host the plugin artifacts internally in a highly available environment.

    If the bundle URL becomes unreachable (such as the URL changing at remote end or connectivity to the remote web server having issues) you might encounter boot loops.

  4. Custom bundles are unzipped in /app/config/BUNDLE_DIRECTORY_STRUCTURE, where BUNDLE_DIRECTORY_STRUCTURE is the directory structure within the bundle ZIP file itself. These file locations are needed in the next step.

    $ tree .
    .
    └── truststore
          └── keystore.ks

    In this example, the unzipped keystore file gets placed under /app/config/truststore/keystore.ks and the unzipped role mappings file under /app/config/mappings/role-mappings.yml.

Example: Custom SAML bundleedit

This example adds a custom SAML bundle for deployment level role-based access control (RBAC). To set platform level RBAC, see Configure RBAC.

  1. If your Identity Provider doesn’t publish its SAML metadata at an HTTP URL, or if your Elasticsearch cluster cannot reach that URL, you can upload the SAML metadata as a file.

    1. Prepare a ZIP file with a custom bundle that contains your Identity Provider’s metadata (metadata.xml) and store it in the saml folder.

      This bundle allows all Elasticsearch containers to access the metadata file.

    2. In the advanced configuration editor, update your Elasticsearch cluster configuration with the bundle you prepared in the previous step. Modify the user_bundles JSON attribute as shown in the following example:

      {
        "cluster_name": "REPLACE_WITH_YOUR_CLUSTER_NAME",
        "plan": {
      
          ...
      
          "elasticsearch": {
            "version": "6.4.1",
            "user_bundles": [
              {
                "name": "saml-metadata",
                "url": "https://www.MYURL.com/saml-metadata.zip", 
                "elasticsearch_version": "6.4.1"
              }
            ]
          }
        }

      The URL for the bundle ZIP file must be always available. Make sure you host the plugin artifacts internally in a highly available environment.

      If the bundle URL becomes unreachable (such as the URL changing at remote end or connectivity to the remote web server having issues) you might encounter boot loops.

      Custom bundles are unzipped in /app/config/BUNDLE_DIRECTORY_STRUCTURE, where BUNDLE_DIRECTORY_STRUCTURE is the directory structure within the ZIP file itself. These file locations are needed in the next step.

      In this example, the SAML metadata file is located in the path /app/config/saml/metadata.xml:

      $ tree .
      .
      └── saml
            └── metadata.xml
    3. Adjust your saml realm configuration accordingly:

          idp.metadata.path: /app/config/saml/metadata.xml 

      The path to the SAML metadata file that was uploaded