service bus role assignment bicep

This browser is no longer supported.

Upgrade to Microsoft Edge to take advantage of the latest features, security updates, and technical support.

Create Azure RBAC resources by using Bicep

• 4 contributors

Azure has a powerful role-based access control (RBAC) system. For more information on Azure RBAC, see What is Azure Role-based access control (Azure RBAC)? By using Bicep, you can programmatically define your RBAC role assignments and role definitions.

Role assignments

Role assignments enable you to grant a principal (such as a user, a group, or a service principal) access to a specific Azure resource.

To define a role assignment, create a resource with type Microsoft.Authorization/roleAssignments . A role definition has multiple properties, including a scope, a name, a role definition ID, a principal ID, and a principal type.

Role assignments apply at a specific scope , which defines the resource or set of resources that you're granting access to. For more information, see Understand scope for Azure RBAC .

Role assignments are extension resources , which means they apply to another resource. The following example shows how to create a storage account and a role assignment scoped to that storage account:

If you don't explicitly specify the scope, Bicep uses the file's targetScope . In the following example, no scope property is specified, so the role assignment is scoped to the subscription:

Use the smallest scope that you need to meet your requirements.

For example, if you need to grant a managed identity access to a single storage account, it's good security practice to create the role assignment at the scope of the storage account, not at the resource group or subscription scope.

A role assignment's resource name must be a globally unique identifier (GUID).

Role assignment resource names must be unique within the Microsoft Entra tenant, even if the scope is narrower.

For your Bicep deployment to be repeatable, it's important for the name to be deterministic - in other words, to use the same name every time you deploy. It's a good practice to create a GUID that uses the scope, principal ID, and role ID together. It's a good idea to use the guid() function to help you to create a deterministic GUID for your role assignment names, like in this example:

Role definition ID

The role you assign can be a built-in role definition or a custom role definition . To use a built-in role definition, find the appropriate role definition ID . For example, the Contributor role has a role definition ID of b24988ac-6180-42a0-ab88-20f7382dd24c .

When you create the role assignment resource, you need to specify a fully qualified resource ID. Built-in role definition IDs are subscription-scoped resources. It's a good practice to use an existing resource to refer to the built-in role, and to access its fully qualified resource ID by using the .id property:

The principalId property must be set to a GUID that represents the Microsoft Entra identifier for the principal. In Microsoft Entra ID, this is sometimes referred to as the object ID .

The principalType property specifies whether the principal is a user, a group, or a service principal. Managed identities are a form of service principal.

It's important to set the principalType property when you create a role assignment in Bicep. Otherwise, you might get intermittent deployment errors, especially when you work with service principals and managed identities.

The following example shows how to create a user-assigned managed identity and a role assignment:

Resource deletion behavior

When you delete a user, group, service principal, or managed identity from Microsoft Entra ID, it's a good practice to delete any role assignments. They aren't deleted automatically.

Any role assignments that refer to a deleted principal ID become invalid. If you try to reuse a role assignment's name for another role assignment, the deployment will fail. To work around this behavior, you should either remove the old role assignment before you recreate it, or ensure that you use a unique name when you deploy a new role assignment. This quickstart template illustrates how you can define a role assignment in a Bicep module and use a principal ID as a seed value for the role assignment name.

Custom role definitions

Custom role definitions enable you to define a set of permissions that can then be assigned to a principal by using a role assignment. For more information on role definitions, see Understand Azure role definitions .

To create a custom role definition, define a resource of type Microsoft.Authorization/roleDefinitions . See the Create a new role def via a subscription level deployment quickstart for an example.

Role definition resource names must be unique within the Microsoft Entra tenant, even if the assignable scopes are narrower.

Some services manage their own role definitions and assignments. For example, Azure Cosmos DB maintains its own Microsoft.DocumentDB/databaseAccounts/sqlRoleAssignments and Microsoft.DocumentDB/databaseAccounts/sqlRoleDefinitions resources. For more information, see the specific service's documentation.

Related resources

• Microsoft.Authorization/roleAssignments
• Microsoft.Authorization/roleDefinitions
• Extension resources
• Resource group
• Subscription
• Management group
• Create a new role def via a subscription level deployment
• Assign a role at subscription scope
• Assign a role at tenant scope
• Create a resourceGroup, apply a lock and RBAC
• Create key vault, managed identity, and role assignment
• Create role assignments for different scopes with Bicep , by Barbara Forbes

