In Spring security you can whitelist the incoming IP using hasIpAddress. Is it possible to have a whitelist for the incoming domain/url/servicename?
I have two services in a kubernates cluster, most of their endpoints can only be accessed with the accessed token (legacy filter can't be removed). However, I would like one service to call the other without a token for a particular endpoint (let's say service A call service B). Is it possible to specify the service name rather than the ip to be whitelisted in service B? I don't want to make the endpoint to be publicly accessible. Do I have to convert to IP like this
InetAddress ipaddress = InetAddress.getByName(service);
Is there something smart for Kubernetes services?
Maybe you can try to use the internal kubernetes dns link so you don't have to specify the ip address.
Related
I could use some advice… I think I might be missing something obvious here but I’m trying to understand how microservices communicate when using the API gateway or BFF networking pattern. Each of the microservices will obviously have an API as well, so how are they any less accessible than the API gateway? Surely they have HTTP endpoints as well? How does a virtual network limit the microservices to only being accessible from the API gateway? Does that make sense? All the tutorials I find online seem to assume I understand! I’m confused.
Microservices network diagram
Microservices in your VPC have private IP addresses that are only directly routable within that VPC. They are not available on the internet at all, unless you explicitly provide them with a public IP, or via another way in, like an API gateway, load balancer with an assigned public IP, transit gateway, etc.
Resources in your VPC can also be assigned to security groups that provide fine control over which IP addresses are allowed to communicate with them on which ports.
I find my server node's endpoint >/v1/agent/services returns majority of services, but not all the services, anyone knows why ?
The visibility of services will depend on which API endpoint you're using.
Consul intends for services to be registered against a Consul client agent which is running on the same host as the deployed service (using the /v1/agent/service/register endpoint). The services registered with each agent in the data center are aggregated to form the service catalog (https://www.consul.io/docs/architecture/anti-entropy#catalog).
The /v1/agent/services endpoint only returns services which have been registered against the specific agent with which you are communicating. In contrast, the /v1/catalog/services endpoint returns an aggregated list of all services which have been registered every agent across the data center. If you query this endpoint, you will receive a list of all services registered with Consul.
I am developing several services, and use consul as the service registry. I'm able to register all of my services to the consul.
And now for the next thing to do, I need to be able to communicate from service A to service B.
Without a service registry, usually what I did was simply dispatch a client HTTP request from service A to service B.
But since now I already have service discovery in place, should I get the service B host address via consul and then dispatch a client HTTP request to the service B host address something like that? Or does the consul also provide an API gateway, so I only need to dispatch my client HTTP request from service A to the consul, and then the consul will automatically forward it to the destination?
Also if there is relevant documentation about my case, I would be very glad to take a look at it? (I can't find the relevant documentation, probably my google search keyword is wrong)
Consul supports two methods for service discovery, DNS and HTTP.
Applications can perform DNS lookups against their local Consul agent which exposes a DNS server on port 8600 (you can also configure DNS forwarding). For example, an application can issue an A record query for web.service.consul and Consul will return a list of healthy instance endpoints for the web service. SRV lookups are also supported in order to retrieve the IP and port for a given service. The DNS interface also supports querying endpoints by service tag and data center. Details can be found at Consul.io: DNS - Service Lookups.
HTTP-based service discovery can be performed by querying the /v1/health/service/:name endpoint against the local agent. The following will return a full list of healthy and unhealthy endpoints for the service nginx.
$ curl http://127.0.0.1:8500/v1/health/service/nginx
You can use the passing query parameter to restrict the output to only healthy services.
$ curl "http://127.0.0.1:8500/v1/health/service/nginx?passing"
I recommend reviewing the guide Register a Service with Consul Service Discovery for more info on registering and querying services from the catalog.
Lastly, API gateways like Traefik and Solo's Gloo support using Consul for service discovery (see Traefik's Consul Catalog Provider and Gloo's Consul Services). You could configure your services to route requests to these gateways, and allow the gateway to forward to the backend destination.
I ended up getting the list of services info from the consul, and then perform name matching on it then get the service address.
I use this endpoint to get the list of the services and it's data:
http://localhost:8500/v1/agent/services
So it's the client-side discovery I guess.
Basic and Naive question, I saw a demo on youtube how consul server and agent can work together to deliver a web service hosted at port 80 based on its availbilty. i.e. from which server is up , it will make that service availble. However for scenario I am asking if we can specifically redirect user to an endpoint of similar web service based on the location where the user is requesting from ?
if its is possible what confuguration for consul would it take to do ?
Consul uses a network tomography system to compute network coordinates for nodes in the cluster. Inside a data center this can be used in combination with Prepared Queries (in addition to other methods) to discover service instances near a given agent in the data center.
For traffic from external users, you'll want to a use a DNS global traffic manager like NS1 or F5's BIG-IP DNS to direct end-users to the closest data center. Once inside the data center, you can utilize Consul to route the connection to the nearest service instance.
See this blog post from NS1 about their integration with Consul, and ability route traffic based on service location. https://ns1.com/blog/hashicorp-and-ns1-automating-application-networking-for-microservices
I am trying to create a new traffic manager profile of either Performance or Weight configuration but I keep getting stuck when trying to add an Azure Endpoint.
I have a two public IP inside of Azure, one with an optional DNS name, one with out.
When I try to add either of these as an endpoint, I get the following error message:
The one with a dns name on it:
Failed to save configuration changes to Traffic Manager profile 'profilename'. Error: Endpoint target type, 'DomainName', is not allowed for this profile. Valid values are: IPv4Address.
The one without a dns name:
No DNS name is configured.
If i choose External Endpoint and add the IPv4 directly it will work.
I tried with several different Traffice Manager profiles.. Is there a secret that I am missing out on? I am stuck..
Usually, There are three types of endpoint supported by Traffic Manager:
Azure endpoints are used for services hosted in Azure.
External endpoints are used for IPv4/IPv6 addresses, FQDNs, or for services hosted outside Azure that can either be on-premises or
with a different hosting provider.
Nested endpoints are used to combine Traffic Manager profiles to create more flexible traffic-routing schemes to support the needs
of larger, more complex deployments.
...
Azure endpoints are used for Azure-based services in Traffic Manager.
The following Azure resource types are supported:
PaaS cloud services. Web Apps Web App Slots PublicIPAddress resources
(which can be connected to VMs either directly or via an Azure Load
Balancer). The publicIpAddress must have a DNS name assigned to be
used in a Traffic Manager profile.
In this case, when you add a public IP address in the same subscription as an Azure endpoint, it will grey out if no DNS name configured in the Azure portal. You could add it when the public IP address configured with Azure provided DNS name like somedns.westus2.cloudapp.azure.com, this works on my side.
For example, there is a public IP address with the DNS name used for an Azure load balancer frontend.