I have a domain foobar. When I started my project, I knew I would have my webserver handling traffic for foobar.com. Also, I plan on having an elasticsearch server I wanted running at es.foobar.com. I purchased my domain at GoDaddy and I (maybe prematurely) purchased a single site certificate for foobar.com. I can't change this certificate to a wildcard cert. I would have to purchase a new one. I have my DNS record routing traffic for that simple URL. I'm managing everything using Kubernetes.
Questions:
Is it possible to use my simple single-site certificate for the main site and subdomains like my elasticsearch server or do I need to purchase another single-site certificate specifically for the elasticsearch server? I checked earlier and GoDaddy wants $350 for the multisite one.
ElasticSearch complicates this somewhat since if it's being accessed at es.foobar.com and the cert is for foobar.com it's going to reject any requests, right? Elasticsearch needs a cert in order to have solid security.
Is it possible to use my simple single-site certificate for the main site and subdomains?
To achieve your goal, you can use Name based virtual hosting ingress, since most likely your webserver foobar.com and elasticsearch es.foobar.com work on different ports and will be available under the same IP.
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: name-virtual-host-ingress
spec:
rules:
- host: foobar.com
http:
paths:
- pathType: Prefix
path: "/"
backend:
service:
name: webserver
port:
number: 80
- host: es.foobar.com
http:
paths:
- pathType: Prefix
path: "/"
backend:
service:
name: elastic
port:
number: 9200-9300 #http.port parametr in elastic config
It can also be implemented using TLS private key and certificate and and creating a file for TLS. This is possible for just one level, like *.foobar.com.
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: name-virtual-host-ingress
spec:
tls:
- hosts:
- foobar.com
- es.foobar.com
secretName: "foobar-secret-tls"
rules:
- host: foobar.com
http:
paths:
- pathType: Prefix
path: "/"
backend:
service:
name: webserver
port:
number: 80
- host: es.foobar.com
http:
paths:
- pathType: Prefix
path: "/"
backend:
service:
name: elastic
port:
number: 9200-9300 #http.port parametr in elastic config
Either you need to get a wildcard or separate certificate for another domain.
Related
I am trying to set up authentication with Okta for elastic stack on google cloud. The link from OKTA has the first step to route the cluster address through a certain endpoint and path as shown here
Well, I have an ingress shown thus:
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: kibana-ingress
annotations:
kubernetes.io/ingress.class: "gce"
spec:
tls:
- hosts:
- x.x.x.net
rules:
- host: x.x.x.net
http:
paths:
- path: /api/security/v1/saml
pathType: Prefix
backend:
service:
name: kibana-kibana
port:
number: 5601
But every time, I tried to check the hosts from the browser with the path identified as well, it gives an error page as shown thus:
{"statusCode":404,"error":"Not Found","message":"Not Found"}
WHat could possibly cause this that I cannot access the hosts from my browser meanwhile if I remove the path, the dashboard is accessible.
Thanks
I use jenkins-x to deploy front-end and back-end projects, and I want to use the same url in ingress with different paths.
The frontend uses mysite.com, and the backend uses mysite.com/api. At first, I wanted to directly modify "charts/my-project/template/ingress" to achieve the goal, but when the backend was deployed to gke, he did not Use the correct address, but use the default address of gke, and generate two addresses like .., ../api, I don’t Understand why this happens, is there any good way to solve this problem?
spec:
rules:
- host: mysite.com
http:
paths:
- path: /api
backend:
serviceName: {{ .Values.service.name }}
servicePort: 8080
You can set your frontend and your backend on the same domain like this:
spec:
rules:
- host: mysite.com
http:
paths:
- backend:
serviceName: <your-frontend-service-name>
servicePort: 80
path: /
- backend:
serviceName: <your-backend-service-name>
servicePort: 8080
path: /api
Learning k8s + istio here. I've setup a 2 nodes + 1 master cluster with kops. I have Istio as ingress controller. I'm trying to set up OIDC Auth for a dummy nginx service. I'm hitting a super weird bug I have no idea where it's coming from.
So, I have a
Keycloak service
Nginx service
The keycloak service runs on keycloak.example.com
The nginx service runs on example.com
There is a Classic ELB on AWS to serve that.
There are Route53 DNS records for
ALIAS example.com dualstack.awdoijawdij.amazonaws.com
ALIAS keycloak.example.com dualstack.awdoijawdij.amazonaws.com
When I was setting up the keycloak service, and there was only that service, I had no problem. But when I added the dummy nginx service, I started getting this.
I would use firefox to go to keycloak.example.com, and get a 404. If I do a hard refresh, then the page loads.
Then I would go to example.com, and would get a 404. If I do a hard refresh, then the page loads.
If I do a hard refresh on one page, then when I go to the other page, I will have to do a hard reload or I get a 404. It's like some DNS entry is toggling between these two things whenever I do the hard refresh. I have no idea on how to debug this.
If I
wget -O- example.com I have a 301 redirect to https://example.com as expected
wget -O- https://example.com I have a 200 OK as expected
wget -O- keycloak.example.com I have a 301 redirect to https://keycloak.example.com as expected
wget -O- https://keycloak.example.com I have a 200 OK as expected
Then everything is fine. Seems like the problem only occurs in the browser.
I tried opening the pages in Incognito mode, but the problem persists.
Can someone help me in debugging this?
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deployment
labels:
app: nginx
spec:
replicas: 2
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:latest
ports:
- containerPort: 80
---
apiVersion: v1
kind: Service
metadata:
name: nginx
spec:
ports:
- port: 80
name: http
protocol: TCP
selector:
app: nginx
---
apiVersion: networking.istio.io/v1beta1
kind: Gateway
metadata:
name: nginx-gateway
spec:
selector:
istio: ingressgateway
servers:
- port:
number: 80
name: http
protocol: HTTP
tls:
httpsRedirect: true
hosts:
- "example.com"
- port:
number: 443
name: https
protocol: HTTPS
tls:
mode: SIMPLE
credentialName: ingress-cert
hosts:
- "example.com"
---
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
name: nginx
spec:
hosts:
- "example.com"
gateways:
- nginx-gateway
http:
- route:
- destination:
port:
number: 80
host: nginx
---
apiVersion: networking.istio.io/v1beta1
kind: Gateway
metadata:
name: keycloak-gateway
spec:
selector:
istio: ingressgateway
servers:
- port:
number: 80
name: http
protocol: HTTP
tls:
httpsRedirect: true
hosts:
- "keycloak.example.com"
- port:
number: 443
name: https
protocol: HTTPS
tls:
mode: SIMPLE
credentialName: ingress-cert
hosts:
- "keycloak.example.com"
---
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
name: keycloak
spec:
hosts:
- "keycloak.example.com"
gateways:
- keycloak-gateway
http:
- route:
- destination:
port:
number: 80
host: keycloak-http
The problem was that I was using the same certificate for both Gateways, hence resulting in keeping the same tcp connection for both services.
There is a discussion about it here https://github.com/istio/istio/issues/9429
By using a different certificate for both Gateway ports, the problem disappears
I currently have an AKS cluster setup running a GraphQL server and normal nginx ingress. We're attempting to onboard GraphQL Subscriptions, which utilize Websockets. The URL that GraphQL uses for websockets is the same url that is used for GraphQL queries. We've tried adding proxy configuration to enable websocket ingress, but the connection is never established. Running the GraphQL server without Kubernetes is successful, so we think there is something kubernetes-specific going on here...has anyone had any success doing this? Relevant ingress config below
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
name: web-ingress
namespace: web
annotations:
kubernetes.io/ingress.class: nginx
certmanager.k8s.io/cluster-issuer: letsencrypt
nginx.ingress.kubernetes.io/use-regex: "true"
nginx.ingress.kubernetes.io/affinity: cookie
nginx.ingress.kubernetes.io/proxy-send-timeout: "3600"
nginx.ingress.kubernetes.io/proxy-read-timeout: "3600"
nginx.ingress.kubernetes.io/proxy-connect-timeout: "30"
nginx.ingress.kubernetes.io/configuration-snippet: |
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
spec:
tls:
- hosts:
- my.host
- my-api.host
secretName: tls-secret
rules:
- host: my.host
http:
paths:
- path: /graphql
backend:
serviceName: webapi
servicePort: 80
- path: /(.*)
backend:
serviceName: website
servicePort: 80
- host: my-api.host
http:
paths:
- backend:
serviceName: webapi
servicePort: 80
path: /(.*)
You might want to start from a bit less complex config like this:
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
name: web-ingress
namespace: web
annotations:
kubernetes.io/ingress.class: nginx
certmanager.k8s.io/cluster-issuer: letsencrypt
ingress.kubernetes.io/ssl-redirect: "true"
kubernetes.io/tls-acme: "true"
spec:
tls:
- hosts:
- my.host
secretName: tls-secret
rules:
- host: my.host
http:
paths:
- path: /
backend:
serviceName: website
servicePort: 80
- path: /graphql
backend:
serviceName: webapi
servicePort: 80
I switched the config to one endpoint instead of two. Removed some config since NGINX handles websockets out of the box. I removed regexp. I added the tls-acme annotation. And also ssl-redirect. In summary I just made it a bit less complex. Get this up and running first and then start applying advanced config stuff like the timeouts you did.
Happy to hear any feedback on this!
I have a Google Kubernetes Engine with a spring boot application that has a public service endpoint. But I would like to change the endpoint from http://... to a secure https://... .
For example:
https://xx.xxx.xx.xxxx:8085/getAllStudent instead of http://xx.xxx.xx.xxxx:8085/getAllStudent
How can i solve this?
It looks like you are using then NodePort type of your services. If you want to accept HTTPS over this port your service behind it simply needs to open a HTTPS server instead of an HTTP server.
Using NodePort like this is not a recommend way but rather use the proper Ingress functionality in Kubernetes in order to expose a service over a host name. Ingress then supports supplying an SSL certificate that can be used to encrypt traffic over HTTPS.
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
name: tls-example-ingress
spec:
tls:
- hosts:
- sslexample.foo.com
secretName: testsecret-tls
rules:
- host: sslexample.foo.com
http:
paths:
- path: /
backend:
serviceName: service1
servicePort: 80