I am new to Networking and have some questions regarding some of the service tags in Azure NSG.
If you see below, Azure has multiple options for service tags while defining inbound NSG rules. But I failed to understand the scenarios for AzureKeyVault, Storge, Cosmos DB etc. in which scenarios these services initiate the request? Why do we need these service tags in the inbound NSG.
But I failed to understand the scenarios for AzureKeyVault, Storage,
Cosmos DB etc. in which scenarios these services initiate the request?
Why do we need these service tags in the inbound NSG.
It's not so good understanding for service tags in the inbound NSG as outbound NSG. For example, If you want to deny all outbound internet traffic and allow only traffic to specific Azure services such as AzurekeyVault or AzureCosmosDB. You can do so using service tags as the destination in your NSG outbound rules.
Similarly, If you want to allow or deny traffic from Azure service in a virtual network, Ip address or Application security group. You can do so using service tags as the source in your NSG inbound rules. For example, you can set the service tag AppService and specific IP addresses(some specific VM IP address) as the destination, then you could restrict the AppService to access the resources in your VM like API or database.
For more details, you can view scenarios for securing your Azure service.
Related
I have an ECS Fargate container app that serves the API request over the public internet.
My understanding is that this API service container can be deployed on the public subnet and that is configured with ALB DNS and target group. As we can see target group redirects the traffic to private IP of the ECS task, I guess we don't need public IP to be enabled when launching the task. However when I attempt this on ECS task launch getting an error "Resourceinitializationerror: unable to pull secrets or registry auth: execution resource retrieval failed: unable to retrieve ecr registry auth: service call has been retried 3 time(s): RequestError: send request failed caused by: Post "https://api.ecr.eu-west-2.amazonaws.com/": dial tcp 52.94.53.88:443: i/o timeout"
If this is not workable and we need to enable public ip on the task launch, I'd prefer to restrict the public IP port access only to web service ALB for best security practice. Could someone suggest me a workable approach on this use-case pls? Thanks.
"I'd prefer to restrict the public IP port access only to web service ALB for best security practice."
Have you tried doing that? It should work fine. Since security groups are stateful, as long as the outbound rules are open, you should be able to lock down the inbound rules on the security group.
If you want remove the public IP completely, then you will need to either deploy Fargate task to a private subnet, with a route to a NAT Gateway, or add VPC endpoints to your VPC for the AWS services that the task needs to access, like ECR.
I have an AWS API gateway that I created with zappa and an ECR docker image. I assigned the lambda function to a VPC but can no longer access the API.
I created an internet gateway and have the route table routing 0.0.0.0/0 and ::/0 to it.
I have all traffic allowed on all ports on the security group as well.
However, whenever I try to access any endpoints I get a timeout error. If I take the lambda function out of the VPC I am able to access all the endpoints.
You cannot access API gateway from lambda directly, if your lambda inside VPC. In this case you have to use VPC endpoint.
You can use Lambda functions to proxy HTTP requests from API Gateway to an HTTP endpoint within a VPC without Internet access. This allows you to keep your EC2 instances and applications completely isolated from the internet while still exposing them via API Gateway. By using API Gateway to front your existing endpoints, you can configure authentication and authorization rules as well as throttling rules to limit the traffic that your backend receives.
Reference: https://aws.amazon.com/blogs/compute/using-api-gateway-with-vpc-endpoints-via-aws-lambda/#:~:text=Conclusion,exposing%20them%20via%20API%20Gateway
I want to run an application on Azure service fabric. One service should serve as identity provider. So I installed identity server 4 package on that 'usermanager'. I have also two other services which should use this usermanager for authentication and authorization.
That works on localhost. But on Azure I have the problem that an endpoint must be 'Input' or 'Internal' in my service manifest. But for my usermanager I need both input and internal.
<Endpoint Protocol="http" Name="IdentityServerEndpoint" Type="Input" Port="5000" />
/.well-known/openid-configuration needs 'Internal' and
/connect/authorize?xxxxxx needs 'Input'
I found that for Input endpoints azure service fabric uses the full qualified domain name and for internal endpoints it uses the ip address of the lokal network like 10.0.0.4.
Is there a solution to make an endpoint both input and internal?
Or is there a solution to make identity server 4 to handle two endpoints?
Any ideas to solve this problem?
Believe it or not, the "Type" field in the Endpoint config doesn't actually do anything on any hosting platform. It's just metadata that you can configure and use in your code (basically a way for you to set your own policies). It doesn't matter what you put there otherwise.
Ultimately, you're opening an endpoint on a process on a VM. That endpoint will be open on the VM's IP and the port you choose, e.g., 10.0.0.1:5000.
If you want that endpoint to also be available on your cluster's VIP and FQDN, that configuration is external to Service Fabric. In Azure you just need to configure the Azure Load Balancer to forward external traffic on the port your service is listening on. See here for more info on that: https://learn.microsoft.com/en-us/azure/service-fabric/service-fabric-connect-and-communicate-with-services#connections-from-external-clients
I am deploying RESTful API's in Azure and protecting them with teh Azure API Manager. However, I've not been able to figure out how to restrict calls to the actual API to block requests going around the API manager. Is there a way in the web.config or something to restrict IP's, domain names.... on teh .net web api?
You can whitelist the IPs in c# code. Check below link for code changes,
https://weblogs.asp.net/senthil/restrict-ip-address-in-asp-net-web-api
You can get the static IP address of APIM in overview section. But you have to consider below points,
In all tiers of API Management, the public IP address (VIP) of the API Management tenant is static for the lifetime of the tenant, with some exceptions. The IP address changes in these circumstances:
The service is deleted and then re-created.
The service subscription is suspended or warned (for example, for
nonpayment) and then reinstated.
You add or remove Azure Virtual Network (you can use Virtual Network
only at the Developer and Premium tier).
For multi-region deployments, the regional address changes if the region is vacated and then reinstated (you can use multi-region deployment only at the Premium tier).
Premium tier tenants that are configured for multi-region deployment are assigned one public IP address per region.
You can get your IP address (or addresses, in a multi-region deployment) on the tenant page in the Azure portal.
Yes, you can configure call limits and quota policies through the API Management Portal, including inbound and outbound policies. Below is the policy template, you can choose what you want. Here Restrict caller IPs would meet your requirements.
For detailed configuration, please check this article and follow the steps.
I am going to use Secure Gateway service in Bluemix and I have some questions about how I should make it work.
Systems in my data center's intranet access the Internet through a proxy (with no authentication). Can Secure Gateway connect to Bluemix via a proxy?
Does it connect to Bluemix via HTTPS protocol?
The network admins asked me: What are the IPs (or the IP range) of Bluemix, any idea?
Thank you very much.
A Secure Gateway instance runs in two parts, as shown in "Reaching enterprise backend with Bluemix Secure Gateway via console": the gateway and the gateway client. The gateway runs in Bluemix, the gateway client runs in the data center containing one or more systems of record to connect to. The gateway client needs network access to the Bluemix data center (typically via the Internet) and to the systems of record (via the data center's internal network). The gateway client initiates the connection, so it needs to know Bluemix's address, but Bluemix doesn't need to know the gateway client's address.
To answer your questions specifically:
A proxy isn't supported. The gateway and its client need direct access to each other.
The connection uses HTTPS for SSL encryption. The transport level security (TLS) options can be used to add authentication.
Bluemix's IP addresses aren't published.
For point 3:
The client connects outbound to the cloud services. Once the SecGW is connected, all additional Destination connects flow through that connection, no additional firewall or iptables rules are needed. If they have a rule in-place so that the on-premises machine where the SecureGateway client is installed can use the outbound port 443 (HTTPS) to make connections, that is all they need.