Merge pull request #325 from ritza-co/docs-18.14

Docs v18.14 release

docs/auto-discovery/agent-based-discovery.md

@@ -41,7 +41,7 @@ It can be run from the command line or can be scheduled using the relevant sched
   -device-customer string
     	default device customer
   -device-name-format int
-    	1 - hostname, 2 - hostname + domain, 3 - hostname and hostname+domain as alias, 4 - hostname+doman and hostname as alias (default 1)
+    	1 - hostname, 2 - hostname + domain, 3 - hostname and hostname+domain as alias, 4 - hostname+domain and hostname as alias (default 1)
   -device-object-category string
     	default device object category
   -device-service-level string
@@ -76,6 +76,8 @@ It can be run from the command line or can be scheduled using the relevant sched
     	default IP VRF group
   -light-mode
     	reduces CPU utilization by cost of discovery speed
+  -new-device-object-category
+      updates/overwrites the object category for the device
   -offline
     	doesn't connect with Device42, just prints the encrypted data to be sent
   -quiet

docs/auto-discovery/cloud-auto-discovery/aws-autodiscovery.mdx

@@ -178,6 +178,7 @@ _**Example of minimum policy**_ _(except for K8s cluster endpoints, since it is
         "elasticfilesystem:DescribeFileSystems",
         "elasticfilesystem:DescribeMountTargets",
         "elasticloadbalancing:Describe*",
+        "kms:DescribeKey",
         "kms:ListKeys",
         "kms:ListResourceTags",
         "lambda:GetAccountSettings",
@@ -328,51 +329,6 @@ Option 2:
     - make the assumable role available in the main account (dynamic discovery will pull it in if no accounts are listed, or if the main account is included in the manually added list of ID’s), 
     - or also attach the d42 minimum discovery policy to the user directly (requires selection of the “discover main account” box on the job).
 
-## Amazon API Autodiscovery
-
-### Amazon API Discovery Items
-
-<table><tbody><tr><td><strong>Cloud Service/Object Name</strong></td><td><strong>Where to locate in D42</strong></td><td>Accessed API</td><td>Information Generated</td></tr><tr><td>EC2 Instances</td><td>Devices --&gt; All Devices</td><td>&nbsp;</td><td>Service name, instance ID, OS platform, image ID, Status, etc.</td></tr></tbody></table>
-<br/>
-
-When discovering your Amazon Cloud via the Amazon API, Device42 authenticates against the **API URL** with your **AWS API Access Key** and **Secret Key**. To create a discovery job, please ensure you have these available. You can find or generate new AWS API Access keys via the AWS Console -> UserName Menu --> "My Security Credentials". Expand the "Access keys (access key ID and secret access key)" item, and "Create New Access Key" (or reference an existing one): 
-
-<ThemedImage
-  alt="Create an access key in AWS"
-  sources={{
-    light: useBaseUrl('/assets/images/cloud-discovery-aws/cloud-discovery-aws-8-light.png'),
-    dark: useBaseUrl('/assets/images/cloud-discovery-aws/cloud-discovery-aws-8-dark.png'),
-  }}
-/>
-
-### Setting Up an AWS API Discovery Job
-
-<ThemedImage
-  alt="Create AWS cloud discovery job"
-  sources={{
-    light: useBaseUrl('/assets/images/cloud-discovery-aws/cloud-discovery-aws-7-light.png'),
-    dark: useBaseUrl('/assets/images/cloud-discovery-aws/cloud-discovery-aws-7-dark.png'),
-  }}
-/>
-<br/><br/>
-
-1. Begin by setting **Cloud Type:** ‘Amazon API’ via the dropdown \[pictured\].
-2. Enter a "Name" for your Amazon AWS API discovery job.
-3. Enter the "URL" of the AWS API endpoint you are targeting, including the port if necessary. For URLs and other information on AWS API endpoints, reference the "Endpoints" section of [the AWS API documentation](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/Query-Requests.html#Using_Endpoints).
-4. Add your **AWS API Key ID** to the "API Key" field, followed by the corresponding **Amazon Secret Key** in the "Secret Key" field for the account to be discovered: You'll add both your API Key ID and Secret Key to Device42 as separate 'password' entries, and the procedure is the same as adding a new password: 
-    - Click the magnifying glass to bring up the credential selection screen
-    - Click the ‘Add Password’ button in the upper right-hand corner
-    - Enter your AWS API Key ID in the field labeled “Password:” - _The USERNAME FIELD IS NOT USED by cloud discoveries!_, and click "Save". Repeat the process and add a second entry for your Secret Key, as well. Note that Device42 stores these values encrypted; if desired, you may also set access permissions on your AWS credentials.
-5. In the **Region:** box, enter the region you are targeting, e.g. _us-east-1_.
-6. Set a discovery schedule if desired; Save and run your AWS API discovery!
-
-**Options for AWS API Discovery:**
-
-- **Action for Instance not found:** Choose how Device42 will handle the situation of an instance that was previously discovered not being found on subsequent discovery runs. Change Status will update the instance's status, while "Delete Instance" will delete the missing instance. The best choice for you depends on how you manage your infrastructure.
-- **Strip Domain Name:** Strips the domain name (everything after the first period) from the name as discovered before storing in Device42
-- **Object category for discovered devices:** Choose a category to assign to discovered devices
-- **Overwrite existing object categories:** Select this option to overwrite any previously assigned categories with the current selection
-
 ## Using AWS Roles To Discover Accounts Within Discovery Jobs
 
 AWS Cloud Discovery Jobs can use AWS roles to discover accounts. When the job includes the AWS role, the discovery job will dynamically grab multiple accounts from AWS. We previously (before v18.13) aimed to maintain a 1:1 relationship between roles and accounts. Now, a single role can discover multiple accounts. This enables AWS users to set up discovery and specify the precise account to create, or leave the account empty to have the discovery job create Cloud accounts as a result of the discovery.

docs/auto-discovery/cloud-auto-discovery/kubernetes-autodiscovery.md

@@ -9,40 +9,40 @@ sidebar_position: 6
 
 ### Kubernetes Discovery for AWS, Google Cloud, and MS Azure
 
-Kubernetes Discovery is available as an option for [Amazon AWS](auto-discovery/cloud-auto-discovery/aws-autodiscovery.mdx), [Google Cloud](auto-discovery/cloud-auto-discovery/google-cloud-platform-autodiscovery.md), and [Microsoft Azure](auto-discovery/cloud-auto-discovery/azure-autodiscovery.md) cloud autodiscovery jobs. Scroll down the Add Cloud Discovery page to select the _Kubernetes Discovery_ option.
+Kubernetes Discovery is available as an option for [Amazon AWS](auto-discovery/cloud-auto-discovery/aws-autodiscovery.mdx), [Google Cloud](auto-discovery/cloud-auto-discovery/google-cloud-platform-autodiscovery.md), and [Microsoft Azure](auto-discovery/cloud-auto-discovery/azure-autodiscovery.md) cloud autodiscovery jobs. Scroll down the Add Cloud Discovery page to select the **Kubernetes Discovery** option.
 
 ![](/assets/images/discovery_cloud_platforms_autodiscovery_kubernetes-autodiscovery1.png)
 
-You can also select an _Action for Resources not found:_ option to choose how to handle Kubernetes Cluster children resources not found in subsequent discovery.
+Select an option under **Action for Kubernetes Resources not found:** to choose how to handle Kubernetes Cluster children resources not found in subsequent discovery.
 
 ![](/assets/images/discovery_cloud_platforms_autodiscovery_kubernetes-autodiscovery2.png)
 
 Your cloud discovery job will now also include discovery of Kubernetes resources on the target cloud platform.
 
 ### Standalone Kubernetes Discovery
 
-To add a Standalone Kubernetes discovery job, you'll need either a Bearer Token or Basic Credentials. You'll also need to enter a URL and select an Action for Resources not found.
+To add a Standalone Kubernetes discovery job, choose between the **Bearer Token** and **Basic Credentials** options for authentication. You'll also need to enter a **URL** and select an option under **Action for Kubernetes Resources not found**.
 
-Optionally, you can also choose a Vendor and a VRF Group. Please note that all Vendors and VRF Groups are user-defined.
+Optionally, you can also choose a **Vendor** and a **VRF Group**. Please note that all vendors and VRF groups are user-defined.
 
 ![](/assets/images/discovery_cloud_platforms_autodiscovery_kubernetes-autodiscovery3.png)
 
 You can optionally set the **Service Level** (for example, "Development", "Deployment", or "Production") of the job to be applied to the discovered items. See [Service Level and Object Category Options](index.mdx#service-level-and-object-category-options) for details.
 
 ### View Discovered Kubernetes Resources
 
-Discovered Kubernetes resources appear in the Resources list page. Select _Resources > All Resources_ from the main menu to display the list page. Use the _Vendor Resource Type_ drop-down to choose the Kubernetes resources you want to see.
+Discovered Kubernetes resources appear in the Resources list page. Select **Resources > All Resources** from the main menu to display the list page. Use the **Vendor Resource Type** dropdown to choose the Kubernetes resources you want to see.
 
 ![](/assets/images/discovery_cloud_platforms_autodiscovery_kubernetes-autodiscovery4.png)
 
-Click on a _Resource Name_ to view that resource.
+Click on a **Resource Name** to view that resource.
 
 ![](/assets/images/discovery_cloud_platforms_autodiscovery_kubernetes-autodiscovery5.png)
 
 Click on the available links to see details about those resources.
 
 ![](/assets/images/discovery_cloud_platforms_autodiscovery_kubernetes-autodiscovery6.png)
 
-Click the Edit button at the top right to edit resource information. Editing is generally limited to adding or editing Notes or Tags or changing the In Service status or Level.
+Click the **Edit** button at the top right to edit resource information. Editing is generally limited to adding or editing **Notes** or **Tags**, or changing the **In Service** status or level.
 
 ![](/assets/images/discovery_cloud_platforms_autodiscovery_kubernetes-autodiscovery7.png)

docs/auto-discovery/database-discovery/index.mdx

@@ -23,6 +23,14 @@ Dynamic discovery can discover different ports to use. As of v16.17.00, Device42
 
 If you want to specify DB discovery details yourself, including the DB server port, server IP address, and DB access credentials, use [Database Connections Discovery](#database-connections-discovery-jobs) jobs (see below) to discover databases.
 
+### Discovery Exclusions
+
+Set discovery exclusions in **Tools > Settings > Global Settings** in the **Discovery Exclusions** section.
+
+If you enable the **Ignore DB Login Names** setting, DB login names will not be collected during database discovery.
+
+You can also specify interfaces, IP addresses, and MAC addresses to be ignored during discovery. 
+
 ## MS SQL Server DB Discovery (on Windows targets)
 
 Microsoft SQL Server (MSSQL) discovery is supported on discovery targets running Microsoft Windows and requires a separate set of credentials to authenticate to the database instance itself. Ensure these credentials have appropriate permissions to view the databases you are interested in discovering.

docs/auto-discovery/microsoft-dhcp-discovery.md

@@ -0,0 +1,29 @@
+---
+title: "Microsoft DHCP Discovery"
+sidebar_position: 4.8
+---
+
+# Microsoft DHCP Discovery
+
+As of v18.14, Microsoft DHCP Discovery has been added as an additional discovery type located under **Discovery > DHCP**. 
+
+Microsoft Dynamic Host Configuration Protocol (DHCP) is a service provided by the Microsoft Windows Server operating system. DHCP is a network management protocol used to dynamically assign IP addresses and other network configuration parameters (such as subnet mask, default gateway, DNS servers, etc.) to devices on a network.
+
+If you are already using Microsoft DHCP Servers in your environment, Microsoft DHCP Discovery can automatically populate records on discovered DHCP Servers, IP Addresses, and subnets, including additional DHCP details like DHCP Scope, State, Lease Duration, DNS information, and Start/End address ranges. 
+
+![](/assets/images/microsoft-dhcp-discovery/microsoft-dhcp-3.png)
+
+## Discovery
+
+Microsoft DHCP Discovery uses WMI by default but WinRM is also supported and can be optionally enabled in the job configuration. (Example Below)
+
+![](/assets/images/microsoft-dhcp-discovery/microsoft-dhcp-1.png)
+
+:::note
+If **Discover Using WinRM** is not enabled, you must have a WDS paired with the selected Remote Collector to use WMI. 
+:::
+
+## Miscellaneous
+The following miscellaneous discovery options are also available:
+
+![](/assets/images/microsoft-dhcp-discovery/microsoft-dhcp-2.png)

docs/auto-discovery/storage-arrays-autodiscovery/index.md

@@ -20,10 +20,10 @@ Use the links below for additional information about access protocols and minimu
 [See Dell/EMC Autodiscovery](auto-discovery/storage-arrays-autodiscovery/dell-emc-autodiscovery.md) for more information about the following storage arrays:
 
 - Dell Compellent
-- VNX or VMAX using EMC SMIS Providor
+- Dell PowerStore
+- VNX or VMAX using EMC SMIS Provider
 - EMC Data Domain
 - EMC Unity
-- EMC Unity
 - Isilon
 
 ### HP Arrays

docs/integration/external-integrations/delinea-secret-server-integration.md

@@ -0,0 +1,54 @@
+---
+title: "Delinea Secret Server Integration"
+sidebar_position: 8.5
+---
+
+# Delinea Secret Server Integration
+
+Each Device42 Autodiscovery job is configured to use one (or more) sets of system credentials. If you already use Delinea Secret Server to manage passwords and other secrets or simply don't want to use Device42 for this purpose, the Device42 Delinea Secret Server integration allows Device42 to securely store and retrieve these credentials externally as your primary secret management solution.
+
+Delinea Secret Server offers useful features such as automatic password rotation, which can be configured to rotate secrets per your specific corporate policies and industry guidelines.
+
+:::info
+Please note that passwords retrieved from Delinea Secret Server are not viewable in Device42.
+:::
+
+## Configuring Delinea Secret Server
+
+### Pre-requisites
+
+For the Delinea Secret Server integration to work, you will need to create a user account in Delinea Secret Server with the **View Secret** permission. 
+
+This user should also have view access to the desired folder(s) you would like Secrets retrieved from.
+
+While you can use any user account, it is _strongly recommended_ that you use a dedicated application account for Device42. Application accounts are restricted from logging into the UI and can only be used via the API. 
+
+## Configuring Device42
+
+- Select **Tools > Integrations > Delinea Secret Server** from the Device42 menu.
+
+![](/assets/images/delinea-secret-service-integration/Delinea_2.png)
+
+- Click on the **Edit** button in the bottom right corner and enter your Delinea Secret Server RESTful API information. (Example below)
+
+![](/assets/images/delinea-secret-service-integration/Delinea_3.png)
+
+- Verify connectivity by clicking the **Test Settings** button in the top right corner.
+
+![](/assets/images/delinea-secret-service-integration/Delinea_4.png)
+
+- The **Test Settings** button attempts to validate the supplied configuration settings by retrieving a token from Delinea Secret server. If a token is successfully retrieved, a message stating "Delinea Secret Server Settings Valid" should appear in the top right corner. (Example Success Response Below)
+
+![](/assets/images/delinea-secret-service-integration/Delinea_5.png)
+
+- If you run into configuration errors related to SSL errors, you may need to disable SSL Verification within the Delinea Secret Server configuration page before trying again. 
+
+![](/assets/images/delinea-secret-service-integration/Delinea_6.png)
+
+## Using the Device42 Delinea Secret Server Integration for Discovery
+
+To create a new password object using Delinea Secret Server, simply select Delinea Secret Server from the Password Storage drop-down menu:
+
+![](/assets/images/delinea-secret-service-integration/Delinea_1.png)
+
+**Note:** By default, both usernames and passwords are retrieved from Delinea Secret Server by looking up the secret using either **Secret Name** or **Secret ID**, depending on which was selected in the configuration. Regardless of which option is selected, the value used to do the lookup is assumed to be stored in the **Label** field of the related Secret in Device42. If there is no value for **Label** then the value is taken from the **Username** field instead. Usernames and passwords are parsed from the Secret returned by Delinea Secret Server using the slugs "username" and "password" respectively. You may also override the default slugs used by utilizing **Password Custom fields** named **username_slug** and **password_slug**.

docs/integration/external-integrations/hashicorp-vault-integration.md

@@ -0,0 +1,55 @@
+---
+title: "HashiCorp Vault Integration"
+sidebar_position: 12.5
+---
+
+# HashiCorp Vault Integration
+
+Each Device42 autodiscovery job is configured to use one (or more) sets of system credentials. If you already use HashiCorp Vault to manage passwords and other secrets, or simply don't want to use Device42 for this purpose, the Device42 HashiCorp Vault integration allows Device42 to securely store and retrieve these credentials externally as your primary secret management solution.
+
+HashiCorp Vault offers useful features such as automatic password rotation, which can be configured to rotate secrets per your specific corporate policies and industry guidelines.
+
+:::info
+Please note that passwords retrieved from HashiCorp Vault are not viewable in Device42.
+:::
+
+## Configuring HashiCorp Vault
+
+### Pre-requisites
+
+- **(Required) Role ID / Secret ID:** For the HashiCorp Vault integration to work, you will need to create an AppRole in HashiCorp Vault with a policy that grants "read" to the desired Secret Paths. 
+    - AppRole authentication is done by using both "RoleID" and "SecretID" as credentials. 
+    - Details on how to create an AppRole and retrieve the RoleID and SecretID can be found [here](https://developer.hashicorp.com/vault/docs/auth/approle).
+- **(Required) Secret Engine Path:** You will also need to specify the path to a valid K/V Version 1 or Version 2 secret engine to retrieve secrets from. Example: secret, kv, foo, bar, etc.
+- **(Optional) Namespace:** If you're leveraging Multi-Tenancy with Namespaces then you will need to include the Namespace as well. Note: This is Limited to Vault Enterprise Standard or HCP Vault Clusters.
+
+
+## Configuring Device42
+
+- Select **Tools > Integrations > HashiCorp Vault** from the Device42 menu.
+
+![](/assets/images/hashicorp-vault-integration/HashiCorp_2.png)
+
+- Click on the **Edit** button in the bottom right corner and enter your HashiCorp Vault RESTful API information. (Example below)
+
+![](/assets/images/hashicorp-vault-integration/HashiCorp_3.png)
+
+- Verify connectivity by clicking the **Test Settings** button in the top right corner.
+
+![](/assets/images/hashicorp-vault-integration/HashiCorp_4.png)
+
+- The **Test Settings** button attempts to validate the supplied configuration settings by retrieving a token from HashiCorp Vault. If a token is successfully retrieved, a message stating "HashiCorp Vault Settings Valid" should appear in the top right corner. (Example Success Response Below)
+
+![](/assets/images/hashicorp-vault-integration/HashiCorp_5.png)
+
+- If you run into configuration errors related to SSL errors, you may need to disable SSL Verification within the HashiCorp Vault configuration page before trying again. 
+
+![](/assets/images/hashicorp-vault-integration/HashiCorp_6.png)
+
+## Using the Device42 HashiCorp Vault Integration for Discovery
+
+To create a new password object using HashiCorp Vault, simply select HashiCorp Vault from the **Password Storage** drop-down menu:
+
+![](/assets/images/hashicorp-vault-integration/HashiCorp_1.png)
+
+**Note:** By default, both usernames and passwords are retrieved from HashiCorp Vault by looking up the secret using its path within the vault. The value used to do the lookup is assumed to be stored in the **Label** field of the related Secret in Device42. If there is no value for **Label** then the value is taken from the **Username** field instead. Usernames and passwords are parsed from the Secret returned by HashiCorp Vault using the slugs "username" and "password" respectively. You may also override the default slugs used by utilizing **Password Custom fields** named **username_slug** and **password_slug**.