Is there any way to restore the deleted API on Azure APIM? The API was deleted recently (3 days back).
We have azure APIM instance backup taken daily, but we want to avoid complete instance restore as APIM service has 100+ APIs. Can we restore a single API from backup?
You cannot recover a deleted API from the Azure API management instance.
As Per the current Azure documentation, we can recover a soft-delete API Management Instance & currently this feature is in preview.
It depends on how you delete an API Management instance, the instance is either soft-deleted and recoverable during a retention period, or it's permanently deleted:
When you use the Azure portal or REST API version 2020-06-01-preview or later to delete an API Management instance, it's soft-deleted.
An API Management instance deleted using a REST API version before 2020-06-01-preview is permanently deleted.
An API Management instance deleted using API Management commands in Azure PowerShell or Azure CLI is permanently deleted..
Related
I am new to Azure API Manager, I have used Apigee Edge before where you can store each api proxy code in either git or SVN. But in Azure I am not sure how each API that is exposed via the gateway is stored. I can see there is a repository for the whole API Manager instance. Does that mean all the APIs are bundled to the same Gateway Instance and stored there?
I am planning to build a CI/CD pipeline to create the APIs in the API Manager for that I need to understand how the APIs code will be stored.
Your help is appreciated. Thanks.
Besides the GIT repository for the apimanagement instance, you can fetch it in form of ARM templates. Refer this blog.
https://azure.microsoft.com/en-in/blog/build-a-ci-cd-pipeline-for-api-management/
I'm deploying WSO2 API manager 2.6.0 with an external MySQL database and I'm trying to have my API's persist when I change my deployment.
Currently I have 2 deployments using the same external database, one local and the other hosted on an AWS EKS cluster. When I create an API on my local deployment, I can only view it on my AWS deployment if I'm logged in to the store, and visa-versa for my localhost deployment.
The expected and desired behaviour is that all APIs created on both deployments should be displayed on the store no matter if I'm logged in or not, is there any configurations I can change to make the happen?
Here is the doc I used to configure the external database: https://docs.wso2.com/display/AM260/Installing+and+Configuring+the+Databases
I have an ASP.NET Core REST API Service hosted on an Azure Web App. I own its source code and I can change it if required.
I am planning to publish REST API Service with Azure API Management.
I am adding Azure AD authentication to the Azure API Management front. So, the API management front is secured. All the steps are is described here.
All good so far. Here is the question (or challange?) :
Considering that my backend REST API Service is hosted on Azure and publicly accessible, how do I protect it against the request calls other than the API Management Calls?
How the backend service knows the identity and AAD group claims of the incoming call and access to its claims?
A link to a code sample or online documentation would be a great help.
Update
While there are some overlaps with the follwoing question:
How to prevent direct access to API hosted in Azure app service
... part of this question is still outstanding:
How the backend service knows the identity and AAD group claims of the incoming call and access to its claims?
You can enable static IP restriction on your WebApp to only allow incoming traffic from the VIP of your APIM Service facing ( keep in mind in some specific scenarios , the VIP may change and will be required to update the whitelist again).
Clients ==> AAD==> VIP APIM Service <==> (VIP APIM allowed) Web App
https://learn.microsoft.com/en-us/azure/app-service/app-service-ip-restrictions
I have multiple environments in Google Compute Engine (dev, staging, and production), each with its own Google Cloud SQL instance. The instances connect via Cloud SQL Proxy and authenticate with a credential file that is tied to a service account. I want to have a separate service account for each environment, which would be restricted to accessing the SQL instance specific to that environment. Currently, it appears that any service account with role Cloud SQL Client can access any Cloud SQL instance within the same project.
I cannot find any way to restrict access on a Cloud SQL Instance to a specific service account. Is it possible, and if so, how? If not, is there a different way to achieve the goal of preventing a server in one environment from accessing a Cloud SQL instance in another environment?
NOTE: this configuration is possible with Google Cloud Storage; one can assign a specific service account to have various permissions on each bucket, so that the dev service account cannot accidentally access Production files.
Unfortunately, Cloud SQL currently does not support instance level IAM policies.
The only workaround is hosting the instances in different projects.
As of the August 2021 release of Google Cloud SQL:
You can use IAM Conditions to define and enforce conditional, attribute-based access control for Google Cloud resources, including Cloud SQL instances
See the documentation for IAM Conditions for information about how to restrict a user or service account to specific Cloud SQL instances.
I have Google Cloud project consisting of a compute engine instance which I want to configure as a push subscriber of Cloud Pub/Sub service. I have setup an apache webserver with a self-signed certificate on the instance and have also made a DNS entry (abc.mydomain.com) which points to the instance which has a static IP address. I am already a verified owner of the domain (mydomain.com) on webmasters.
Whenever I add the subscription from the Cloud console, it fails with the error: "The subscription could not be added" and does not show any other useful information.
Please help.
Self-signed certificates are not supported.
There are few options for you:
Pay for the certificate
Use App Engine as a proxy
Use pull subscriptions
Use App Engine Managed VM
The last one is basically a Compute Engine instance, but you will get free https connection via a subdomain of appspot.com.