194 posts tagged with "Azure"

Are you running internal web-based applications that you want to give access to users working remotely securely without the need for a VPN or firewall? Do you want to enforce or use Azure Conditional Access policies to protect and manage access?

Let me introduce the Microsoft Microsoft Entra ID Application Proxy...

Application Proxy is a feature of Azure AD that enables users to access on-premises web applications from a remote client. Application Proxy includes both the Application Proxy service which runs in the cloud, and the Application Proxy connector, which runs on an on-premises server. Azure AD, the Application Proxy service, and the Application Proxy connector work together to securely pass the user sign-on token from Azure AD to the web application. Application Proxy also supports single sign-on.

Application Proxy is recommended for giving remote users access to internal resources. Application Proxy replaces the need for a VPN or reverse proxy.

Overview​

The Microsoft Entra ID Application Proxyhas been around for a few years, but appears to be a hidden gem; the Application Proxy allows users_(by using Microsoft Entra ID and an Application Proxy Connector(s))_ to connect to internally hosted web applications, by the connector relaying the traffic.

Application Proxy supports the following types of applications:

• Web applications
• Web APIs that you want to expose to rich applications on different devices
• Applications hosted behind a Remote Desktop Gateway
• Rich client apps that are integrated with the Microsoft Authentication Library (MSAL)

