Skip to content

Commit

Permalink
Merge pull request #328 from ritza-co/docs-18.14.1
Browse files Browse the repository at this point in the history
Docs v18.14.1 release (week 14, 2024)
  • Loading branch information
sixhobbits authored Apr 15, 2024
2 parents 2dc73b3 + 680fe24 commit 3c4b1b8
Show file tree
Hide file tree
Showing 28 changed files with 303 additions and 30 deletions.
150 changes: 143 additions & 7 deletions docs/auto-discovery/cloud-auto-discovery/aws-autodiscovery.mdx
Original file line number Diff line number Diff line change
Expand Up @@ -139,7 +139,7 @@ _**K8s cluster endpoints access per K8s RBAC setup**_
- /apis/apps/v1/deployments?watch=False OR /apis/extensions/v1beta1/deployments?watch=False (depends on k8s version)
- /apis/networking.k8s.io/v1beta1/ingresses?watch=False OR /apis/extensions/v1beta1/ingresses?watch=False (depends on k8s version)

_**Example of minimum policy**_ _(except for K8s cluster endpoints, since it is controlled by K8s RBAC)._
_**Example IAM Policy**_ _(except for K8s cluster endpoints, since it is controlled by K8s RBAC)._

```
{
Expand Down Expand Up @@ -191,6 +191,7 @@ _**Example of minimum policy**_ _(except for K8s cluster endpoints, since it is
"organizations:ListAccountsForParent",
"organizations:ListOrganizationalUnitsForParent",
"organizations:ListRoots",
"organizations:ListTagsForResource",
"rds:Describe*",
"rds:ListTagsForResource",
"redshift:DescribeClusters",
Expand Down Expand Up @@ -299,7 +300,7 @@ Device42 adds the new AWS Role to the roles list; it will also appear in the Ava

2. We would need an account that uses just accountID and one that would be with the Require ExternalID option - Note no requirement for MFA option at this time

3. Policy to be added - use the example minimum policy needed for discovery from our docs site [here](auto-discovery/cloud-auto-discovery/index.mdx)
3. Policy to be added - use the example policy needed for discovery from our docs site [here](auto-discovery/cloud-auto-discovery/index.mdx)

2. From the Sub (or separate)-account

Expand All @@ -315,21 +316,156 @@ Set Up

Option 1:

- Keypair user must be deployed into the org’s root account
- Key/pair user must be deployed into the org’s root account.
- This user policy must have at a minimum the following rights:
- `sts:assumerole`
- `organizations:listaccounts`
- A role must be added to all accounts where discovery is desired, with the same role name used in every account where discovery is desired
- The minimum d42 discovery policy must be granted to the role
- For role config within D42, do not add any accounts to the role
- A role must be added to all accounts where discovery is desired, with the same role name used in every account where discovery is desired.
- The Device42 discovery policy must be granted to the role.
- For role config within Device42, do not add any accounts to the role.
- At this time, we cannot use dynamic account discovery to discover roles which use external ID values

Option 2:
- If you don't want to follow the steps above, you can either:
- 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).
- or also attach the Device42 discovery policy to the user directly (requires selection of the “discover main account” box on the job).

## 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.

## Setting up Environment Credentials using EC2 Instance Profiles
In 18.14, you can now perform AWS discovery without the need to supply any form of long-term, programmatic credentials by leveraging Instance Profiles / IAM roles for Amazon EC2 instances.

Support for this comes in the form of a new discovery option called 'Use Environment Credentials', which when enabled, allows the discovery job to be saved without selecting an Access Key ID or Secret Key in the job configuration.

![](/assets/images/cloud-discovery-aws/aws-1.png)

**Note:** This is only possible when using a AWS hosted Main Appliance or Remote Collector for discovery as it relies on internal AWS mechanisms.

### Configuration
1. **Deploy a Main Appliance or Remote Collector within AWS**
2. **Create a new IAM Policy**

- 2.1. On the IAM Policy creation screen, click on 'JSON' in the policy editor and copy/paste one of the policies below based on your desired discovery configuration:
- Option 1: Single Account Discovery

Please refer to the example discovery policy above.

- Option 2: Role Assumption Using Static Account Discovery

This option is good if you have a need to specify External IDs when assuming roles, as Dynamic Account Discovery does not support role assumption using External IDs.

*Example IAM Policy*

```
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"sts:assumerole"
],
"Resource": [
"*"
]
}
]
}
```

- Option 3: Role Assumption Using Dynamic Account Discovery

This option is good if you want to discover resources in all member accounts without the need to specify individual Account IDs.

**Note:** This requires the associated Remote Collector or Main Appliance to be deployed within the organization's root (management) account.

See: [Setting Up Dynamic Account Discovery Roles](#setting-up-dynamic-account-discovery-roles) for more details on configuring Dynamic Account Discovery.

*Example IAM Policy*

```
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"sts:assumerole",
"organizations:listaccounts"
],
"Resource": [
"*"
]
}
]
}
```

- 2.2. Once you've confirmed you have the appropriate permission set selected, click on next, give the policy a name and description and then click on 'Create Policy'.

3. **Create a new IAM Role**

- 3.1. On the IAM Role creation screen, select 'AWS service' as the trusted entity type and 'EC2' as the Service or use case. Click Next.
- 3.2. On the add permissions screen, search for and select the policy created in step 2. Click on next, give the role a name and description and then click on 'Create Role'.

For those that may be looking to do the role preparation via the AWS CLI and not within the AWS Management Console, you can reference the trust policy below.

*Example Trust Policy*

```
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"sts:AssumeRole"
],
"Principal": {
"Service": [
"ec2.amazonaws.com"
]
}
}
]
}
```

4. **Attach the role**
- 4.1. From the EC2 Instances list page, select the EC2 instance created in step 1. Then click on 'Actions' -> 'Security' -> 'Modify IAM role'.
- 4.2. From the 'Modify IAM role' page, select the IAM Role created in step 3 and then click 'Update IAM role'.

5. **Additional Member Account Configuration for Role Assumption Using Static / Dynamic Account Discovery**

**Note:** If you're configuring Single Account Discovery, then there are no remaining steps to be done. If you've opted instead for Role Assumption using static or dynamic account discovery, then continue following the steps below:

- 5.1 Create the discovery policy in each member account to be discovered.

Follow step 2 again but this time use the example discovery policy above.

- 5.2 Create the discovery role in each member account to be discovered.

Follow step 3 again but this time select 'Custom trust policy' instead of 'AWS service'. Copy/paste the trust policy below and then at the add permissions screen, search for and select the discovery policy created in the previous step.

*Example Trust Policy*
```
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::ROOT_ACCOUNT_ID:role/EC2_D42_RC_ROLE"
},
"Action": "sts:AssumeRole"
}
]
}
```

**Note:** Be sure to replace `ROOT_ACCOUNT_ID` and `EC2_D42_RC_ROLE` with your own values.

- ROOT_ACCOUNT_ID: This is the root account ID where the role configured in step 3 resides
- EC2_D42_RC_ROLE: This is the name of the role in the root account to establish a trust with
Original file line number Diff line number Diff line change
Expand Up @@ -280,3 +280,10 @@ In the Device42 Appliance Manager, ensure that the Username field has a value of

Next, you click on **Save and Continue**. Then you can **Run** the job immediately. Or you can save it and have it run on a regular schedule.

### Azure Cloud Account Tags

Select your Azure cloud account from the list page under **Infrastructure > Cloud Infrastructure > Cloud Accounts**.

If available, the discovered account-level tags will be listed under the **Vendor Custom Fields** section.

![Azure cloud account tags](/assets/images/azure-cloud-account-tags.png)
Original file line number Diff line number Diff line change
Expand Up @@ -46,4 +46,12 @@ _Data discovered on the Google Cloud Platform is similar to what you might be us

**Service Level Option**

You can 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.
You can 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.

### GCP Account Tags

Select your Google cloud account from the list page under **Infrastructure > Cloud Infrastructure > Cloud Accounts**.

If available, the discovered account-level tags will be listed under the **Vendor Custom Fields** section.

![GCP cloud account tags](/assets/images/GCP-tags.png)
41 changes: 40 additions & 1 deletion docs/auto-discovery/enrichai-data/index.md
Original file line number Diff line number Diff line change
Expand Up @@ -73,6 +73,37 @@ In addition, if the entry is new or unique, it may require the EnrichAI service
"vendor": "brocade"
},
"req_id": "vendor_3"
},
{
"context_info": {
"discovery_type": "",
"hardware_name": "",
"hardware_vendor_name": ""
},
"entity_type": "software",
"parameters": {
"category": "",
"hidden_name": "(https://support.microsoft.com/help/4598481) KB4598481",
"name": "KB4598481",
"vendor": "Microsoft",
"version": "KB4598481"
},
"req_id": "software_912"
},
{
"context_info": {
"discovery_type": "vserver/*nix",
"hardware_name": "",
"hardware_vendor_name": ""
},
"entity_type": "service",
"parameters": {
"description": "Apache Tomcat Web Application Container",
"displayName": "tomcat",
"prettyName": "tomcat",
"vendor": ""
},
"req_id": "service_5803"
}
]
}
Expand All @@ -99,6 +130,14 @@ Device42 also currently displays EnrichAI Data information on OS and vendor view

![](/assets/images/18.04.00_EnrichAI_vendor-view-page.jpg)

:::info
## EnrichAI Data Handling and Security Practices

1. No personal or personally identifiable data is maintained by the EnrichAI service.
2. Data sent to EnrichAI is not associated with or tracked to the calling system or installation.
3. Unmatched values (values that do not have a corresponding match in EnrichAI) are stored for future mining and resolution. This storage has no association with the calling system or installation.
4. Only Device42 personnel work with these non-identifiable data elements.
5. Data collected for future enrichment mining is stored in the United States.

:::note
Device42 reserves the right to make changes and updates to the internal matching algorithm and or the golden records that are provided with this service.
:::
Original file line number Diff line number Diff line change
Expand Up @@ -3,6 +3,9 @@ title: "Linux & Unix Server Autodiscovery"
sidebar_position: 16
---

import ThemedImage from '@theme/ThemedImage'
import useBaseUrl from '@docusaurus/useBaseUrl'

Device42 supports SSH-based Linux and UNIX discovery from within the main appliance (v13.2+). For a full list of supported Linux/UNIX operating systems, please visit [Device42 Supported Operating Systems.](auto-discovery/operating-systems-supported-in-auto-discovery.md)

## Information Discovered
Expand Down Expand Up @@ -60,33 +63,53 @@ Before configuring an ssh-based discovery job, please be sure you have your SSH

Depending on permissions granted and your configured password policies, account lock-out could result in an otherwise completely avoidable outage. You, the customer, are responsible for any such behavior that might result if you choose to ignore this requirement.

## Option To Ignore IPs/MAC Addresses
### Option To Ignore IPs/MAC Addresses

You can ignore IP and MAC addresses from being included in our database during autodiscovery. Devices with these addresses will still be discovered but the detailed information that would typically be collected and stored is ignored.
You can ignore IP and MAC addresses from being included in our database during autodiscovery. Devices with these addresses will still be discovered but the detailed information that would typically be collected and stored is ignored.

Configure rules to ignore IP and MAC addresses for a specific job when creating or editing the job.
Configure rules to ignore IP and MAC addresses for a specific job when creating or editing the job.

![Ignore IPs and MACs](/assets/images/ip-mac-ignore.png)
![Ignore IPs and MACs](/assets/images/ip-mac-ignore.png)

Globally, you can add an **Exclusion** to ignore IP and MAC addresses for all jobs by navigating to **Tools > Settings > Global Settings** on the Main Appliance.
Globally, you can add an **Exclusion** to ignore IP and MAC addresses for all jobs by navigating to **Tools > Settings > Global Settings** on the Main Appliance.

* * *

### Exclusions

![](/assets/images/WEB-728_linux-unix-ad-exclusions.png)

**Exclude Server(s)**: List of server IPs to exclude from discovery - this is useful for ignoring individual IPs when the discovery target is specified as range or CIDR block.
**Exclude Service Port Client IPs**: Do not discover client connections on specified listening ports.
**Remote IP Exclusion**: Do not discover connections to or from any of these remote IPs.

### Naming Options

![](/assets/images/WEB-728_linux-unix-ad-naming-optionhost-discovery.png)
<ThemedImage
alt="Naming Options"
sources={{
light: useBaseUrl('/assets/images/linux-unix-server-auto-discovery/nix-naming-options-light.png'),
dark: useBaseUrl('/assets/images/linux-unix-server-auto-discovery/nix-naming-options-dark.png'),
}}
/>

**Strip domain suffix**: strips the domain suffix from discovered servers - _[see the next section for hostname config details]._
**Domains to strip**: Ordered list of domains to strip from hostname, one per line - if blank, full domain stripped; if specified, the first match is stripped.
**Set the device name as the name given in the server field of the autodiscovery job**: if checked & discovering via hostname/FQDN, the device will be named using the discovery target name provided.
**Overwrite existing device hostname with discovered hostname**: Check this option to give precedence to the discovered hostname.
**Device Name Format**: select desired device naming format; see ["Configuring hostname discovery details"](auto-discovery/linux-unix-server-auto-discovery.md#section-7) below for explanations.

![](/assets/images/WEB-728_linux-unix-ad-exclusions.png)
### Host Discovery

<ThemedImage
alt="Host Discovery options"
sources={{
light: useBaseUrl('/assets/images/linux-unix-server-auto-discovery/nix-host-discovery-light.png'),
dark: useBaseUrl('/assets/images/linux-unix-server-auto-discovery/nix-host-discovery-dark.png'),
}}
/>

**Exclude Server(s)**: List of server IPs to exclude from discovery - _[Useful to ignore individual IPs when discovery target specified as range or CIDR block]_
**Exclude Service Port Client IPs**: do not discover client connections on specified listening ports.
**Remote IP Exclusion**: do not discover any connections to/from any of these remote IPs.
Enabling the **Discover ProviderID/CloudID** option reveals the **Provider Token** option, which might be needed for authentication with the cloud service provider.

* * *

Expand Down
7 changes: 7 additions & 0 deletions docs/auto-discovery/remote-collector-rc.md
Original file line number Diff line number Diff line change
Expand Up @@ -9,6 +9,13 @@ The Remote Collector _(aka the "RC")_ is a virtual appliance that is deployed se

You may configure an unlimited number of remote collector appliances as needed across your environment. RCs facilitate SNMP, IPMI, hypervisor and other auto discoveries across networks with only https access required, eliminating the need to open numerous ports up across network segments.

### RC Sizing Recommendations

For one RC per 1000 workloads, the sizing recommendations are:
- 2 vCPU
- 4GB RAM
- 50GB vDisk

## RC Installation and Configuration

To download the Remote Collector, head to our [Auto-Discovery tools download page.](https://www.device42.com/autodiscovery/); Click the Download button under "D42 Remote Collector", which should be found at the top of the page.
Expand Down
Loading

0 comments on commit 3c4b1b8

Please sign in to comment.