Coming soon: Throughout 2024 we will be phasing out GitHub Issues as the feedback mechanism for content and replacing it with a new feedback system. For more information see: https://aka.ms/ContentUserFeedback .

Submit and view feedback for

Additional resources

medienstudio.net

Azure Service Bus with Bicep & Managed Identity in ASP.NET Core

Azure Service Bus can be used by clients with two different authentication mechanisms – either through Shared access policies with Manage , Send and Listen capabilities or through the Role-based access control (RBAC) . The latter one is recommended as it also allows you to make use of Managed Identites instead of relying on connection strings. In this post we’ll take a look at how this can be set up using Bicep and connected to an ASP.NET Core app.

Btw. you can run both mechanisms in parallel for example if you need to connect a client that does not support Managed Identities.

First we create our service bus and output its name for later reference.

Next we create a reusable module to assign Service Bus roles to Managed Identites e.g. for WebApps or Functions. There are three different roles available: Reader, Sender and Owner. Each have their own global role Id that we need to use depending on the permissions we want to set.

Lastly we call the role assignment modules with the apps Principal Id, Service Bus name and desired role name. In this example we have a function app that listens to queue messages and a web app that can send them.

Leave a Reply Cancel reply

This site uses Akismet to reduce spam. Learn how your comment data is processed .

Like often, some automation can make your life just easier!  I hope you’ve enjoyed this one!

UPCOMING TRAININGS

CHECK OUT OUR TRAININGS

Azure Integration Services

Azure migration.

• Azure Governance

Azure Security

Azure foundations, recent posts.

• Azure Service Bus vs Event Grid Pull Delivery
• Trying the new Microsoft Applied Skills
• Finally a correct way to configure RBAC for DevOps agents!
• What do the new API Management v2 tiers mean for you?
• Validate payloads in Azure API Management
• Announcement
• API Management
• Architecture
• Azure App Service
• Azure Data Factory
• Azure DevOps
• Azure Event Grid
• Azure Functions
• Azure Kubernetes Service
• Azure Policy
• Azure Resource Graph
• Azure Resource Manager
• Azure Service Bus
• Azure Stream Analytics
• BizTalk Server
• Container Apps
• Geen categorie
• Home Automation
• Microsoft Learn
• Service Bus

MEET THE YOUR AZURE COACH TEAM

Your Azure Coach is specialized in organizing Azure trainings that are infused with real-life experience. All our coaches are active consultants, who are very passionate and who love to share their Azure expertise with you.

Toon Vanhoutte

Azure integration services & serverless.

Wim Matthyssen

Azure infra, security & governance, azure development and ai/ml, azure identity and security, stéphane eyskens, cloud-native azure architecture, geert baeke, azure kubernetes service & containerization, maik van der gaag, azure infrastructure as code & devops, bart verboven, sammy deprez, azure ai, ml & cognitive services, sander van de velde.

Permissioning Azure Pipelines with Bicep and Azure RBAC Role Assignments

How can we deploy resources to Azure, and then run an integration test through them in the context of an Azure Pipeline? This post will show how to do this by permissioning our Azure Pipeline to access these resources using Azure RBAC role assignments. It will also demonstrate a dotnet test that runs in the context of the pipeline and makes use of those role assignments.

We're following this approach as an alternative to exporting connection strings , as these can be viewed in the Azure Portal; which may be an security issue if you have many people who are able to access the portal and view deployment outputs.

We're going to demonstrate this approach using Event Hubs. It's worth calling out that this is a generally useful approach which can be applied to any Azure resources that support Azure RBAC Role Assignments. So wherever in this post you read "Event Hubs", imagine substituting other Azure resources you're working with.

The post will do the following:

• Add Event Hubs to our Azure subscription
• Permission our service connection / service principal
• Deploy to Azure with Bicep
• Write an integration test
• Write a pipeline to bring it all together

Add Event Hubs to your subscription ​

First of all, we may need to add Event Hubs to our Azure subscription.

Without this in place, we may encounter errors of the type:

##[error]MissingSubscriptionRegistration: The subscription is not registered to use namespace 'Microsoft.EventHub'. See https://aka.ms/rps-not-found for how to register subscriptions.

We do this by going to "Resource Providers" in the Azure Portal and registering the resources you need. Lots are registered by default, but not all.

Permission our service connection / service principal ​

In order that we can run pipelines related to Azure, we mostly need to have an Azure Resource Manager service connection set up in Azure DevOps. Once that exists, we also need to give it a role assignment to allow it to create role assignments of its own when pipelines are running.