Azure Application Proxy can often be overlooked to solve your business requirements without the need to implement costly third-party firewalls (it also doesn't have to be an on-premises workload, for example, if the web application is running on a VM in Azure, it will also work).

The Azure Application proxy connector is a lightweight agent installed on a Windows Server machine that is logically close to the backend service that you want to deliver through the proxy.

The Connector gives access to and relays the information to the Application proxy service in Microsoft Azure via HTTP/HTTPS as long as it has access to the following:

Setup Azure Application Proxy​

I will set up an Azure Application Proxy to grant access to my Synology NAS (Network Attached Storage) device web page in this guide.

Although I am using my local NAS web administration page, it can be any webpage (Unifi Controller, hosted on Apache, IIS etc.) accessible from the connector.

• I have a Windows Server 2022 Domain Controller.
• Synology NAS (not domain joined, but accessible on the network via a DNS record from the domain)
• Microsoft 365 Developer subscription with appropriate licenses

Pre-requisites for Azure Application Proxy setup​

The following resources and rights will be needed to set up Azure Application Proxy:

• An Microsoft Entra ID tenant
• A minimum of Application Administrator rights is required to set up the Application and user and group assignments.
• A server running Windows Server 2012 R2 or above to install the Application Proxy connector on (and the permissions to install)
• If you are using a third-party domain (you will need a public SSL certificate) and, of course, the ability to edit external DNS records, the domain will need to be added to Microsoft Entra ID as a custom domain in order to be used.
• Microsoft Entra ID Premium P1 license or M365 Business Premium/E3 license for each user using Microsoft Entra ID Application Proxy.

(Note: Normal Azure AD service limits and restrictions apply).

I will be configuring the Azure Application Proxy on a domain controller running Windows Server 2022.

Disable IE Enhanced Security Configuration​

The Azure Application Proxy connector requires you to log in to Microsoft Azure, and I will be installing this on a Windows Server 2022 domain controller; if this Enhanced Security Configuration is enabled (as it should be), you will have problems authenticating to Microsoft Azure, so the easiest thing is to turn it off temporarily.

1. Open Server Manager
2. Click on Local Server
3. Click on: IE Enhanced Security Configuration
4. Select Off for: Administrators
5. Close Microsoft Edge (if you have it opened)
6. 

Install Azure Application Proxy Connector​

1. Login to Azure Portal (on the server that you want to install the Connector on)
2. Navigate to: Microsoft Entra ID
3. Select Application Proxy
4. 
5. Click on: Download connector service.
6. Accept the system requirements and click Accept Terms & Download
7. A file named: 'AADApplicationProxyConnectorInstaller.exe' should have been downloaded. Run it.
8. Select: I agree to the license terms and conditions and select Install
9. 
10. Wait for the Microsoft Microsoft Entra ID Application to display and log in with an Microsoft Entra ID account with Application Administrator rights.
11. The Microsoft Microsoft Entra ID Application Connector will now be registered in your Microsoft Entra ID tenancy.
12. 
13. Click Close
14. Now re-enable IE enhanced security configuration.

You should now see two new services appear in services as Automatic (Delayed Start):

• WAPCsvc - Microsoft AAD Application Proxy Connector
• WAPCUpdaterSvc - Microsoft AAD Application Proxy Connector Updater

And the following processes running:

• ApplicationProxyConnectorService
• ApplicationProxyConnectorUpdateService

If you are running Server Core, Microsoft Microsoft Entra ID Application Proxy can be installed via PowerShell.

The Azure Application Proxy Connector agent gets updated automatically when a new major version is released by Microsoft.

Configure Connector Group​

Now that you have created the Connector, the Application Proxy has put our Connector in a group that has defaulted to Asia; because you can have more than one Application Proxy Connector for redundancy and different applications, we will create a new Connector Group that is set to use the Australia region if Asia works for you – feel free to skip this step.

1. Login to Azure Portal (on any PC/server)
2. Navigate to: Microsoft Entra ID
3. Select Application Proxy
4. You should now see: Default and your Region
5. If you expand the Default Group, will you see your Connector:
6. 
7. Click on + New Connector Group
8. Give it a name (i.e., On-premises)
9. Select the Connector you had earlier and select the region closest to you (currently, the following regions can be chosen: Asia, Australia, Europe, North America)
10. 
11. Click + Create
12. Clicking create will create your new On-premises connector group and add the Connector to the group.

Configure your Azure Application Proxy Application​

Now that you have your Connector setup, its time to set up your application

1. Login to Azure Portal (on any PC/server)
2. Navigate to: Microsoft Entra ID
3. Select Application Proxy
4. Click on: + Configure an app
5. Fill in the details that match your application:

• Name: This is the application that users will see (i.e. I am going with Pizza, which is the name of my NAS)
• Internal URL: This is the internal URL used to access your application inside the network (in my example, it is: http://pizza.corp.contoso.com/)
• External Url: This is the external URL that will be created so that users can access the application form; I will go with Pizza. Note this URL down.
• Pre-Authentication: You don't have to authenticate with Azure AD, you can use passthrough, but it is not something I would recommend without delving into requirements, testing – I am going to select: Microsoft Entra ID.
• Connector Group: Select the connector group you created earlier or that your Connector is signed to.
• Leave all Additional Settings as default – they can be changed later if you need to.
  1. 
  2. Verify that everything is filled out correctly and, click + Add
  3. Azure Application Proxy has now created a new Enterprise Application for you; based on the name mentioned earlier, if you navigate to the external URL mentioned earlier, you should get a prompt similar to below:
  4. 
  5. It is now time to assign the permissions for users to access the Application via Microsoft Entra ID!

Assign rights to your Azure Application Proxy Application​

1. Login to Azure Portal (on any PC/server)
2. Navigate to: Microsoft Entra ID
3. Select Enterprise Applications
4. Find the application that was created earlier by the Azure Application Proxy service.
5. 
6. Click on the Application
7. Click on: Users and Groups
8. Click Add Assignment
9. Add a user or group (preferred) you want to have access to this application.
10. Click Assigned
11. 
12. Click on Application Proxy
13. Here you can see and edit the information you created earlier when you created the application, copy the External URL
14. Open Microsoft Edge (or another browser of your choice)
15. Paste in the External URL
16. Log in with the Microsoft Entra ID account that was assigned to the Enterprise application.
17. You should now have access to your on-premises web application from anywhere in the world, and because you are using Microsoft Entra ID, your conditional access policies and restrictions will be in effect:
18. 

Note: Because the Synology web interface was running on port: 5000, I had to go back and add the port to the internal URL, as the Application Proxy was attempting to route to the incorrect port. Note: You may also notice that Microsoft has supplied an *.msappproxy.net certificate, even if your backend service doesn't have one..

Setup Password-based Single-Sign on​

Azure Application Proxy supports various single sign-on methods, including Kerberos SPN integration.

However, my Synology NAS uses standalone accounts, so I will set Password-based single sign-on, allowing the MyApps extension to store my credentials (if you want single-sign-on using the password-based sign in, then every user will need to have this extension configured).

1. Download and install the MyApps Secure Sign-in extension
2. Log in using your Microsoft account to the MyApps extension
3. 
4. Login to Azure Portal (on any PC/server)
5. Navigate to: Microsoft Entra ID
6. Select Enterprise Applications
7. Find the application that was created earlier by the Azure Application Proxy service.
8. Click on Single sign-on
9. Select Password-based
10. 
11. Type in the URL of the authentication webpage and click Save
12. 
13. The Azure AD Application Proxy didn't find my sign-in login and password fields, so I have to manually configure them, select: Configure Pizza Password Single Sign-on Settings.
14. Select: Manually detect sign-in fields
15. Select Capture sign-in fields
16. 
17. Your MS Edge Extension should show Capture Field:
18. 
19. Enter in your username
20. Press Enter
21. Enter in your password
22. Select the MS Apps extension and select Save
23. Navigate back to the Azure Portal
24. Select 'I was able to sign in.'
25. If successful, Azure AD should now have mapped the fields:
26. 
27. Click Save
28. Next time you log in to the application, the My Apps Secure Sign-in Extension will have cached the credentials. It should automatically log you into the application, meaning you should only log in once with your Azure AD credentials.

Access your Azure Application Proxy published application​

1. You can now go to My Apps (microsoft.com), and you will see your application.
2. 
3. Your application will also appear in the Microsoft 365 Waffle (it may take up to an hour to appear):
4. 

I recommend you go into the Enterprise Application and upload a better image/logo so your users can quickly tell it apart.

Azure Bicep is a Domain Specific Language (DSL) for deploying Azure resources declaratively. Azure Bicep is a transparent abstraction over ARM and ARM templates, which means anything that can be done in an ARM Template can be done in Bicep.

Azure Bicep has recently (December 2021) been updated to: v0.4.1124, along with various other hotfixes and enhancements; this version supports 'Insert Resource' functionality.

Insert Resource simplifies ARM to Bicep conversion without exporting entire ARM templates, then compiles them to Bicep when you are only after export for a single resource.

To use Insert Resource, you will need to have:

• Bicep version greater than v0.4.1124
• Azure CLI
• Visual Studio Code with the Bicep extension

You can easily install both or upgrade following the Microsoft documentation on the: Install Bicep tools page. You can also review the Bicep changes and latest release notes on Github here: Azure Bicep releases

Import Resources into Bicep using Azure CLI and Bicep​

1. Open a new file in Visual Studio Code
2. Set the Language mode to Bicep
3. 
4. Now we need to login to Azure; in Visual Studio code, click View and Terminal.
5. In the terminal, type in: az login
6. Login to Azure using the credentials that have read access to the Resource you want to export.
7. Once you are logged in, type in: az resource list
8. In the JSON output in the terminal, copy the resource ID (inside the double quotes from the id value)
9. Now we need to open the Command Palette, press: CTRL+Shift+P on your keyboard (or click on View, Command Palette)
10. Start typing in Bicep; if you have the latest version, you should see: Bicep: Insert Resource., select this
11. 
12. Enter in the resource ID you copied earlier.
13. 
14. Azure Bicep should have connected and exported your Resource straight into Bicep! As below, it had imported a Log Analytics workspace in my subscription straight into Bicep.
15. 

To find the resource ID using the Azure Portal.​

You can use the Azure CLI to find the Resource ID, but you can also use the Azure Portal by navigating to it below:

1. Log in to the Azure Portal
2. Navigate to the Resource you want to export to Bicep
3. On the Overview pane, click on JSON view

I had problems connecting to export an App Service and App Service plan, so for some resources with multiple dependencies, you may be better off exporting the ARM template from the resources/resource groups and decompiling that way, but the Insert Resource functionality is a very quick way to bring your resources into Bicep!

As part of standing up and using an Azure Storage account as an SFTP service, I ran into a few issues. This blog post is merely intended to show my findings in case others run into similar issues.

PTY allocation request failed on channel 0​

Even though you appear to have connected successfully, you may see the following errors:

• PTY allocation request failed on channel 0
• shell request failed on channel 0

You may laugh, but the solution for this was very simple, switch from SSH to SFTP!

If you were like me, I just flicked to SSH as a habit.

Home Directory is not accessible​

Make sure that the Home directory (Folder) is created in your container, SFTP won't create this for you.

Also make sure that the Home directory for the user, references Container/Folder, like the below:

Wrong username, authentication failed​

When attempting to connect to SFTP using a tool such as WinSCP, I got:

• Using username "lukeftpuser".
• Authentication failed.

The username is actually comprised of:

STORAGEACCOUNTNAME+FTPNAME, ie: sftpstorageacc1337.lukeftpuser

Unable to find Azure Storage SSH Keys​

This is not an error, but Azure Keyvault, does not currently support SSH keypairs, so once they are created by Azure, they are stored in a Microsoft.Compute.sshPublicKeys resource found here: SSH Keys

SSH File Transfer Protocol (SFTP) support is now supported in Preview for Azure Blob Storage accounts with hierarchical namespace enabled.

Although tools such as Storage Explorer, Data Factory, AzCopy allows a copy to and from Azure storage accounts, sometimes your applications need more traditional integration, so SFTP is a welcome addition to the Microsoft Azure ecosystem, which in some cases removes the need for additional Virtual Machine(s).

This support enables standard SFTP connectivity to an Azure Storage account. As an Azure PaaS (Platform as a Service) resource, it offers additional flexibility, reduces operational overhead, and increases redundancy and scalability.

We will run through the initial setup of the Azure Storage account using the Azure Portal.

SFTP using an Azure Storage account does not support shared access signature (SAS) or Microsoft Entra ID (Azure AD) authentication for connecting SFTP clients. Instead, SFTP clients must use a password or a Secure Shell (SSH) private/public keypair.

Before we head into the implementation, just a bit of housekeeping, this is currently still in Preview at the time this post was written; the functionality MAY change by the time it becomes GA (Generally Available).

During the public preview, the use of SFTP does not incur any additional charges. However, the standard transaction, storage, and networking prices for the underlying Azure Data Lake Store Gen2 account still apply. SFTP might incur additional charges when the feature becomes generally available. As of the time of the preview SFTP support is only avaliable in certain regions.

You can connect to the SFTP storage account by using local (to the SFTP storage account) SSH public-private keypair or Password (or both). You can also set up individual HOME directories (because of the hierarchical namespace, these are folders not containers) for each user (maximum 1000 local user accounts).

Creating an Azure Storage account for SFTP​

This article assumes you have an Azure subscription and rights to create a new Storage account resource, however if you have an already existing storage account the following pre-requisites are required:

• A standard general-purpose v2 or premium block blob storage account. You can also enable SFTP as you create the account.
• The account redundancy option of the storage account is set to either locally-redundant storage (LRS) or zone-redundant storage (ZRS); GRS is not supported.
• The hierarchical namespace feature of the account must be enabled for existing storage accounts. To enable the hierarchical namespace feature, see Upgrade Azure Blob Storage with Azure Data Lake Storage Gen2 capabilities.
• If you're connecting from an on-premises network, make sure that your client allows outgoing communication through port 22. The SFTP uses that port.

Fill out the SFTP Public Preview Interest Form​

Because the SFTP functionality is currently in Private Preview, Microsoft has asked that anyone interested in the SFTP Preview fill out a Microsoft Forms:

• SFTP Public Preview Interest Form

This MAY be required before proceeding to the following steps; initially, I believe this was required - but there appears to have been a few people who I know have registered the feature without the form - either way, the SFTP Public Preview Interest form, is a good opportunity to supply your use-case information to Microsoft directly, to help improve the nature of the service going forward.

Registering the Feature​

To create an Azure Storage account that supports SFTP - we need to enable the Preview Feature.

1. Log in to the Azure Portal

2. Navigate to: Subscriptions

3. Select the Subscription that you want to enable SFTP preview for

4. Click on: Preview features

5. Search for: SFTP

6. Click on: SFTP support for Azure Blob Storage and click Register - this may take from minutes to a few days to be registered, as each preview request may need to be manually approved by Microsoft personnel based on the Public Preview Interest form - my feature registration occurred quite quickly, so there is a chance that they either have automated the approvals or I was just lucky.

   As you can see in the screenshot below, I had already registered mine:

7. 

8. You can continue to hit refresh until it changes from: Registering to Registered.

9. While we are here, let's check that the Microsoft.Storage resource provider is registered (it should already be enabled, but it is a good opportunity to check before attempting to create a resource and get a surprise), by clicking on Resource providers in the left-hand side menu and search for: Storage, if it is set to NotRegistered - click on Microsoft.Storage and click Register.

To register the SFTP feature using PowerShell, you can run the following cmdlet:

Register-AzProviderFeature -FeatureName "AllowSFTP" -ProviderNamespace "Microsoft.Storage"

Create the Azure Storage Account​

Now that the Preview feature has been registered, we can now create a new Storage account.

1. Log in to the Azure Portal
2. Click on +Create a resource
3. Type in: Storage account and click on the Microsoft Storage account resource and click Create
4. 
5. Select your Subscription you enabled the SFTP feature in earlier
6. Select your Resource Group (or create a new resource group) to place your storage account into.
7. Select your storage account name (this needs to be globally unique and a maximum of 24 characters), in my example; I am going with: sftpstorageacc1337
8. Select your Region; remember that only specific regions currently have SFTP support at the time of this article _.
9. Select your performance tier; premium is supported but remember to select Blob, select Standard.
10. Select your Redundancy; remember that GRS-R, GRS isn't supported at this time; I will select Zone-redundant storage (ZRS) so that my storage account is replicated between the three availability zones, but you can also select LRS (Locally Redundant Storage).
11. 
12. Click Next: Advanced
13. Leave the Security options as-is and check: Enable hierarchical namespace under the Data Lake Storage Gen2 subheading.
14. Click Enable SFTP
15. 
16. Click: Next: Networking
17. SFTP supports Private Endpoints (as a blob storage sub-resource), but in this case, I will be keeping Connectivity as a Public endpoint (all networks)
18. 
19. Click Next: Data Protection
20. Here you can enable soft-delete for your blobs and containers, so if a file is deleted, it is retained for seven days until it's permanently deleted; I am going to leave mine set as the default of 7 days and click: Next: Tags.
21. Add in any applicable Tags, i.e. who created it, when you created it, what you created it for and click Review + Create
22. Review your configuration, make sure that Enable SFTP is enabled with Hierarchical namespace and click Create.

In case you are interested in Infrastructure as Code, here is an Azure Bicep file I created to create a storage account ready for SFTP here that can be deployed to a Resource Group, ready for the next steps:

param storageaccprefix string = ''
var location = resourceGroup().location

resource storageacc 'Microsoft.Storage/storageAccounts@2021-06-01' = {
  name: '${storageaccprefix}${uniqueString(resourceGroup().id)}'
  location: location
  sku: {
    name: 'Standard_ZRS'
  }
  kind: 'StorageV2'
  properties: {
    defaultToOAuthAuthentication: false
    allowCrossTenantReplication: false
    minimumTlsVersion: 'TLS1_2'
    allowBlobPublicAccess: true
    allowSharedKeyAccess: true
    isHnsEnabled: true
    supportsHttpsTrafficOnly: true
    encryption: {
      services: {
  
        blob: {
          keyType: 'Account'
          enabled: true
        }
      }
      keySource: 'Microsoft.Storage'
    }
    accessTier: 'Hot'
  }
}

Setup SFTP​

Now that you have a compatible Azure storage account, it is time to enable SFTP!

1. Log in to the Azure Portal
2. Navigate to the Storage account you have created for SFTP and click on it
3. On the Storage account blade, under Settings, you will see: SFTP
4. 
5. Click on SFTP and click + Add local user.
6. Type in the username of the user you would like to use (remember you can have up to 1000 local users, but there is no integration into Azure AD, Active Directory or other authentication services currently), in my example I will use: lukeftpuser
7. You can use either (and both) SSH keys or passwords, in this article - I am simply going to use a password so I select: SSH Password.
8. Click Next
9. Our storage account is empty, we now need to create a top-level container, so I will sect Create new and set the name to: ftp
10. I will leave the Public access level to Private (no anonymous access)
11. Click Ok
12. Now that the ftp container has been created, we need to set the permissions, I am simply going to give the permissions of Read, Create, Delete, List and Write. It's worth noting, that if you only need to read or list contents, then that is the only permissions you need, these permissions are for the Container, not the folder, so you may find your users may have permissions to other folders in the same Container if not managed appropriately.
13. Now we set the Home directory. This is the directory that the user will be automatically mapped to, this is optional but if you don't have a Home directory filled in for the user, they will need to connect to the appropriate folders when connecting to SFTP manually. The home directory needs to be relative, ie: ftp/files (the container name and the files folder, located in the ftp container).
14. 
15. Because we specified Password earlier, Azure has automatically created a new password for that account, although you can generate new passwords - you are unable to specify what the Password is, make sure you copy this and store it in a password vault of some kind, the length of the password that was generated for me was: 89 characters.
16. 
17. You should see the connection string of the user, along with the Authentication method and container permissions.
18. 

Test Connectivity via SFTP to an Azure Storage Account​

I will test Connectivity to the SFTP Azure Storage account using Windows 11, although the same concepts apply across various operating systems (Linux, OSX, etc.).

Test using SFTP from Windows using command prompt​

1. Make sure you have a copy of the Connection String and user password from the SFTP user account created earlier.

2. Open Command Prompt

3. Type in sftp CONNECTIONSTRING, example below and press Enter:

   • sftp sftpstorageacc1337.lukeftpuser@sftpstorageacc1337.blob.core.windows.net

4. If you get a prompt to verify the authenticity of the host matches (i.e. the name/URL of the storage account matches) and type in: Yes, to add the storage account to your known host's list

5. Press Enter and paste in the copy of the Password that was generated for you earlier.

6. You should be connected to the Azure Storage account via SFTP!

7. As you can see below, I am in the Files folder, which is my users home folder, and there is a file named: Test in it.

8. 

   Once you have connected to SFTP using the Windows command line you can type in: ?

   That will give you a list of all the available commands to run, ie upload files etc

Test using WinSCP​

1. Make sure you have a copy of the Connection String and user password from the SFTP user account created earlier.
2. If you haven't already, download WinSCP and install it
3. You should be greeted by the Login page (but if you aren't, click on Session, New Session)
4. For the hostname, type in the URL for the storage account (after the @ in the connection string)
5. For the username, type in everything before the @
6. Type in your Password
7. Verify that the port is 22 and file protocol is SFTP and click Login
8. 
9. 

Congratulations! You have now created and tested Connectivity to the Azure Storage SFTP service!

Allowing and restricting Azure resources by being accessible by specific Public IP (Internet Protocol) addresses has been around for years; most Azure resources support it, a Storage account is no different.

In this article, I will be using PowerShell to obtain my current public IP, then parse that variable into my Azure Bicep deployment to create a storage account, with the firewall rule allowing ONLY my public IP address.

I will assume that you have both Azure Bicep and PowerShell Azure modules installed and the know-how to connect to Microsoft Azure.

Utilising PowerShell to create dynamic variables in your deployment can open the doors to more flexible deployments, such as including the name of the person deploying the infrastructure into the tags of the resource - or in this case, adding a whitelisted IP automatically to your Azure resource to be secure by default.

I will be using PowerShell splatting as it's easier to edit and display. You can easily take the scripts here to make them your own.

Azure Bicep deployments (like ARM) have the following command: 'TemplateParameterObject'. 'TemplateParameterObject' allows Azure Bicep to accept parameters from PowerShell directly, which can be pretty powerful when used with a self-service portal or pipeline.

Now we are ready to create the Azure Storage account...

I will first make an Azure Resource Group using PowerShell for my storage account first, then use the New-AzResourceGroupDeployment cmdlet to deploy my storage account from my bicep file.

#Connects to Azure
Connect-AzAccount
#Grabs the Public IP of the currently connected PC and adds it into a variable.
$publicip = (Invoke-WebRequest -uri "http://ifconfig.me/ip").Content
#Resource Group Name
$resourcegrpname = 'storage_rg'
#Creates a resource group for the storage account
New-AzResourceGroup -Name $resourcegrpname -Location "AustraliaEast"
# Parameters splat, for Azure Bicep
# Parameter options for the Azure Bicep Template, this is where your Azure Bicep parameters go
$paramObject = @{
  'storageaccprefix' = 'stg'
  'whitelistpublicip'  = $publicip
}
# Parameters for the New-AzResourceGroupDeployment cmdlet goes into.
$parameters = @{
  'Name'                  = 'StorageAccountDeployBase'
  'ResourceGroupName'     = $resourcegrpname 
  'TemplateFile'          = 'c:\temp\storageaccount.bicep'
  'TemplateParameterObject'    = $paramObject
  'Verbose'               = $true
}
#Deploys the Azure Bicep template
New-AzResourceGroupDeployment @parameters

As you can see above, I am grabbing my current IP Address from the ifconfig website and storing it in a variable (as a string object), then referencing it in the paramObject - which will be passed through to the TemplateParameterObject command as Parameters strings for Azure Bicep, my IP address (I am running this from an Azure VM) is then passed through, to Azure Bicep.

My Azure Bicep is below:

param storageaccprefix string = ''
param whitelistpublicip string = ''
var location = resourceGroup().location

resource storageaccount 'Microsoft.Storage/storageAccounts@2021-06-01' = {
  name: '${storageaccprefix}${uniqueString(resourceGroup().id)}'
  location: location
  sku: {
    name: 'Standard_ZRS'
  }
  kind: 'StorageV2'
  properties: {
    defaultToOAuthAuthentication: false
    allowCrossTenantReplication: false
    minimumTlsVersion: 'TLS1_2'
    allowBlobPublicAccess: true
    allowSharedKeyAccess: true
    isHnsEnabled: true
    networkAcls: {
      resourceAccessRules: []
      bypass: 'AzureServices'
      virtualNetworkRules: []
      ipRules: [
        {
          value: whitelistpublicip
          action: 'Allow'
        }
      ]
      defaultAction: 'Deny'
    }
    supportsHttpsTrafficOnly: true
    encryption: {
      services: {
  
        blob: {
          keyType: 'Account'
          enabled: true
        }
      }
      keySource: 'Microsoft.Storage'
    }
    accessTier: 'Hot'
  }
}

In Azure Bicep - I am accepting the whitelistpublicip variable from PowerShell and have passed that along to the virtualNetworkRules object as an Allow, while the defaultAction is 'Deny'.

If I navigate to the Azure Portal, I can see my newly created storage account; under the Networking blade, I can see that the Firewall has been enabled and my Public IP has been added successfully:

Hopefully, this helps you be more secure from deployment time and gives you a good framework to work on; in the future, the same process can be used to create inbound RDP rules for Virtual Machines, as an example.