我有两个kubernetes环境,它们使用入口作为代理重定向请求以服务静态(前端)和后端rest服务。
在其中一个环境中,这样的请求可以由两个主机URL访问(一个主机配置了tls cert secret),在另一个环境中,我没有配置任何tls secret,只能由一个主机URL访问
在第一个环境中(只有一个主机,没有TLS机密),我有以下几点:
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
annotations:
nginx.ingress.kubernetes.io/proxy-connect-timeout: "70"
nginx.ingress.kubernetes.io/proxy-read-timeout: "1000"
nginx.ingress.kubernetes.io/proxy-send-timeout: "1000"
nginx.ingress.kubernetes.io/rewrite-target: /$1
creationTimestamp: "XXXX"
generation: 9
labels:
app: myapp
chart: myapp-0.1.0
heritage: Helm
release: myapp-ingress
name: myapp-ingress
namespace: myapp-namespace
resourceVersion: "25745018"
selfLink: /apis/extensions/v1beta1/namespaces/my-app-namespace/ingresses/my-app-ingress
uid: 34c3d902-1517
spec:
rules:
- host: hostOne
http:
paths:
- backend:
serviceName: myapp-front
servicePort: 8080
path: /(.*)
- backend:
serviceName: myapp-backend
servicePort: 8080
path: /myappapi/(.+)
tls:
- hosts:
- hostOne
status:
loadBalancer:
ingress:
- {}
在这个例子中,我可以通过HTTP完美地发出请求,一切正常。对于HTTPS请求,我得到了一个SSLExcepcion,因为客户端中没有安装证书(这很正常,很明显)
在第二个集群中,我有TLS secret和两个主机URL:
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
annotations:
nginx.ingress.kubernetes.io/proxy-connect-timeout: "70"
nginx.ingress.kubernetes.io/proxy-read-timeout: "1000"
nginx.ingress.kubernetes.io/proxy-send-timeout: "1000"
nginx.ingress.kubernetes.io/rewrite-target: /$1
creationTimestamp: "XXXX"
generation: 9
labels:
app: myapp
chart: myapp-0.1.0
heritage: Helm
release: myapp-ingress
name: myapp-ingress
namespace: myapp-namespace
resourceVersion: "25745018"
selfLink: /apis/extensions/v1beta1/namespaces/my-app-namespace/ingresses/my-app-ingress
uid: 34c3d902-1517
spec:
rules:
- host: hostOne
http:
paths:
- backend:
serviceName: myapp-front
servicePort: 8080
path: /(.*)
- backend:
serviceName: myapp-backend
servicePort: 8080
path: /myappapi/(.+)
- host: hostTwo
http:
paths:
- backend:
serviceName: myapp-front
servicePort: 8080
path: /(.*)
- backend:
serviceName: myapp-backend
servicePort: 8080
path: /myappapi/(.+)
tls:
- hosts:
- hostTwo
secretName: tlsSecret
- hosts:
- hostOne
status:
loadBalancer:
ingress:
- {}
在这种情况下,当使用HTTP进行请求时,我得到一个803错误,在两个URL(hostOne和hostTwo)中重定向到HTTPS
我想在仅对hostTwo使用http时进行重定向,hostTwo配置了证书和TLS机密。
为什么在响应http重定向时会出现入口,而在第一种情况下不会?我应该改变什么?
当我用RestTemplate将请求发送到https时,我得到一个SSLException:
2020-05-08 12:57:05,586 ERROR class=ExceptionHandler Received fatal alert: handshake_failure; nested exception is javax.net.ssl.SSLHandshakeException: Received fatal alert: handshake_failure
我尝试安装cert和ad TLS1.2,如下所述:Spring RestTemplate:SSL握手失败
但它不起作用,我不能用http发送请求,只是为了检查服务的代码是否良好。
我找到了。https://kubernetes.github.io/ingress-nginx/user-guide/nginx-configuration/annotations/
只需添加nginx.ingres.kubernetes。io/force ssl redirect:“false”,因为默认值为true@nischay,您的解决方案不起作用,因为在第一个入口中,应该需要添加nginx.ingres.kubernetes。io/force ssl redirect:“false”,拆分入口比添加注释更复杂,无论如何,非常感谢。
我建议您有两个单独的入口对象。一个用于SSL主机,另一个用于非SSL主机。请检查以下2个入口物体。
对于HostOne-不需要重定向的地方
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
annotations:
nginx.ingress.kubernetes.io/proxy-connect-timeout: "70"
nginx.ingress.kubernetes.io/proxy-read-timeout: "1000"
nginx.ingress.kubernetes.io/proxy-send-timeout: "1000"
nginx.ingress.kubernetes.io/rewrite-target: /$1
generation: 9
labels:
app: myapp
chart: myapp-0.1.0
heritage: Helm
release: myapp-ingress
name: myapp-ingress-non-ssl
namespace: myapp-namespace
spec:
rules:
- host: hostOne
http:
paths:
- backend:
serviceName: myapp-front
servicePort: 8080
path: /(.*)
- backend:
serviceName: myapp-backend
servicePort: 8080
path: /myappapi/(.+)
tls:
- hosts:
- hostOne
status:
loadBalancer:
ingress:
- {}
对于HostTwo-需要重定向的地方#添加了重定向注释
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
annotations:
nginx.ingress.kubernetes.io/proxy-connect-timeout: "70"
nginx.ingress.kubernetes.io/proxy-read-timeout: "1000"
nginx.ingress.kubernetes.io/proxy-send-timeout: "1000"
nginx.ingress.kubernetes.io/rewrite-target: /$1
nginx.ingress.kubernetes.io/force-ssl-redirect: "true"
generation: 9
labels:
app: myapp
chart: myapp-0.1.0
heritage: Helm
release: myapp-ingress
name: myapp-ingress-ssl
namespace: myapp-namespace
spec:
rules:
- host: hostTwo
http:
paths:
- backend:
serviceName: myapp-front
servicePort: 8080
path: /(.*)
- backend:
serviceName: myapp-backend
servicePort: 8080
path: /myappapi/(.+)
tls:
- hosts:
- hostTwo
secretName: tlsSecret
status:
loadBalancer:
ingress:
- {}
我正在尝试为应用程序完成一项非常常见的任务: 分配证书并使用TLS/HTTPS对其进行保护。 我花了将近一天的时间搜索留档,尝试多种不同的策略来让它发挥作用,但没有什么对我有用。 最初,我使用Helm在EKS上设置nginx ingress,方法如下:https://github.com/nginxinc/kubernetes-ingress.我尝试使用以下配置使示例应用程序工作(cafe): 入
我知道10.254.0.1:443实际上提供来自主节点(端口6443上的api)(192.168.0.200)的证书,但如何解析,10.254.0.1提供其有效证书。 以下是clusterip API的描述:[root@master01 dns]#kubectl description service kubernetes namespace:default labels:component=ap
我有一个具有两个路径的角色的入口: SEO部署是正确的: 它开始正常工作。我找不到一个合理的动机支持这种行为。
我使用nginx入口控制器在GKE上设置了一个新的kubernetes集群。TLS不起作用,它在使用假证书。 有很多配置细节,所以我做了一个回购https://github.com/jobevers/test_ssl_ingress 简而言之,步骤是 创建一个没有GKE负载均衡器的新集群 用我的密钥和证书创建一个tls秘密 创建一个nginx入口部署/pod 创建入口控制器 nginx-ingre
互联网上的大多数Web应用程序经常将用户重定向并转发到其他页面或其他外部网站。但是,如果不验证这些页面的可信度,黑客可以将受害者重定向到网络钓鱼或恶意软件站点,或者使用转发来访问未经授权的页面。 让我们来了解这个漏洞的威胁代理,攻击向量,安全弱点,技术影响和业务影响。 威胁代理 - 检测发现未经检查的重定向很容易。查找可以设置完整URL的重定向。未经检查的标头更难,因为他们瞄准内部网页。 攻击者的