##[error]The template deployment failed with error: 'Authorization failed for template resource {GUID-THE-FIRST} of type Microsoft.Authorization/roleAssignments . The client {GUID-THE-SECOND} with object id {GUID-THE-SECOND} does not have permission to perform action Microsoft.Authorization/roleAssignments/write at scope /subscriptions/\*\*\*/resourceGroups/johnnyreilly/providers/Microsoft.EventHub/namespaces/evhns-demo/providers/Microsoft.Authorization/roleAssignments/{GUID-THE-FIRST} .'.

Essentially, we want to be able to run pipelines that say "hey Azure, we want to give permissions to our service connection". We are doing this with the self same service connection, so (chicken and egg) we first need to give it permission to give those commands in future. This is a little confusing; but let's role with it. (Pun most definitely intended. 😉)

To grant that permission / add that role assignment, we go to the service connection in Azure Devops:

We can see there's two links here; first we'll click on "Manage Service Principal", which will take us to the service principal in the Azure Portal:

Take note of the display name of the service principal; we'll need that as we click on the "Manage service connection roles" link, which will take us to the resource groups IAM page in the Azure Portal:

Here we can click on "Add role assignment", select "Owner":

Then when selecting members we should be able to look up the service principal to assign it:

We now have a service connection which we should be able to use for granting permissions / role assignments, which is what we need.

Event Hub and Role Assignment with Bicep ​

Next we want a Bicep file that will, when run, provision an Event Hub and a role assignment which will allow our Azure Pipeline (via its service connection) to interact with it.

Do note that our bicep template takes the service principal id as a parameter. We're going to supply this later from our Azure Pipeline.

We're now going to write a dotnet integration test which will make use of the infrastructure deployed by our Bicep template. Let's create a new test project:

We'll create a test file called EventHubTest.cs with these contents:

Let's talk through what happens in the test above:

• We read in Event Hub connection configuration for the test from environment variables. (These will be supplied by an Azure Pipeline that we will create shortly.)
• We post a message to the Event Hub.
• We read a message back from the Event Hub.
• We confirm that the message we read back matches the one we posted.

Now that we have our test, we want to be able to execute it. For that we need an Azure Pipeline!

Azure Pipeline ​

We're going to add an azure-pipelines.yml file which Azure DevOps can use to power a pipeline:

When the pipeline is run, it does the following:

• Gets the service principal id from the service connection.
• Compiles our Bicep into an ARM template
• Deploys the compiled ARM template to Azure
• Installs the dotnet SDK
• Uses the Azure CLI task which allows us to access service principal details in the pipeline to run our dotnet test.

We'll create a pipeline in Azure DevOps pointing to this file, and we'll also create the variables that it depends upon:

• azureResourceGroup - the name of your resource group in Azure where the app will be deployed
• location - where your app is deployed, eg northeurope
• serviceConnection - the name of your AzureRM service connection in Azure DevOps
• subscriptionId - your Azure subscription id from the Azure Portal
• tenantId - the Azure tenant id from the Azure Portal

Running the pipeline ​

Now we're ready to run our pipeline:

Here we can see that the pipeline runs and the test passes. That means we've successfully provisioned the Event Hub and permissioned our pipeline to be able to access it using Azure RBAC role assignments. We then wrote a test which used the pipeline credentials to interact with the Event Hub. To see the repo that demostrates this, look here .

Just to reiterate: we've demonstrated this approach using Event Hubs. This is a generally useful approach which can be applied to any Azure resources that support Azure RBAC Role Assignments.

Thanks to Jamie McCrindle for helping out with permissioning the service connection / service principal. His post on rotating AZURE_CREDENTIALS in GitHub with Terraform provides useful background for those who would like to do similar permissioning using Terraform.

• Add Event Hubs to your subscription
• Event Hub and Role Assignment with Bicep
• Azure Pipeline
• Running the pipeline

Easy way to set Azure RBAC roles in Bicep

When deploying resources in Azure using Bicep, occasionally you will have to assign rights to a user or principal to perform certain actions. For example, authorizing an app service to access a storage account.

Initially you would create something like this:

I came up with the following Bicep module which shows a nice way to hide the nasty details such as the role guids in a module.

This makes the Bicep files a lot more readable, especially when you have to assign roles more often.

Creating a module to do this also has the advantage that you can change the scope, for example when the storage account is part of a different resource group.

