Frequently Asked Questions

All resources, including hidden resources in Azure, are shown in the diagram that is based on the resource group viewpoint. However, resource types that aren't fully supported yet are shown as being of the default "Resource" type. This means that it isn't possible to see the detailed properties of that resource type yet. Full support for additional resource types are added based on community feedback.

NubOps currently supports graphically describing and providing detailed properties for the following resource types:

• IaaS services
• - Virtual Machines
• - Virtual Machine Scale Sets
• - Virtual Machine Scale Set Virtual Machines
• - Availability Sets
• - Proximity Placement Groups
• - Capacity Reservation Groups
• - Dedicated Host Groups

• PaaS services
• - Web Apps
• - Web App Plans
• - Web App Slots
• - Web App Configurations
• - Web App Slot Configurations
• - Autoscale Settings
• - App Service Environments
• - Function Apps
• - Logic Apps (standard)

• Container services
• - Container Registries
• - Container Instances
• - Container Groups
• - Managed Clusters

• Serverless services
• - Logic Apps (consumption)
• - Integration Accounts
• - Api Management Service
• - Event Hub Namespaces
• - Event Hubs
• - Notification Hub Namespaces
• - Notification Hubs

• DBaaS services
• - Azure SQL Servers
• - Azure SQL Databases
• - Azure SQL Elastic Pools
• - MySQL Servers
• - MySQL Databases
• - Cosmos DB Accounts
• - Redis Caches
• - PostgreSQL Servers
• - PostgreSQL Databases
• - MariaDB Servers
• - MariaDB Databases

• Network services
• - Virtual Networks
• - Route Tables
• - Network Security Groups
• - Public IP Addresses
• - Network Interfaces
• - Load Balancers
• - Traffic Manager Profiles
• - Public IP Prefixes
• - Virtual Gateways
• - Local Gateways
• - App Gateways
• - Web Application Firewall Rulesets
• - Front Doors
• - Azure Firewalls
• - Azure Virtual Hub Firewalls
• - Private Endpoints
• - Private DNS Zone Groups
• - Private DNS Zones
• - Network Watcher
• - Network Watcher Flow Logs
• - Virtual WAN
• - Virtual Hubs
• - Virtual Hub Route Tables
• - Virtual Hub V2 Route Tables
• - Virtual WAN VPN Gateways
• - Virtual WAN VPN Sites
• - Virtual WAN P2S VPN Gateways

• Governance services
• - Management Groups
• - Log Analytics Workspaces
• - Diagnostic Settings
• - Blueprints
• - Blueprint Assignments
• - Application Insights
• - Recovery Services Vaults
• - Replication Fabrics
• - Replication Protection Containers
• - Replication Protected Items
• - Recovery Services Backup Policies
• - Backup Vaults
• - Backup Protection Containers
• - Backup Policies
• - Policy Set Definitions
• - Policy Assignments
• - Budgets
• - Management Locks
• - Automation Accounts
• - Software Update Configurations

• Security services
• - Key Vaults
• - Security Compliances
• - Secure Scores
• - Security Alerts
• - Security Contacts
• - Disk Encryption Sets

• Other services
• - Tenants
• - Subscriptions
• - Resource Groups
• - Regions
• - Certificates
• - Domain Registrations
• - Dns Zones
• - Bastion Hosts
• - Storage Accounts
• - Virtual Machine Disks
• - App Configurations

NubOps retrieves data by using an app registration that you create in your Azure AD tenant. You also need to assign the "Reader" role to the app registration in Azure IAM on the subscriptions that you want to work with in NubOps. To extract information from Azure AD (that is needed by the Asset Manager feature) you also need to assign permission for Microsoft's Graph API, but that isn't required if you only want to work with the Architect feature.

When you create an app registration (select 'single tenant mode') you'll get three values which are "tenant ID", "client ID" and "client secret". These three values are then entered into the "Edit project" window in NubOps so that you can verify that the connection works.

If everything works fine then you'll be able to see your tenant and subscriptions in the Architect feature once you've verified the connection, regardless if you have signed up for a NubOps subscription yet or not. However, you'll need to sign up for a NubOps subscription to see all the actual resources, but at least you've verified that everything is working as expected before you do so.

Microsoft provides this guide on this topic: Use the portal to create an Azure AD application and service principal that can access resources

You can also check out this video on how to create an App Registration: Getting started

When you create an app registration you also have to assign a role to that app registration in Azure IAM on the subscriptions you want NubOps to analyze.

Our recommendation is to start out by only assigning the app registration the "Reader" role on one single non-production subscription in Azure. If possible, create a new Azure subscription where you can experiment without affecting other resources. This will also reduce initial "noise" in NubOps as you start out.

The Policies feature will generate a lot of findings and recommendations so it makes sense to start out by creating a green field environment. Then you could create one resource type at a time, a virtual machine for example, to see what needs to be reconfigured based on the findings and recommendations provided by the Policies feature. This will give you insights into best practices concerning Azure security and governance. Once you've gained a good understanding on how to use NubOps, and identified potential improvements to the rest of your environment, you can use NubOps to verify that the tasks agreed upon within your organization have indeed been carried out and completed correctly according to plan.

When you create an app registration you prevent NubOps from accessing data by only assigning the Reader role to the app registration on those subscriptions that you want to use NubOps with.

