I'm interested in putting a vendor provided application running in an AWS EC2 Instance behind my Istio gateway. It sounds like the ideal scenario is to use a WorkloadEntry to define the endpoint and make it easy to flex should I ever get this into the cluster, etc.
In the documentation I've read, there is mention of using a sidecar in the VM to enable this. What I've failed to find is how to use a sidecar in a VM. There's lots of good stuff about sidecars in a pod, but I'm not sure what it takes to implement on the VM and how I would even go about doing that. Maybe the integration needed for the sidecar would be to complex to implement in a 3rd party app? Maybe I can do this better without a Sidecar?
How do I find details on VM Sidecars and getting them integrated into the mesh?
When do you decide between implementing this as a WorkloadEntry vs simply a MESH_EXTERNAL ServiceEntry?
If you want to integrate a VM into your k8s Istio environment, you need to setup Istio on your VM :
https://istio.io/latest/docs/ops/deployment/vm-architecture/
Related
I am researching the use of Istio service mesh and finding the Envoy proxy is a very good service proxy option to work with it. But over last couple of years, the Envoy proxy seems to have grown as a cloud-native project. In our application, we need service proxy to sit beside our app and this service-proxy should do JWT validation for all incoming requests.
Now I am wondering should i just go with Envoy proxy and setup with JWT validation like explained here
https://www.scottguymer.co.uk/post/configuring-jwt-authentication-in-envoy/
Or should i set it up with along with Istio.
Istio also does the JWT claims based validation at the ingress gateway level.
https://istio.io/latest/docs/tasks/security/authentication/jwt-route/
But my main question is, to keep architecture light without adding too many layers (if we don't have to), should Envoy proxy be used without Istio in this specific case.
I have read this online.
Service mesh like Istio acts as a control plane and uses Envoy in the data plane to do app-level processing (like app-level JWT validation per app-node) via the Sidecar pattern.
But I am wondering if I really need to use service mesh if all i need is a service proxy beside each app-instance.
If you're using Kubernetes I recommend you to use Istio as it will be much easier to manage all your proxies in case you want to use many proxies.
With Istio you can also select in which namespaces or workloads apply the automatic sidecar injection, so you could decide which apps will run with sidecar, and which apps won't.
This is adding another layer, but it's also adding more security to your environment.
I'd like to have my Google Cloud Run services privately communicate with one another over non-HTTP and/or without having to add bearer authentication in my code.
I'm aware of this documentation from Google which describes how you can do authenticated access between services, although it's obviously only for HTTP.
I think I have a general idea of what's necessary:
Create a custom VPC for my project
Enable the Serverless VPC Connector
What I'm not totally clear on is:
Is any of this necessary? Can Cloud Run services within the same project already see each other?
How do services address one another after this?
Do I gain the ability to use simpler by-convention DNS names? For example, could I have each service in Cloud Run manifest on my VPC as a single first level DNS name like apione and apitwo rather than a larger DNS name that I'd then have to hint in through my deployments?
If not, is there any kind of mechanism for services to discover names?
If I put my managed Cloud SQL postgres database on this network, can I control its DNS name?
Finally, are there any other gotchas I might want to be aware of? You can assume my use case is very simple, two or more long lived services on Cloud Run, doing non-HTTP TCP/UDP communications.
I also found a potentially related Google Cloud Run feature request that is worth upvoting if this isn't currently possible.
Cloud Run services are only reachable through HTTP request. you can't use other network protocol (SSH to log into instances for example, or TCP/UDP communication).
However, Cloud Run can initiate these kind of connection to external services (for instance Compute Engine instances deployed in your VPC, thanks to the serverless VPC Connector).
the serverless VPC connector allow you to make a bridge between the Google Cloud managed environment (where live the Cloud Run (and Cloud Functions/App Engine) instances) and the VPC of your project where you have your own instances (Compute Engine, GKE node pools,...)
Thus you can have a Cloud Run service that reach a Kubernetes pods on GKE through a TCP connection, if it's your requirement.
About service discovery, it's not yet the case but Google work actively on that and Ahmet (Google Cloud Dev Advocate on Cloud Run) has released recently a tool for that. But nothing really build in.
We are looking to migrate our .NET Core applications to AWS. For some background information; At the moment we host our applications on VM's behind IIS, which with the .NET Core Hosting module, is very straight forward. Our applications are a combination of both intranet and externally facing applications, nothing with very high traffic demand.
After some research it seems like AWS ECS Fargate is a good option. The plan is to Dockerize our applications and deploy them to ECS Fargate at this point.
My consern is mainly about the topic of reverse proxies.
For now I have got an Identityserver application successfully running on ECS Fargate behind an Application Load Balancer. The ALB does TLS termination, and forwards traffic to the container running under ECS Fargate on http. It's a very straight forward setup, but I worry I am missing something as this really is not my field of expertise.
My question is, would the above setup sound sufficient? My current headache is if it would be worth to add Nginx (or similar) reverse proxies to the pipeline? In that case we'd have 2 scenarios as I understand it:
Keep the ALB and add another reverse proxy (say Nginx). The ALB still does TLS termination and forwards the traffic to Nginx which again forwards the traffic to the container running the application itself. I am maybe not seeing the benefits of this, however I fear I might be wrong. I feel it's adding unnecessary complexity to the setup.
Skip the ALB all together and expose Nginx (or another reverse proxy) publicly. The Nginx instance would stand for TLS termination, load balancing and so on. While I can see the benefit of more control with this scenario, again - the additional setup makes me think it might not be worth it, seeing we are a small team with limited hosting experience.
So - my main question would be if the original scenario would sound plausible for a production environment? Any other feedback is of course also highly appreciated if someone can contribute with some feedback.
I'd like to use istio in an environment which hasn't adapted to kubernetes or consul yet.
Unfortunately, it is impossible to make this from out the box without Kubernetes or consul. There are only two options in documentation: Kubernetes or Nomad & Consul. It is required storage so you need to use Kubernetes or Nomad & Consul to place all Istio services. However, you can take the code of Istio and adapt it to your purpose. Istio is an open source product and it allows you any modifications.
At the moment I want to introduce some external firewall solution for kubernetes within the AWS.
I'm using kops to help build the production environment. It’s a pretty good framework
However, I’m new to the AWS network structure and kubernetes is also a new thing for me.
What I want to do is setup a firewall for all requests come to the services within the kubernetes.
And if someone hacked a container within the kubernetes, he or she cannot attack any other containers in the cluster. Any idea or suggestion?
For general Kubernetes restricting actions at a network level can be done (assuming you're on 1.7) via Network Policies.
In addition to that if you're concerned about malicious containers in your cluster, I'd recommend reviewing the CIS Kubernetes standard to make sure you've locked down your cluster as, out of the box there appear to be some concerns with kops.
OK I finally figured out a solution. At the beginning, I try to use Fortinet Gate with kops. But it's not working and causing a lot of issues...it seems that the change of route table will have some conflict with kops. Anyway, it's not a good idea to reconnect subnets and firewall instances regarding kops. Later we switched to Deep security. All good. The only issue is kops doesn't support custom launch config at the moment. I hope this can help anyone who want to setup security env on kubernetes.