You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: articles/virtual-machines/linux/disk-encryption-faq.md
+1-1Lines changed: 1 addition & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -95,7 +95,7 @@ You can't apply Azure Disk Encryption on your custom Linux image. Only the galle
95
95
96
96
## Can I apply updates to a Linux Red Hat VM that uses the yum update?
97
97
98
-
Yes, you can perform a yum update on a Red Hat Linux VM. For more information, see [Linux package management behind a firewall](disk-encryption-troubleshooting.md#linux-package-management-behind-a-firewall).
98
+
Yes, you can perform a yum update on a Red Hat Linux VM. For more information, see [Azure Disk Encryption on an isolated network](disk-encryption-isolated-network.md).
99
99
100
100
## What is the recommended Azure disk encryption workflow for Linux?
title: Azure Disk Encryption on an isolated network
3
+
description: This article provides troubleshooting tips for Microsoft Azure Disk Encryption for Linux VMs.
4
+
author: msmbaldwin
5
+
ms.service: security
6
+
ms.topic: article
7
+
ms.author: mbaldwin
8
+
ms.date: 02/27/2020
9
+
10
+
ms.custom: seodec18
11
+
12
+
---
13
+
# Azure Disk Encryption on an isolated network
14
+
15
+
When connectivity is restricted by a firewall, proxy requirement, or network security group (NSG) settings, the ability of the extension to perform needed tasks might be disrupted. This disruption can result in status messages such as "Extension status not available on the VM."
16
+
17
+
## Package management
18
+
19
+
Azure Disk Encryption depends on a number of components, which are typically installed as part of ADE enablement if not already present. When behind a firewall or otherwise isolated from the Internet, these packages must be pre-installed or available locally.
20
+
21
+
Here are the packages necessary for each distribution. For a full list of supported distros and volume types, see [supported VMs and operating systems](disk-encryption-overview.md#supported-vms-and-operating-systems).
On Red Hat, when a proxy is required, you must make sure that the subscription-manager and yum are set up properly. For more information, see [How to troubleshoot subscription-manager and yum problems](https://access.redhat.com/solutions/189533).
31
+
32
+
When packages are installed manually, they must also be manually upgraded as new versions are released.
33
+
34
+
## Network security groups
35
+
Any network security group settings that are applied must still allow the endpoint to meet the documented network configuration prerequisites for disk encryption. See [Azure Disk Encryption: Networking requirements](disk-encryption-overview.md#networking-requirements)
36
+
37
+
## Azure Disk Encryption with Azure AD (previous version)
38
+
39
+
If using [Azure Disk Encryption with Azure AD (previous version)](disk-encryption-overview-aad.md), the [Azure Active Directory Library](../../active-directory/azuread-dev/active-directory-authentication-libraries.md) will need to be installed manually for all distros (in addition to the packages appropriate for the distro, as [listed above](#package-management)).
40
+
41
+
When encryption is being enabled with [Azure AD credentials](disk-encryption-linux-aad.md), the target VM must allow connectivity to both Azure Active Directory endpoints and Key Vault endpoints. Current Azure Active Directory authentication endpoints are maintained in sections 56 and 59 of the [Office 365 URLs and IP address ranges](https://docs.microsoft.com/office365/enterprise/urls-and-ip-address-ranges) documentation. Key Vault instructions are provided in the documentation on how to [Access Azure Key Vault behind a firewall](../../key-vault/key-vault-access-behind-firewall.md).
42
+
43
+
### Azure Instance Metadata Service
44
+
45
+
The virtual machine must be able to access the [Azure Instance Metadata service](instance-metadata-service.md) endpoint, which uses a well-known non-routable IP address (`169.254.169.254`) that can be accessed only from within the VM. Proxy configurations that alter local HTTP traffic to this address (for example, adding an X-Forwarded-For header) are not supported.
46
+
47
+
## Next steps
48
+
49
+
- See more steps for [Azure disk encryption troubleshooting](disk-encryption-troubleshooting.md)
50
+
-[Azure data encryption at rest](../../security/fundamentals/encryption-atrest.md)
Copy file name to clipboardExpand all lines: articles/virtual-machines/linux/disk-encryption-troubleshooting.md
+1-15Lines changed: 1 addition & 15 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -92,21 +92,7 @@ Before the next attempt, reevaluate the characteristics of the VM and make sure
92
92
93
93
## Troubleshooting Azure Disk Encryption behind a firewall
94
94
95
-
When connectivity is restricted by a firewall, proxy requirement, or network security group (NSG) settings, the ability of the extension to perform needed tasks might be disrupted. This disruption can result in status messages such as "Extension status not available on the VM." In expected scenarios, the encryption fails to finish. The sections that follow have some common firewall problems that you might investigate.
96
-
97
-
### Network security groups
98
-
Any network security group settings that are applied must still allow the endpoint to meet the documented network configuration [prerequisites](disk-encryption-overview.md#networking-requirements) for disk encryption.
99
-
100
-
### Azure Key Vault behind a firewall
101
-
102
-
When encryption is being enabled with [Azure AD credentials](disk-encryption-linux-aad.md#), the target VM must allow connectivity to both Azure Active Directory endpoints and Key Vault endpoints. Current Azure Active Directory authentication endpoints are maintained in sections 56 and 59 of the [Office 365 URLs and IP address ranges](https://docs.microsoft.com/office365/enterprise/urls-and-ip-address-ranges) documentation. Key Vault instructions are provided in the documentation on how to [Access Azure Key Vault behind a firewall](../../key-vault/key-vault-access-behind-firewall.md).
103
-
104
-
### Azure Instance Metadata Service
105
-
The VM must be able to access the [Azure Instance Metadata service](../windows/instance-metadata-service.md) endpoint which uses a well-known non-routable IP address (`169.254.169.254`) that can be accessed only from within the VM. Proxy configurations that alter local HTTP traffic to this address (for example, adding an X-Forwarded-For header) are not supported.
106
-
107
-
### Linux package management behind a firewall
108
-
109
-
At runtime, Azure Disk Encryption for Linux relies on the target distribution’s package management system to install needed prerequisite components before enabling encryption. If the firewall settings prevent the VM from being able to download and install these components, then subsequent failures are expected. The steps to configure this package management system can vary by distribution. On Red Hat, when a proxy is required, you must make sure that the subscription-manager and yum are set up properly. For more information, see [How to troubleshoot subscription-manager and yum problems](https://access.redhat.com/solutions/189533).
95
+
See [Disk Encryption on an isolated network](disk-encryption-isolated-network.md)
The following APIs are available through the metadata endpoint:
@@ -537,38 +404,6 @@ Nonce is an optional 10-digit string. If not provided, IMDS returns the current
537
404
538
405
The signature blob is a [pkcs7](https://aka.ms/pkcs7) signed version of document. It contains the certificate used for signing along with the VM details like vmId, sku, nonce, subscriptionId, timeStamp for creation and expiry of the document and the plan information about the image. The plan information is only populated for Azure Market place images. The certificate can be extracted from the response and used to validate that the response is valid and is coming from Azure.
539
406
540
-
#### Retrieving attested metadata in Windows Virtual Machine
541
-
542
-
**Request**
543
-
544
-
Instance metadata can be retrieved in Windows via the PowerShell utility `curl`:
Invoke-RestMethod -Headers @{"Metadata"="true"} -URI "http://169.254.169.254/metadata/attested/document?api-version=2018-10-01&nonce=1234567890" -Method get
554
-
```
555
-
556
-
Api-version is a mandatory field. Refer to the service availability section for supported API versions.
557
-
Nonce is an optional 10-digit string. If not provided, IMDS returns the current UTC timestamp in its place. Due to IMDS's caching mechanism, a previously cached nonce value may be returned.
558
-
559
-
**Response**
560
-
561
-
> [!NOTE]
562
-
> The response is a JSON string. The following example response is pretty-printed for readability.
The signature blob is a [pkcs7](https://aka.ms/pkcs7) signed version of document. It contains the certificate used for signing along with the VM details like vmId, sku, nonce, subscriptionId, timeStamp for creation and expiry of the document and the plan information about the image. The plan information is only populated for Azure Market place images. The certificate can be extracted from the response and used to validate that the response is valid and is coming from Azure.
In cases where the intermediate certificate cannot be downloaded due to network constraints during validation, the intermediate certificate can be pinned. However, Azure will roll over the certificates as per standard PKI practice. The pinned certificates would need to be updated when roll over happens. Whenever a change to update the intermediate certificate is planned, the Azure blog will be updated and Azure customers will be notified. The intermediate certificates can be found [here](https://www.microsoft.com/pki/mscorp/cps/default.htm). The intermediate certificates for each of the regions can be different.
864
699
865
-
### Failover Clustering in Windows Server
866
-
867
-
For certain scenarios, when querying Instance Metadata Service with Failover Clustering, it is necessary to add a route to the routing table.
868
-
869
-
1. Open command prompt with administrator privileges.
870
-
871
-
2. Run the following command and note the address of the Interface forNetwork Destination (`0.0.0.0`)in the IPv4 Route Table.
872
-
873
-
```bat
874
-
route print
875
-
```
876
-
877
-
> [!NOTE]
878
-
> The following example output from a Windows Server VM with Failover Cluster enabled contains only the IPv4 Route Table for simplicity.
Instance Metadata Service can provide details about the storage disks associated with the VM. This data can be found at the instance/compute/storageProfile endpoint.
0 commit comments