When you create an app registration you have to assign permissions to Microsoft's Graph API (and issue admin consent) if you want to see additional information in the tenant object in the Architect feature, or if you want to use the Asset Manager feature. It isn't necessary to assign any such permissions if you only want to use the Architect feature and don't want to see any information about your directory in the tenant object.

We recommend following the information security principle called "Least privilege" for all types of authorizations, meaning that you should only grant the privileges or permissions that are required for NubOps to perform the task that you want it to. When you create the app registration select 'single tenant mode'. Also choose the "Application permissions" option since NubOps likely requires less permissions and privileges than your regular Azure user account has assigned to it. NubOps does not use your user account credentials, or piggy back on the permissions that your user account has, which means that it's probable that you see less in NubOps as compared to the Azure portal if you have adhered to the principle of "Least privilege".

Assign the following Microsoft Graph API permissions to the app registration based on how you want to use NubOps:

API permission required for verifying connection to Azure AD in the "Edit project" window:

• Organization.Read.All

API permission required for viewing directory data in the tenant object in the Architect feature:

• Organization.Read.All

API permissions required for using the Asset Manager and Policies features:

• Organization.Read.All
• Application.Read.All
• User.Read.All

Make sure you have entered the correct information for authenticating to Azure AD with the app registration and that the app registration has the necessary permission in Azure AD.

Go to the app registration in Azure AD, find the following values and enter them in the "Edit Project" window:

• Tenant Id: Copy the "Directory (tenant) ID" value from the app registration overview blade
• Client Id: Copy the "Application (client) ID" value from the app registration overview blade
• Client Secret: Copy the secret value from the app registration certificates & secrets blade

App registration API permission required for verifying connection to Azure AD using Microsoft's Graph API:

• Organization.Read.All: Add this permission in the app registrations API permissions blade and request an admin in your organization to issue admin consent. Admin consent is required in Azure AD for issuing this permission.

Delete the cloud data as a technical issue most likely occurred when it was retrieved from Azure. Retrieve the cloud data again and check to see if the architecture models look better afterwards. If this doesn't help then please submit a bug report to us so we can investigate the cause and release a bug fix.

We provide videos on our YouTube channel for those that are new to working with Azure but also on how to use the different features in NubOps. The purpose of these videos is in one part to showcase the different features in NubOps but we also want to provide insights that will help you out when starting to work with Azure or to improve governance and security controls in your Azure environment.

Here is the link to our channel: NubisOperandis

The videos are mainly focused around these topics:

• Introduction to NubOps and tutorials for new users
• Detailed walkthroughs on how to use specific features in NubOps
• Information about reference architectures for different types of resources that can be deployed in Azure
• Insights into best practises and Microsoft recommendations regarding governance and security controls in Azure

There are two architecture viewpoints in NubOps which are customizable in the way that they are based on the 'tags' that you have assigned to your resources in Azure, i.e. virtual machines, availability sets, web apps, databases, etc. These two viewpoints generate the 'Applications' and 'Application Tiers' entities in the Architect feature and those are created based on the following tags:

• 'Application' or 'ApplicationId'
• 'ApplicationTier'
• 'Environment'

The two application viewpoints support these four tiers:

• Presentation
• Application
• Data
• Storage

There are multiple options for assigning values to the 'ApplicationTier' tag. These values are case-insensitive meaning that NubOps supports all variations regarding upper and lower casing.

Supported 'Presentation tier' tag values:

• Frontend
• FE
• Web

Supported 'Application tier' tag values:

• Backend
• BE
• App
• Application
• ApplicationServer
• Middleware
• Middle

Supported 'Data tier' tag values:

• Data
• DB
• Database

Supported 'Storage tier' tag values:

• Storage
• Disk
• SAN

You can use either the 'Application' or 'ApplicationId' tag as the primary name which is what will appear in the left sidebar in the Architect feature. The 'ApplicationId' is usually a unique ID that is related to the use of a CMDB. If you aren't using a CMDB for asset management of Azure resources then only the 'Application' is necessary to use. Since the same application likely has been installed in multiple subscriptions (such as development, test, QA, production) NubOps modifies the application name shown in NubOps to reflect which environment the application is running in. Assigning the name 'MyApplication' to a resource in the 'test' environment means that the application will be shown as 'MyApplication-test' in NubOps. This makes it easier to avoid confusion when analysing the application using the Architect feature. The purpose of this is that resources from different subscriptions and environments won't be grouped together in the same model. This makes sense especially since it should be a priority to investigate issues in an production environment before anything else.

The 'Environment' tag is necessary to assign to the resources since the same application could be installed in a development subscription, another instance in a test subscription and a third instance in a production subscription. This means that if the environment tag wasn't used then all these instances from all subscriptions would be grouped together in the same architecture model which would make the architecture model nearly impossible to analyse. This is primarily a fail safe mechanism to avoid a scenario where resources from different subscriptions are given the same value in the 'Application' tag.

Regarding the 'ApplicationTier' tag it can have the values: Frontend, Backend, Data or Storage. These values are used to create the tiers in the model that corresponds to the architecture layers in your application. You can use one, two, three or all four tiers in whichever combination you want.

Read more about using tags to organize Azure resources here: Use tags to organize your Azure resources and management hierarchy

Check out this video to learn more about the Application viewpoint: Create solution architecture models based on tags using the application viewpoint