Cleaned up initial example:

I hope someone has some use for this as well.

Update 18-07-2023: Updated to include principalType in template.

Navigation Menu

Search code, repositories, users, issues, pull requests..., provide feedback.

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly.

To see all available qualifiers, see our documentation .

• Notifications

Assigning RBAC via Role Assignment Module #5678

JFolberth Jan 19, 2022

Beta Was this translation helpful? Give feedback.

So I ended up taking thoughts from a few folks and leveraged modules to handle nesting each loops. Did this as wanted the parameter file to be simpler for maintenance/scalability. This as of now is only for the subscription.

parameters.json:

Replies: 4 comments · 17 replies

Slapointe jan 19, 2022.

JFolberth Jan 20, 2022 Author

bansioza44 Mar 30, 2023

brwilkinson Mar 30, 2023 Maintainer

davidkarlsen May 24, 2023

Slapointe jan 20, 2022, {{editor}}'s edit, brwilkinson jan 24, 2022 maintainer, jfolberth jan 24, 2022 author, azmantas jan 23, 2022, brwilkinson feb 2, 2022 maintainer, jfolberth feb 3, 2022 author.

This discussion was converted from issue #5669 on January 19, 2022 21:52.

• Numbered list
• Unordered list
• Attach files

Select a reply

Allen on Azure

Azure architect, enthusiast and evangelist

Azure Service Bus geo-paired namespace

I was recently asked by a client to provision an automated failover solution for their geo-paired Azure Service Bus namespace, whereby an alert is automatically generated and sent via email or Microsoft Teams to a reviewer. The reviewer can then immediately grant approval to activate the automated failover to the secondary namespace and break the pairing, following best practices.

The architectural components are deployed via Terraform and PowerShell for Infrastructure as Code (IaC) to satisfy the CI/CD requirements.

By default, Microsoft describes manually failing over the geo-paired Azure Service Bus namespace due to the interconnected subsystems or infrastructure.”

The Terraform script can be found here

Deployment Plan

Part 1 – The architectural design and deployment of the Azure Service Bus geo-paired namespace across 3 availability zones in each region, (high availability)

Part 2 – The architectural design and deployment of the Azure Service Bus geo-paired namespace across two Azure regions (disaster recovery)

Part 3 – The security pattern overlay for your Azure Service Bus geo-paired namespace secured with private endpoints

Part 4 – The monitoring and alerting architecture of your Azure Service Bus geo-paired namespace architecture

Part 5 – Provisioning an automation platform architecture to automate the failover of your Azure Service Bus geo-paired namespace

Deployment Steps

Enable the Microsoft.ServiceBus on your subscription using azure cli:

I have written a Terraform script to provision the Azure Service Bus geo-paired namespaces as high availability across 3 availability zones in each region to satisfy any high availability requirements.

There is no additional cost for enabling availability zones. You cannot disable or enable availability zones after namespace creation.

Refer to step 4 and step 5 of the Terraform script .

Step 3 – Provisioning acros s 2 Azure regions

The Terraform script will deploy your Azure Service Bus geo-paired namespaces across two Azure regions using a geo-paired namespace, satisfying disaster recovery requirements.

Refer to step 6 and step 7 of the Terraform script .

Lets harden your architecture by overlaying a security pattern over your Azure Service Bus geo-paired namespace deployments by implementing private endpoints to prevent any traffic traversing the public internet.

I have provisioned four private endpoints across 2 virtual networks. Your virtual networks may be in the same or multiple regions. Be aware of the inter-regional traffic costs.

Refer to step 8 and step 9 in the Terraform script .

Provisioning monitoring and alerting of your Azure Service Bus namespace deployments,

A log analytics workspace is provisioned in step 10 of the Terraform script from which we will run Kusto Queries to provision the alerting platform.

The Terraform script deploys the log analytics workspace but does not configure the diagnostics logging.

You will need to configure diagnostic logging as per your bespoke primary namespace/s that you plan to monitor (in the next step),

Step 6 – Diagnostics monitoring

6.1 Connect to your Azure Monitor Workspace

A great source of logs can be collected from the Azure Monitor subscription activity logs connected workspace.

The Azure Service Bus monitoring data, including logs and metrics, is collected and analyzed using Azure Monitor. To generate the log analytics table for Azure Service Bus with the specific query you’ve provided, you would connect to the AzureDiagnostics table in the Log Analytics Workspace connected to the subscription activity logs. This table stores the diagnostic logs for various Azure services, including Azure Service Bus.

