About Silk
Silk offers the flexibility and high performance that organizations need to leverage the public cloud. The Silk Data Virtualization Platform is a combination of tested and packaged software and services. Silk provides a rich set of data services, machine learning, analytics, and policy-based automation and orchestration.
Use this guide to learn about the prerequisites to successfully deploy Silk onto your instance of Microsoft Azure.
Refer to the following guides for more information about the prerequisites, steps involved, architecture, security, and networking requirements to successfully deploy Silk onto your instance of Microsoft Azure.
- Deploying Silk – Overview & Background
- How to Deploy Silk
- Architecture Requirements to Deploy Silk
- Security Requirements to Deploy Silk
- Networking Requirements to Deploy Silk
Security: IAM Roles & Permissions – To Deploy Silk Flex
There are certain security requirements needed to deploy Silk Flex as described below.
- The operator needs Azure Marketplace purchasing permissions.
- The operator needs permission to create a storage account for diagnostic data as part of the Silk Flex deployment from the Azure Marketplace
- The operator needs Owner access to the Resource Group.
- With Owner access, the operator is then able to assign the Owner role for the Resource Group to the Silk Flex instance:
- Role: Owner
- Scope: Resource Group
- Additionally, if the Silk Flex instance is deployed to an existing VNET, the operator will need the ability to create a custom role with the following permissions and assign it to the Silk Flex instance.
- Note: If Silk Flex is allowed to create all the required VNETs itself (for Silk Flex, Silk Data Pods (SDP), and for Management) no additional VNET IAM modifications will be needed.
- Table 1 and Table 2 below describe the full list of required permissions to deploy Silk Flex to an existing VNET, for the initial deployment and for regular use of Silk Flex.
Table 1: Required permissions to deploy Silk Flex to an existing VNET.
# | Vnet Permissions | Initial Deployment | Mandatory Regular Operation | Optional |
Create cluster | E.g. to replace a d.node, Detach a Pv2 instance, etc. | Delete cluster | ||
1 | Microsoft.Network/virtualNetworks/read | |||
2 | Microsoft.Network/virtualNetworks/write | |||
3 | Microsoft.Network/virtualNetworks/subnets/read | |||
4 | Microsoft.Network/virtualNetworks/subnets/write | |||
5 | Microsoft.Network/virtualNetworks/subnets/delete | |||
6 | Microsoft.Network/virtualNetworks/subnets/join/action | |||
7 | Microsoft.Network/networkSecurityGroups/read | |||
8 | Microsoft.Network/networkSecurityGroups/write | |||
9 | Microsoft.Network/networkSecurityGroups/delete | |||
10 | Microsoft.Network/networkInterfaces/read | |||
11 | Microsoft.Network/networkInterfaces/write | |||
12 | Microsoft.Network/networkInterfaces/join/action | |||
13 | Microsoft.Network/networkInterfaces/delete |
Table 2: Required permissions to deploy Silk Flex to an existing VNET only if Silk Flex is on a different VNET than the Silk Data Pod
# | Vnet Permissions | Initial Deployment | Mandatory Regular Operation | Optional |
Create cluster | E.g. to replace a d.node, Detach a Pv2 instance, etc. | Delete cluster | ||
1 | Microsoft.Network/virtualNetworks/read | |||
2 | Microsoft.Network/virtualNetworks/write | |||
3 | Microsoft.Network/virtualNetworks/subnets/read | |||
4 | Microsoft.Network/virtualNetworks/subnets/write |
Security: IAM Roles & Permissions – Silk c.node and d.node Image Copy Process
There are certain security requirements needed for the Silk c.node and d.node image copy process as described below.
- The operator needs permission to create a storage account for the copy process for the Silk c.node and d.node images.
- The operator needs the permissions to use an Azure cloud shell.
- The operator needs to be within the scope of the network access control list of the storage account, in order access the Silk repository and the destination resource group.
Security: IAM Roles & Permissions – To create a Silk Data Pod
There are certain security requirements needed to create a Silk Data Pod (SDP) described below.
- The operator needs permissions to create proximity placement groups and availability sets.
Security: Network Security Group Ports – Silk Flex Cluster Configuration
There are certain security requirements needed to configure the Silk Flex cluster as described below.
- Silk Flex requires SMTP for reporting health telemetry to Silk support.
- Note: If using a SMTP server, Port 25 is generally used. If email authentication is used, opening Port 587 is recommended for mail relay to Silk support.
- Modification of the firewalls to allow communication over TCP port 443 between the user’s computer(s) and the subnets host Silk Flex and the Silk Dat Pods is required.
- Modification of the firewalls will also be required in subsequent steps and during regular use of the Silk Flex instance(s) and the Silk Data Pod(s).
Security: Network Security Group Ports – To Set Up iSCSI Configuration
There are certain security requirements needed to set up the iSCSI configuration between the hosts and a Silk Data Pod (SDP) as described below.
- Host connectivity to the SDPs is via iSCSI protocol over port 3260.
- If hosts are deployed on a separate vNET from the SDPs, iSCSI communication must be allowed and must not be inspected via a security appliance.
- Note: With the amount of data traffic between the host initiators and the SDP targets, the security appliance will be overwhelmed and would likely result in extremely high latencies.
- If deploying Silk in a High Availability and/or Disaster Recovery architecture, Silk requires the following: a. Peer the Source SDP VNET with the DR SDP VNET
- b. Modification to firewalls to allow TCP ports 55855 and 55856 between the source and target SDPs for the Data2 Subnets and port 443 for the external management subnets.
Security: Firewall Rules – To Deploy a Silk Data Pod
There are certain security requirements to deploy a Silk Data Pod (SDP) as described below.
- In addition to the Flex Instance, the SDP requires an SMTP relay to report on health telemetry.
- If there is a firewall that manages access control, Silk suggests enabling the entire SDP Management Subnet as the source for the access control exception to the SMTP relay.
Security: Firewall Rules – For the Silk Data Pod iSCSI Connection Configuration
There are certain security requirements to configure the Silk Data Pod (SDP) iSCSI connection as described below.
- If using Linux for the operating system on the virtual machines hosting the databases (e.g. for Oracle databases), Silk will need to update the operating system. You can do this either automatically if you can configure the firewall to allow access to the OEL and RHEL yum repositories or by updating manually.
Security: Firewall Rules – Replication
Use the following network replication configuration to deploy Silk in a High Availability and/or Disaster Recovery architecture.
- In case the internet is used to connect between the two replication sites (for example, using a VPN), the organization’s firewall settings should be configured to allow the Silk Data Pod incoming and outgoing replication and management traffic.
- The firewall TCP ports that are required as bidirectionally opened are: 55855, 55856, 55857, 55858.
Security: SMTP Whitelisting – Silk Flex Cluster Configuration
Use the following configurations for SMTP whitelisting for the Silk Flex Cluster Configuration.
- The system will need to be able to send emails to the addresses listed below to support Silk’s alerting system and callhome.
- If required, please add these email addresses to the whitelist and explicitly allow SMTP from the Silk Flex and SDP Management subnets:
callhome@clarity.silk.tech
alerts@cs.silk.tech
- The SMTP relay needs to allow attachments up to 10 MB in size.
- Silk recommends enabling the entire SDP Management subnet as the source for the access control exception to the SMTP relay.
Security: Azure policies
Please use the following configurations for the Azure policies for the Silk Data Pod (SDP) deployment.
- Your security team needs to make an exception to allow Proximity Placement Groups (PPGs), storage accounts, and Availability Sets to support the SDP deployment.
Resources and Properties
The following is a list of all deployed resource types and their associated properties. Please check this against any Azure deployment policy restrictions.
Microsoft.Storage/storageAccounts
- networkAcls
- bypass – None
- defaultAction – Deny
- allowBlobPublicAccess – false
- publicNetworkAccess – Disabled
Microsoft.Network/publicIPAddresses (Optional)
- publicIPAllocationMethod – Static
Microsoft.Compute/availabilitySets
- platformUpdateDomainCount – 20
- platformFaultDomainCount – 3
Microsoft.Compute/proximityPlacementGroups
- proximityPlacementGroupType – Standard
Microsoft.Compute/virtualMachines
- availabilitySet
- proximityPlacementGroup
- hardwareProfile
- vmSize – Standard_L#s_v3 andStandard_D#s_v5
- osDisk
- managedDisk
- storageAccountType – Standard_LRS andPremium_LRS
- deleteOption – Detach
- managedDisk
- osProfile
- linuxConfiguration
- disablePasswordAuthentication – false
- provisionVMAgent – false
- patchSettings
- patchMode – ImageDefault
- assessmentMode – ImageDefault
- linuxConfiguration
- enableVMAgentPlatformUpdates – false
- allowExtensionOperations – false
- requireGuestProvisionSignal – false
Microsoft.Network/networkInterfaces
- enableAcceleratedNetworking – true
- enableIPForwarding – false
- disableTcpStateTracking – false
- nicType – Standard
Microsoft.Compute/disks
- networkAccessPolicy – AllowAll
- publicNetworkAccess – Enabled
- encryption
- type – EncryptionAtRestWithPlatformKey
Microsoft.Resources/deployments
- mode – Incremental
The following are also created with no specific properties besides the required fields. Therefore, you will only need to ensure that Azure policies permit their creation:
- Microsoft.Authorization/roleAssignments
- Microsoft.Network/virtualNetworks
- Microsoft.Network/virtualNetworks/subnets
- Microsoft.Network/networkSecurityGroups
Microsoft.Network/networkInterfaces
- enableAcceleratedNetworking – true
- enableIPForwarding – false
- disableTcpStateTracking – false
- nicType – Standard
Microsoft.Compute/disks
- networkAccessPolicy – AllowAll
- publicNetworkAccess – Enabled
- encryption
- type – EncryptionAtRestWithPlatformKey
Microsoft.Resources/deployments
- mode – Incremental
The following are also created with no specific properties besides the required fields. Therefore, you will only need to ensure that Azure policies permit their creation:
- Microsoft.Authorization/roleAssignments
- Microsoft.Network/virtualNetworks
- Microsoft.Network/virtualNetworks/subnets
- Microsoft.Network/networkSecurityGroups
Security: Silk Uses Challenge Handshake Authentication Protocol (CHAP)
Silk implements Challenge Handshake Authentication Protocol (CHAP) as a security measure to ensure the identity of a host initiator to a Silk Data Pod (SDP) target.
This CHAP security measure rejects any unauthorized host from accessing data to the authenticated host.