I have the following scenario:
The user red make a http request to one of the three services in the namespace1. Somehow in the K8s, it should verify, if the user red has a valid certificate for namespace1 to call services or not. In this case, the user red owns the right certificate for the namespace1, so it allows to call any services within the namespace1. The same rule is also apply for user blue.
But when user red try to call services in the namespace2, then requests should be rejected, because it does not own the right certificat for namespace2.
The question is, it is possible to create namespace certificate in kubernetes. For example, when I have a certificate A, then I can only access namespace1 but not namespace2.
I think Kubernetes Services don’t offer such features. The authentication should be done in an ingress controller (e.g. nginx-ingress). You just deploy two different ones, one per namespace, with different certificate configuration.
Not exactly what you want but it's possible to do per domain.You can use an ingress controller such as ambassador with SNI support.You supply separate TLS certificates for different domains, instead of using a single TLS certificate for all domains.It is designed to be configured on a per-mapping basis, enabling application developers or service owners to individually manage how their service gets exposed over TLS.
Using SNI instead multiple ingress controller deployments is more scalable because multiple load balancers or IPs for those ingress controllers can be avoided.
The problem with SNI is client library and browser support is limited.
Related
We have a custom domain feature, which allows our clients to use our services with their custom DNS records.
For example, our client ACME has a CNAME to ssl.company.com like so login.acme.com -> ssl.company.com. right now we are using a k8s cluster to provide such traffic. On each custom domain, we create an ingress, external service, and a certificate using LetsEncrypt cert-manager.
We started using Cloudflare WAF and they are providing CustomHostname feature which allows us to do the same as our CD cluster but without changing the host header. So
for the example above we get
host: login.acme.com -> login.acme.com
SNI: login.acme.com -> ssl.company.com
The issue is of course how to map a generic k8s ingress to allow such traffic.
when we did the POC we used this method and it worked, but now it stopped. We have also tried default backend and unhosted ingress path.
We are using nginx-ingress controller but migrating to another API gateway like kong.
Any help will be grateful.
If we have two service for example
Front-end (which is consul-connect enabled)
Back-end (which is not consul-connect enabled).
Is it possible to restrict communication between then through intention. Provided we use Consul-Sync from to moved k8s service into consul catalog. Then back-end which is not consul-connect enabled will show in intention. I tried setting deny between Front-end -> Back-end. If not working Front-end is hitting Back-end. I am missing something Or its like Authorization can only happen between two consul-connect enabled service
This question was recently answered in https://stackoverflow.com/a/68432317/12384224.
Consul intentions are authorization polices that allow you to control access between applications within a service mesh. You must use a sidecar proxy, or natively integrate your application with the mesh, in order to use intentions. They are not applicable if you are only using Consul for service discovery, or your application is not part of the service mesh.
I am using ISTIO for service mesh in Azure kubernetes. I have configured private DNS to setup the FQDN. Currently the application is accessible over http protocol(eg: http://myapp.contoso.com) and I would like to be secured with https protocol(eg: https://myapp.contoso.com).
I know I have to change the service port to 443 to support https protocol however how/where do I install the SSL certificate for the application (eg: https://myapp.contoso.com)? Is there anything else to be done as well?
That will depend on where do you want the SSL termination to happen, if you want that to happen inside the Azure kubernetes network, then you can do SSL termination at ingress layer.
Or otherwise you can also do the termination at application gateway layer of Azure ( if you want to avail this service from azure, the redirection from http to https, basic firewall features and adding the pfx certificates at the listeners can be done), ingress can also take care of these things although.
You can install the let's encrypt certificates by using this helm chart and for further steps you can follow this stack overflow link, it shall help you in creating configurations for Istio, ppl have used this solution for Istio as well before
I found the answer here Securing Your Istio Ingress Gateway with HTTPS
There is istio documentation about that.
Is it possible to give a application load balancer on AWS a SSL certificate, allowing allowing only HTTPS connections, if I don't want to use a custom domain?
Currently developing some internal dashboard applications, so have no need/want for a domain name attached to them.
I can only dig up info and tutorials of creating to a certificate in Cloudformation, when wanting to add a domain forwarding to the LB.
The SSL certificate has to have a valid DNS name associated with it in order to work. You need to request a certificate via ACM and then attach that to the ELB. You can configure the ELB to only have an HTTPS listener to force secure communication.
Probably not.
It's not generally kosher to issue an SSL certificate to an IP address, and since all *.compute.amazonaws.com style DNS names are floating and could be reassigned at any moment, they damn well won't issue one for them either. (Same stands for Let's Encrypt, by the way: you have to have a DNS name not issued by a provider.)
Just give your internal service a DNS name, be it something like mydashboard.internal.mycompany.com or whatever; it'll be easier to access, too.
All the documentation for Service Fabric mentions that for a production cluster you should use an X509 certificate from a trusted CA with the common name of the cluster address. The problem is I can't find any documentation on the process of obtaining the certificate. As far as I can tell for creating a certificate you need to prove you are who you say you are and to do so you either need to own the domain or expose some sort of file on the specified address.
The problem is that the url of the cluster is on a domain owned by Microsoft and my cluster is not exposed to the outside world as a website. Am I missing something? Do I have to create a web service and expose it in order to just create a certificate?
You can use any a free solution like Letsencrypt, for this it's not required to own the domain (specifically; control the DNS records). They also provide the option to respond to a HTTP based challenge, as proof of control.
To kick off the process, the agent asks the Let’s Encrypt CA what it
needs to do in order to prove that it controls example.com. The Let’s
Encrypt CA will look at the domain name being requested and issue one
or more sets of challenges. These are different ways that the agent
can prove control of the domain. For example, the CA might give the
agent a choice of either: Provisioning a DNS record under example.com,
or Provisioning an HTTP resource under a well-known URI on
https://example.com/
An easy way to get started with Letsencrypt is by using CertBot.
This needs to run on the domain, so it can respond to the HTTP challenge, which results in the issuing of a certificate for your specific cluster endpoint.
Maybe this sample project helps.