6.2 Connect your Primary Service Bus Namespace

Go to your Azure service bus primary namespace > diagnostic settings >

Select your choice of logs based on what metrics you plan to monitor here.

(Remember that logs are cost consumptive based on data at rest and data in transit to your log analytics workspace, so choose carefully),

I chose Operational Logs and AllMetrics to only monitor the management plane of the Azure Service Bus namespace,

Select your collection endpoint > log analytics workspace,

After the initial setup, the log analytics workspace will take around 3 hours to seed with log data. Thereafter, the Azure monitor logs take < 10 minutes to sync to the log analytics workspace every time an event occurs.

The results will show you the last time the namespace was active or search for errors | failures.

Go to your Log Analytics Workspace > Logs > and paste and customize your Kusto Query based on your bespoke environment.

Step 9 – Provision your Automation Account

The PowerShell script below helps to deploy an Azure automation account with a system assigned managed identity enabled.

Enablement of the SAMI is essential for the running of the PowerShell script.

Follow my blog here on how to provision a new automation account and with the preparation for PowerShell:

https://allenvisser.azurewebsites.net/2023/06/29/using-azure-automation-to-schedule-powershell-scripts/

After step 9, an additional module is required to import the Start-AzServiceBusGeoDRFailOver,

Go to Modules > + Add a module >

Browse from gallery > click on the browse from gallery link > Do a search for Servicebus and select the module Az.ServiceBus > Import

Step 11 – Create your Runbook

Search for runbooks and + Create a runbook

Enter your bespoke descriptive name,

Select the runbook type as PowerShell ,

Select a runtime version as recommended ,

Enter a descriptive description,

Review and Create > Create ,

The aim of this PowerShell script is to achieve a safe failover for an Azure Service Bus geo-paired namespace from the primary namespace to a secondary namespace.

NOTE: The PowerShell script is dependent on the enablement of the automation account SAMI with RBAC role permissions of Contributor.

After pasting the PowerShell code into your runbook, select Save

Verification :

Make sure to have executed the Terraform script in your sandbox so that all the resources and pairing are in place.

To verify that your runbook works in your sandbox, click on Testpane > Start

Once your Test runs successfully, you will receive a completed message

In the portal you can confirm that your pairing is updating

Until you notice the end state of no geo pairing.

If you go to your secondary service bus namespace, you will see logs showing a successful Failover has taken place.

Publish your runbook

This runbook will be incorporated into your automated logic app or power automation platform.

NOTE: This automation account manual test will have failed over your geo-paired namespace and broken the pairing. Before continuing with the demonstration, you will have to run a Terraform destroy to delete all the resource and then run Terraform apply to recreate all the resources before we can test the logic app automation flow.

Configuring your Automation Flow

Decide on whether to configure a Power Automation or Logic Apps automation platform. (I dont have a Power Automation license on my sandbox so Im building out on Logic Apps).

Step 12 – Create your Logic App

Create a simple Consumption based logic app.

Refer to my pricing section for more details.

We are going to run the designer actions against the SAMI account

Go to the Logic App Identity,

Enable the System Identity > ON > Save >

Enable system assigned managed identity > Yes >

Select Azure role assignments button under the system assigned tab >

+ Add role assignment > select Monitoring Reader and Contributor

Add a trigger > Recurrence schedule,

Configure a 10 minute frequency (the Azure Monitor takes < 10 minutes to sync log data to the log analytics workspace),

Add an action

Select Run query and list results

Create your bespoke connection name and select the Logic Apps MI (you are going to reference the logic app SAMI you enabled earlier),

Click on Create New

Populate the pre-tested KQL query from earlier,

Now find the source log analytics workspace:

Select the destination subscription, resource group,  resource type (log analytics workspace),

Resource name, and date range

Add a control condition (to choose what to do if the Kusto Query returns a positive result),

Click on the value space and select the dynamic content list.

Add the dynamic content value based on your Kusto Query search criteria. Leave the other values empty as you have already defined the search criteria in your Kusto Query.

Save your work,

Now select the True branch and setup an alert that needs to be sent to an approver when your selected metric condition is satisfied (eg when an Azure Service Bus namespace Error is created within the defined time period in your Kusto Query),

Add an action,

Search and select Send an approval email

Select your preferred email platform,

Setup your distribution group email address,

Select a body from the advanced parameters,

Change the importance to High ,

