Hello,

I can deploy successfully the connector and all the other components, but when I put the Org name and the API key I get this error:

The permission in Github is the one requested and I even added +80 Azure IPs to our allowlist.

Still get the same error.

Appreciate any help.

​Hello, I can deploy successfully the connector and all the other components, but when I put the Org name and the API key I get this error: The permission in Github is the one requested and I even added +80 Azure IPs to our allowlist.Still get the same error. Appreciate any help.  Read More

​

We are excited to announce the general availability of workspaces in Azure API Management! Workspaces enable organizations to manage APIs more productively, securely, and reliably using a federated approach.

Enhanced Autonomy and Productivity

Workspaces bring a new level of autonomy to API teams, enabling them to create, manage, and publish APIs faster, more reliably, securely, and productively within an API Management service. By providing isolated administrative access and API runtime, workspaces empower API teams, while allowing the API platform team to retain oversight with central monitoring, enforcement of API policies and compliance, and publishing APIs for discovery through a unified developer portal.

Isolated Administrative Access and API Runtime

Workspaces function like “folders” within an API Management service. Each workspace contains APIs, products, subscriptions, named values, and related resources. Access to resources within a workspace is managed through Azure’s role-based access control (RBAC) with built-in or custom roles assignable to Microsoft Entra accounts.

Workspaces now offer API runtime isolation through association with a workspace API gateway, allowing teams to manage gateways and their configurations. Segregated runtimes ensure that faults, such as gateway resource starvation or cybersecurity incidents, are contained within individual workspaces, preventing them from affecting all organization’s APIs. Runtime isolation also enables attribution of issues and platform usage to a workspace.

Learn how to create a workspace in API Management.

Workspaces contain APIs, products and related resources that API teams manage. API runtime is provided by an associated workspace gateway. Developer portal, all-APIs policy, and logs and metrics may apply across workspaces.

Independent Deployment Lifecycles

Each workspace typically follows its own deployment lifecycle. The APIOps toolkit release 6.0.2 introduces support for automated deployment of workspaces across API Management services representing different environments. Additionally, the management API version 2023-09-01-preview enables programmatic management of workspaces.

Federated API Management with Workspaces

Workspaces bring first-class support for a federated model of managing APIs in Azure API Management, complementing the existing centralized and siloed models.

Centralized Model

In the centralized model, organizations use a single API Management service shared among multiple API teams without isolating administrative access or API runtime. While this setup simplifies API governance and discovery, it can cause the platform team to become a bottleneck as more API teams are onboarded. Additionally, runtime issues or misconfigurations can lead to platform-wide outages, with the API gateway being a single point of failure.

Siloed Model

In the siloed API management model, each API team owns and operates its own API Management service. While this approach provides full isolation of administrative access and API runtime missing in the centralized model, it leads to internal proliferation of services, making infrastructure maintenance challenging, increasing costs, and resulting in fragmented and ineffective API governance and discovery.

Federated Model with Workspaces

Workspaces enable organizations to adopt a federated approach to API management, combining the benefits of both centralized and siloed models. Workspaces allow API teams to independently, effectively, and efficiently manage APIs throughout their lifecycle, while platform teams can enforce runtime policies for APIs across workspaces, centralize platform logs and metrics (coming soon), implement chargeback by attributing gateway costs to teams in the organization, and facilitate API discovery and onboarding through a unified developer portal.

Upcoming Improvements

With their general availability, workspaces serve as an excellent tool for federating API management in organizations where teams need or benefit from full API runtime isolation. We are actively working on new features and improvements to workspaces:

Shared gateways: Optimize platform costs by associating multiple workspaces with a shared gateway, if complete runtime isolation between workspaces isn’t required
Managed identity support: Authenticate with user-assigned managed identity within workspaces
Regional availability: Use workspaces in API Management services in more regions
Faster provisioning: Create workspace gateways in minutes
Enhanced monitoring: Complement Application Insights telemetry with Azure Monitor logs and metrics

Get Started Today

By isolating administrative access and API runtime for API teams and centralizing API governance and discovery, workspaces increase productivity and improve the reliability and security of APIs managed with API Management. Learn how to get started with workspaces.

Migrating from Preview to Generally Available Workspaces

As part of the general availability of workspaces, we are discontinuing support for preview workspaces in API Management. To continue using workspaces created during the preview, you need to make the following changes:

Associate workspaces with a workspace gateway: Each workspace must be associated with a workspace gateway that isolates the workspace’s runtime traffic, enhancing API reliability, resiliency, and observability. In preview, workspaces shared a gateway with the service.
Remove workspaces’ dependency on service-level managed identity: Service-level managed identity can no longer be used in workspaces, as it may compromise the platform’s reliability and security. We are working on enabling managed identity support within workspaces.

Workspaces without a workspace gateway or relying on service-level managed identity will stop working after March 31, 2025. Learn more about these changes and how to migrate your preview workspaces. If you need to associate multiple workspaces with a shared gateway to migrate to the general availability version of workspaces, this feature will be available before the changes take effect.

Explore the power of workspaces and take your API management to the next level today!

​Microsoft Tech Community – Latest Blogs –Read More 

this appears to be set but does not work

​this appears to be set but does not work   Read More

​

Overview: 

Azure Administrators often come across challenges while tracking multiple Azure role assignments and removals. At present Azure provides Activity Logs but they make less sense to non-techsavy stakeholders. For example it includes Role Id, Principal Id but doesn’t indicate Role names and Principal names which can make the report more readable. To ensure proper tracking and accountability, we need a comprehensive report that includes the following details:

Initiator and Timestamp
User/Group/Principal assigned/removed
Role assigned/removed
Scope of the Attempt   
          

Pre-Requisites:

Export subscription level Activity Logs to a Log Analytics Workspace. For this navigate to Subscription > Activity log > Export Activity Log > Add Diagnostic Setting 

Add Diagnostic Setting to export Administrative logs to a Log Analytic Workspace of your choice and hit the save button:
 

Navigate to the Workspace and Retrieve the Workspace ID from the overview section, we’ll require this in our script.

Solution:

We have created a solution that retrieves and refines information from the Log Analytic Workspace stored Activity Logs and creates a readable CSV report.

Sample Output:

PowerShell Script:

Please replace with appropriate workspace ID(line 32,33) and output CSV file path(line 57, 78). You can provide same values for both at multiple places. Based on the requirement and Log Analytics Retention the no. of days can also be edited(line 6,20)

#Login Azure Account
Add-AzAccount

#Log Analytics query for retrieving Role Assignment addition activities for the past 2 days
$addqr = ‘AzureActivity
| where TimeGenerated > ago(2d)
| where CategoryValue =~ “Administrative” and OperationNameValue =~ “Microsoft.Authorization/roleAssignments/write” and ActivityStatusValue =~ “Start”
| extend RoleDefinition = extractjson(“$.Properties.RoleDefinitionId”,tostring(Properties_d.requestbody),typeof(string))
| extend PrincipalId = extractjson(“$.Properties.PrincipalId”,tostring(Properties_d.requestbody),typeof(string))
| extend PrincipalType = extractjson(“$.Properties.PrincipalType”,tostring(Properties_d.requestbody),typeof(string))
| extend Scope = extractjson(“$.Properties.Scope”,tostring(Properties_d.requestbody),typeof(string))
| extend RoleId = split(RoleDefinition,”/”)
| extend InitiatedBy = Caller
| extend Operation = split(OperationNameValue,”/”)
| project TimeGenerated,InitiatedBy,Scope,PrincipalId,PrincipalType,RoleID=RoleId[4],Operation= Operation[2]’

#Log Analytics query for retrieving Role Assignment removal activities for the past 2 days
$rmqr = ‘AzureActivity
| where TimeGenerated > ago(2d)
| where CategoryValue =~ “Administrative” and OperationNameValue =~ “Microsoft.Authorization/roleAssignments/delete” and (ActivityStatusValue =~ “Success”)
| extend RoleDefinition = extractjson(“$.properties.roleDefinitionId”,tostring(Properties_d.responseBody),typeof(string))
| extend PrincipalId = extractjson(“$.properties.principalId”,tostring(Properties_d.responseBody),typeof(string))
| extend PrincipalType = extractjson(“$.properties.principalType”,tostring(Properties_d.responseBody),typeof(string))
| extend Scope = extractjson(“$.properties.scope”,tostring(Properties_d.responseBody),typeof(string))
| extend RoleId = split(RoleDefinition,”/”)
| extend InitiatedBy = Caller
| extend Operation = split(OperationNameValue,”/”)
| project TimeGenerated,InitiatedBy,Scope,PrincipalId,PrincipalType,RoleID=RoleId[6],Operation= Operation[2]’

#Please replace with appropriate workspace ID
$addqueryResults = Invoke-AzOperationalInsightsQuery -WorkspaceId “<replace with Workspace ID>” -Query $addqr
$rmqueryResults = Invoke-AzOperationalInsightsQuery -WorkspaceId “<replace with Workspace ID>” -Query $rmqr

#Isolating Log Analytics query results
$addqrs = $addqueryResults.Results
$rmqrs = $rmqueryResults.Results

#For each add query result find user/group name and role name to append into the CSV report
foreach ($qr in $addqrs)
{
$rd = Get-AzRoleDefinition -Id $qr.RoleID
if($qr.PrincipalType -eq ‘User’)
{
$prncpl = Get-AzADUser -ObjectId $qr.PrincipalId
}
elseif($qr.PrincipalType -eq ‘Group’){
$prncpl = Get-AzADGroup -ObjectId $qr.PrincipalId
}
else{
$prncpl = Get-AzADServicePrincipal -ObjectId $qr.PrincipalId
}
$qr | Add-Member -MemberType NoteProperty -Name ‘Role’ -Value $rd.Name
$qr | Add-Member -MemberType NoteProperty -Name ‘PrincipalName’ -Value $prncpl.DisplayName

#Replace with appropriate path
$qr | Export-Csv -Path “<Replace Path><FileName.csv>” -NoTypeInformation -Append
}

#For each remove query result find user/group name and role name to append into the CSV report
foreach ($qr in $rmqrs)
{
$rd = Get-AzRoleDefinition -Id $qr.RoleID
if($qr.PrincipalType -eq ‘User’)
{
$prncpl = Get-AzADUser -ObjectId $qr.PrincipalId
}
elseif($qr.PrincipalType -eq ‘Group’){
$prncpl = Get-AzADGroup -ObjectId $qr.PrincipalId
}
else{
$prncpl = Get-AzADServicePrincipal -ObjectId $qr.PrincipalId
}
$qr | Add-Member -MemberType NoteProperty -Name ‘Role’ -Value $rd.Name
$qr | Add-Member -MemberType NoteProperty -Name ‘PrincipalName’ -Value $prncpl.DisplayName

#Replace with appropriate path
$qr | Export-Csv -Path “<Replace Path><FileName.csv>” -NoTypeInformation -Append
}

# End of Script

Hope this helps!

​Microsoft Tech Community – Latest Blogs –Read More