Zone resiliency and private

[robsissons-contino]

We have a requirement to meet some strict policies and would like to use Azure IPAM.

Deploying "out of the box" gives us a lot of non-compliance against several policies, such as:

• Resources should be zonally resilient:
  Cosmos & App Service Plan

• should use private link / have firewall rules / disable public network access
  Cosmos, App Service, Key Vault

• Saved-queries in Azure Monitor should be saved in customer storage account for logs encryption
  Log Analytics

• Key Vault secrets should have expiry date / content type / maximum validity
  KV Secrets

Some of the above we can fix retrospectively after deployment, some cannot (such as making an App Service Plan zonal).

Does anyone have a solution for this or is there a view to adding these features? I have seen some discussions saying that the private solution is being developed but nothing available yet.

Ideally we would still like to be able to access the IPAM solution externally so we would also need to look at deploying an application gateway to proxy the solution?

[DCMattyG]

Hi @robsissons-contino, here's my quick assessment of the points you provided above:

• I agree this would be something that must be addressed at deployment time, however, do you not have an exception process for specific applications where paying 3x doesn't make sense for the zonal redundancy? Just a question to see if there is such a process for your organization.
• All of these can be added post-deployment and the reason they are not part of the deployment script today is there are a plethora of different ways to implement these specific requirements that varies from organization to organization.
• Azure Monitor is not in the mix here. This solution does use Azure Resource Graph queries via API, but there isn't a way to log these as they hit the ARG service to my knowledge.
• None of these "secrets" used in this solution expire. For example, one of the items stored in KeyVault is your Tenant ID. I think you'd agree that there isn't an expiration on such a value so again this would likely warrant some kind of exception process as there can sensitive values stored in KeyVault that don't necessarily "expire".

Would you mind providing me some feedback on my assessment above, and they we can talk about next steps and what does/doesn't need to change with the deployment scripts?

Thanks so much!

[robsissons-contino]

Hi @DCMattyG

Thanks for the response, and apologies for delay in getting back to you.

I agree this would be something that must be addressed at deployment time, however, do you not have an exception process for specific applications where paying 3x doesn't make sense for the zonal redundancy? Just a question to see if there is such a process for your organization.

In our case, the IPAM solution will be central to our automation for provisioning of new virtual networks so if the service is unavailable then the whole provisioning service is down so for this reason we would require high availability offered by the additional zones. Appreciate this isn't the case for everyone!

All of these can be added post-deployment and the reason they are not part of the deployment script today is there are a plethora of different ways to implement these specific requirements that varies from organization to organization.

Appreciate this, and assumed this would be the case. Wondered if there is a way to have a second script available to "enable" private access or some documentation detailing the steps required for this?

Azure Monitor is not in the mix here. This solution does use Azure Resource Graph queries via API, but there isn't a way to log these as they hit the ARG service to my knowledge.

The policy which highlighted this comes from a NIST initiative which requires storage accounts for log analytics workspaces for any saved queries. In this case we will raise an exemption to waiver - no action required.

None of these "secrets" used in this solution expire. For example, one of the items stored in KeyVault is your Tenant ID. I think you'd agree that there isn't an expiration on such a value so again this would likely warrant some kind of exception process as there can sensitive values stored in KeyVault that don't necessarily "expire".

Agree - we need to raise exemptions here too.

Is there anything I can do to assist in documenting / scripting the private configuration or do you already have anything which can be used for this?

Thanks again

[DCMattyG]

Hi there @robsissons-contino, thanks for the responses!

I have intended on adding a section in the docs for quite some time now around different possible ways to enable private network communication between all of the components of the Azure IPAM platform. I will finally have some time as we approach the holidays where I can get this done properly with screenshots & details. I believe this will be the best approach as customers can see various examples and pick & choose the way that makes the most sense for their organization.

We always welcome contributions so if you have some thoughts as to how those docs should be organized or want to suggest some verbiage that makes sense, please don't hesitate. Otherwise I intend of accomplishing this over the month of December and will roll all of this into the next release (v3.6.0).