k8s nginx ingress配置TLS

在没有配置任何nginx下,k8s的nginx默认只支持TLS1.2,不支持TLS1.0和TLS1.1

默认的 nginx-config(部分可能叫 nginx-configuration)的配置如下:

apiVersion: v1
data:
  allow-backend-server-header: ‘true‘
  enable-underscores-in-headers: ‘true‘
  generate-request-id: ‘true‘
  http-redirect-code: ‘301‘
  ignore-invalid-headers: ‘true‘
  max-worker-connections: ‘65536‘
  proxy-body-size: 20m
  proxy-connect-timeout: ‘10‘
  reuse-port: ‘true‘
  server-tokens: ‘false‘
  ssl-redirect: ‘false‘
  worker-cpu-affinity: auto
kind: ConfigMap
metadata:
  annotations:
    kubectl.kubernetes.io/last-applied-configuration: >
      {"apiVersion":"v1","data":{"allow-backend-server-header":"true","enable-underscores-in-headers":"true","generate-request-id":"true","ignore-invalid-headers":"true","max-worker-connections":"65536","proxy-body-size":"20m","proxy-connect-timeout":"10","reuse-port":"true","server-tokens":"false","ssl-redirect":"false","worker-cpu-affinity":"auto"},"kind":"ConfigMap","metadata":{"annotations":{},"labels":{"app":"ingress-nginx"},"name":"nginx-configuration","namespace":"kube-system"}}
  labels:
    app: ingress-nginx
  name: nginx-configuration
  namespace: kube-system
  selfLink: /api/v1/namespaces/kube-system/configmaps/nginx-configuration
  

看了下官方的文档,如果需要支持TLS1.0和TLS1.1需要改下 nginx-config 同时重启下容器即可

To provide the most secure baseline configuration possible,

nginx-ingress defaults to using TLS 1.2 only and a secure set of TLS ciphers.


The default configuration, though secure, does not support some older browsers and operating systems.

For instance, TLS 1.1+ is only enabled by default from Android 5.0 on. At the time of writing, May 2018, approximately 15% of Android devices are not compatible with nginx-ingress‘s default configuration.

To change this default behavior, use a ConfigMap.

A sample ConfigMap fragment to allow these older clients to connect could look something like the following:
kind: ConfigMap
apiVersion: v1
metadata:
  name: nginx-config
data:
  ssl-ciphers: "ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA"
  ssl-protocols: "TLSv1 TLSv1.1 TLSv1.2"

为了避免影响到之前的配置,切勿直接复制这个yaml配置替换你的配置!!!

在你原有的配置上加上 ssl-ciphers 和 ssl-protocols 配置即可

apiVersion: v1
data:
  allow-backend-server-header: ‘true‘
  enable-underscores-in-headers: ‘true‘
  generate-request-id: ‘true‘
  http-redirect-code: ‘301‘
  ignore-invalid-headers: ‘true‘
  max-worker-connections: ‘65536‘
  proxy-body-size: 20m
  proxy-connect-timeout: ‘10‘
  reuse-port: ‘true‘
  server-tokens: ‘false‘
  ssl-ciphers: >-
    ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA
  ssl-protocols: TLSv1 TLSv1.1 TLSv1.2
  ssl-redirect: ‘false‘
  worker-cpu-affinity: auto
kind: ConfigMap
metadata:
  annotations:
    kubectl.kubernetes.io/last-applied-configuration: >
      {"apiVersion":"v1","data":{"allow-backend-server-header":"true","enable-underscores-in-headers":"true","generate-request-id":"true","ignore-invalid-headers":"true","max-worker-connections":"65536","proxy-body-size":"20m","proxy-connect-timeout":"10","reuse-port":"true","server-tokens":"false","ssl-redirect":"false","worker-cpu-affinity":"auto"},"kind":"ConfigMap","metadata":{"annotations":{},"labels":{"app":"ingress-nginx"},"name":"nginx-configuration","namespace":"kube-system"}}
  labels:
    app: ingress-nginx
  name: nginx-configuration
  namespace: kube-system
  selfLink: /api/v1/namespaces/kube-system/configmaps/nginx-configuration

加上配置之后呢,需要重启下容器 nginx-ingress

参考文档:https://kubernetes.github.io/ingress-nginx/user-guide/tls/#legacy-tls

原文地址:https://www.cnblogs.com/lyc94620/p/11345124.html

时间: 2024-10-08 21:17:13

k8s nginx ingress配置TLS的相关文章

K8s Nginx Ingress 介绍