Customize your Subject line,

Take note of the User Options Approve | Reject. We will be using this later.

Save and Run the designer to test functionality,

Step 12 – Approver notification

Your designated approver should get an approval email if the logic app conditions are met,

Select Approve to initiate the remainder of the flow,

Upon selecting Approve the approval banner will appear,

Add an Action,

Search and add a second control condition

In the condition, search dynamic content for SelectedOption ,

In the next section, type in Approve (case sensitive with trimming)

Go to True and select Add an action,

Search for azure automation ,

Select Create job ,

Create a connection name and select the Authentication Type of Logic Apps Managed Identity (which requires you to have configured the RBAC role of Contributor across the subscription as completed earlier),

Create new,

In the Create job section,

Point to the previously created Automation Account,

Point to your target Automation Account > subscription, resource group and AA name,

Now open your Advanced parameters and select your Runbook Name (without this vital runbook name, your execution will fail) > and populate your runbook name,

With your Runbook name inserted, select to wait for the Automation Account job to finish running before moving onto the next step.

Save your designer,

Send an email (v2) on your chosen platform,

Complete the email fields and to whom the confirmation email must be sent,

Upon successful completion, the approver would receive a confirmation email.

You will also be able to view the Automation Account Activity logs to verify that the automation job executed to failover the Service Bus Namespaces and break the pairing.

You will also be able to view the (Primary) Service Bus Activity logs to verify that the break pairing did in fact begin. (Im not sure why the error is produced when the pairing break does take place successfully),

The final verification is to check the primary service bus namespace and verify that the failover has taken place and the pairing has in fact been broken.

Consumption App Pricing

— I hope this blog helped you with the automation of your geo-paired Azure Service Bus namespace —-

Leave a comment Cancel reply

Your email address will not be published. Required fields are marked *

Save my name, email, and website in this browser for the next time I comment.

Elektrostal

City in moscow oblast, russia / from wikipedia, the free encyclopedia, dear wikiwand ai, let's keep it short by simply answering these key questions:.

Can you list the top facts and stats about Elektrostal?

Summarize this article for a 10 year old

• Bahasa Indonesia
• Eastern Europe
• Moscow Oblast

Elektrostal

Elektrostal Localisation : Country Russia , Oblast Moscow Oblast . Available Information : Geographical coordinates , Population, Area, Altitude, Weather and Hotel . Nearby cities and villages : Noginsk , Pavlovsky Posad and Staraya Kupavna .

Information

Find all the information of Elektrostal or click on the section of your choice in the left menu.

• Update data

Elektrostal Demography

Information on the people and the population of Elektrostal.

Elektrostal Geography

Geographic Information regarding City of Elektrostal .

Elektrostal Distance

Distance (in kilometers) between Elektrostal and the biggest cities of Russia.

Elektrostal Map

Locate simply the city of Elektrostal through the card, map and satellite image of the city.

Elektrostal Nearby cities and villages

Elektrostal weather.

Weather forecast for the next coming days and current time of Elektrostal.

Elektrostal Sunrise and sunset

Find below the times of sunrise and sunset calculated 7 days to Elektrostal.

Elektrostal Hotel

Our team has selected for you a list of hotel in Elektrostal classified by value for money. Book your hotel room at the best price.

Elektrostal Nearby

Below is a list of activities and point of interest in Elektrostal and its surroundings.

Elektrostal Page

• Information /Russian-Federation--Moscow-Oblast--Elektrostal#info
• Demography /Russian-Federation--Moscow-Oblast--Elektrostal#demo
• Geography /Russian-Federation--Moscow-Oblast--Elektrostal#geo
• Distance /Russian-Federation--Moscow-Oblast--Elektrostal#dist1
• Map /Russian-Federation--Moscow-Oblast--Elektrostal#map
• Nearby cities and villages /Russian-Federation--Moscow-Oblast--Elektrostal#dist2
• Weather /Russian-Federation--Moscow-Oblast--Elektrostal#weather
• Sunrise and sunset /Russian-Federation--Moscow-Oblast--Elektrostal#sun
• Hotel /Russian-Federation--Moscow-Oblast--Elektrostal#hotel
• Nearby /Russian-Federation--Moscow-Oblast--Elektrostal#around
• Page /Russian-Federation--Moscow-Oblast--Elektrostal#page
• Terms of Use
• Copyright © 2024 DB-City - All rights reserved
• Change Ad Consent Do not sell my data