作者:漠然,原文发布于2017年3月4日,原文链接 一.Ingress 介绍 Kubernetes 暴露服务的方式目前只有三种:LoadBlancer Service.NodePort Service.Ingress:前两种估计都应该很熟悉,具体的可以参考下这篇文章:下面详细的唠一下这个 Ingress . 1.1.Ingress 是个什么玩意 可能从大致印象上 Ingress 就是能利用 Nginx.Haproxy 啥的负载均衡器暴露集群内服务的工具:那么问题来了,集群内服务想要暴露出去面临着

Kubernetes 部署 Nginx Ingress Controller

开始天真地以为只要写一个 ingress 配置文件并部署好就行了. apiVersion: extensions/v1beta1 kind: Ingress metadata: name: cnblogs-ingress spec: rules: - host: q.cnblogs.com http: paths: - backend: serviceName: q-web servicePort: 80 # kubectl apply -f cnblogs-ingress.yaml # kub

同一k8s集群中多nginx ingress controller

同一k8s集群中多nginx ingress controller同一k8s集群中,若有多个项目(对应多个namespace)共用一个nginx ingress controller,因此任意注册到ingress的服务有变更都会导致controller配置重载,当更新频率越来越高时,此controller压力会越来越大,理想的解决方案就是每个namespace对应一个nginx ingress controller,各司其职. NGINX ingress controller提供了ingress

见异思迁:K8s 部署 Nginx Ingress Controller 之 kubernetes/ingress-nginx

前天才发现,区区一个 nginx ingress controller 竟然2个不同的实现.一个叫 kubernetes/ingress-nginx ,是由 kubernetes 社区维护的,对应的容器镜像是 quay.io/kubernetes-ingress-controller/nginx-ingress-controller ,namespace 是 ingress-nginx :一个叫 nginxinc/kubernetes-ingress ,是由 nginx 公司与社区共同维护的,对

SSL/TLS深度解析--在 Nginx上配置 HSTS、CSP 与其他

在 Nginx 上配置 HSTS HTTP响应中包含 Strict-Transport-Security 头实现网站HSTS,像下面这样配置: Strict-Transport-Security: max-age=31536000; includeSubDomains; preload,就实现了HSTS,即-- HTTP Strict Transport Security,HTTP严格传输安全.假设TLS连接没有错误,兼容的浏览器将会在 max-age 参数指定的保留期内激活HSTS. 一旦站点

[系统集成] 用 Kubernetes Nginx Ingress 实现 HTTP 服务发布与负载均衡

用户在 Kubernetes 上部署的服务一般运行于私有网络,Pod和Service 提供了 hostPort,NodePort等参数用于暴露这些服务端口到K8S节点上,供使用者访问.这样的方法有明显缺点: 1)容易占用过多的主机端口: 2)服务端口暴露到多台主机会增加防火墙和安全配置的难度 3)默认的hostPort,NodePort方式没有负载均衡的作用 K8S的 Ingress 资源提供了另一种服务暴露的方法,它可以获取各个服务的状态,传递给nginx等工具进行配置修改.重新加载等工作,实

Kubernetes 使用 ingress 配置 https 集群(十五)

目录 一.背景 1.1 需求 1.2 Ingress 1.3 环境介绍 二.安装部署 2.1.创建后端 Pod 应用 2.2 创建后端 Pod Service 2.3.创建 ingress 资源 2.4.为 Nginx Pod 创建 Service 三.升级为 https 3.1 首先我们要制作证书 3.2.创建 secret 资源 3.3 更改 ingress 资源 3.4 浏览器访问验证 四.ingress 资源介绍 4.1.通过访问路径过滤 4.2.基于名称解析的虚拟主机 4.3.http

k8s的ingress使用

ingress 可以配置一个入口来提供k8s上service从外部来访问的url.负载平衡流量.终止SSL和提供基于名称的虚拟主机. 配置ingress的yaml: 要求域名解析无误 要求service对应的pod正常 一.test1.domain.com   -->  service1:8080 apiVersion: extensions/v1beta1 kind: Ingress metadata: name: test-ingress namespace: test spec: rule

k8s之ingress方向代理pod

Ingress controller Nginx -->后来改造 Traefik -->也是用于微服务 Envoy  -->微服务 Ingress资源 目前使用0.17.1版本ingress-nginx ingress定义  后端pod发生变化,service就变化,service变化ingress就发生变化,ingress再把变化注入到ingress-nginx-controller主容器的nginx的backend反向代理配置且重载配置文件使之能够动态改变反向代理配置 kubectl