一看必会系列:k8s 练习8 ingress https ssl

来源:本站原创 网络技术 超过259 views围观 0条评论

 

k8s ingress-nginx ssl

生成证书
https://github.com/kubernetes/ingress-nginx/blob/master/docs/examples/PREREQUISITES.md

生成证书和key
$ openssl req -x509 -sha256 -nodes -days 365 \
         -newkey rsa:2048 \
         -keyout tls.key \
         -out tls.crt \
         -subj "/CN=nginxsvc/O=nginxsvc"
Generating a 2048 bit RSA private key
…………….+++
…………….+++
writing new private key to ‘tls.key’
—–

命令格式
kubectl create secret tls ${CERT_NAME} –key ${KEY_FILE} –cert ${CERT_FILE}

制作secret,后面在容器里用 tls名字进行挂载
$ kubectl create secret tls tls-secret –key tls.key –cert tls.crt
secret "tls-secret" created  #引号里为名字

使用真实的https证书
[root@k8s-master ssl]# ll
total 16
-rw-r–r– 1 root root 3622 Mar  4 07:17 ccie.wang.crt    -证书
-rw-r–r– 1 root root 1732 Jan 28 16:41 ccie.wang.key    -key
-rw-r–r– 1 root root  308 Apr  2 04:57 ccie.wang.yaml
-rw-r–r– 1 root root 2992 Mar 31 19:38 multi-tls.yaml
[root@k8s-master ssl]# kubectl create secret tls tls.ccie.wang –key ccie.wang.key –cert ccie.wang.crt
secret/tls.ccie.wang created  #生成密文成功

配置ingress service

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: nginx-ccie-wang-test
spec:
  tls:
    – hosts:
        #写成其它host也能行。不知为啥
      – in4ssl.ccie1.wang
      secretName: tls.ccie.wang
  rules:
      #这个host一定要对,这个对应nginx的 server_name
    – host: in4ssl.ccie.wang
      http:
        paths:
        – path: /
          backend:
             #service必须先存在,端口也要存在
            serviceName: frontend-svc
             #启动后会自动开启443端口,不用定义
            servicePort: 80

验证:
进入ingress的pod查看配置
kubectl exec nginx-ingress-controller-7966d94d6c-8prth \
-n ingress-nginx — cat /etc/nginx/nginx.conf > nginx.conf

直接请求https页面,出现如下即正常
[root@k8s-master ssl]# curl -s https://in4ssl.ccie.wang |head -5
<html ng-app="redis">
  <head>
    <title>Guestbook</title>
    <link rel="stylesheet" href="bootstrap.min.css">
    <script src="angular.min.js"></script>
[root@k8s-master ssl]#

直接请求http页面,发现被重定向即为正常
[root@k8s-master ssl]# curl in4ssl.ccie.wang
<html>
<head><title>308 Permanent Redirect</title></head>
<body>
<center><h1>308 Permanent Redirect</h1></center>
<hr><center>nginx/1.15.9</center>
</body>
</html>

 

————–知识扩展

https://kubernetes.github.io/ingress-nginx/user-guide/tls/

TLS Secrets¶
Anytime we reference a TLS secret, we mean a PEM-encoded X.509, RSA (2048) secret.

You can generate a self-signed certificate and private key with:

生成证书
$ openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout ${KEY_FILE} -out ${CERT_FILE} -subj "/CN=${HOST}/O=${HOST}"
Then create the secret in the cluster via:

创建密文
kubectl create secret tls ${CERT_NAME} –key ${KEY_FILE} –cert ${CERT_FILE}
The resulting secret will be of type kubernetes.io/tls.

Default SSL Certificate¶
NGINX provides the option to configure a server as a catch-all with server_name for requests that do not match any of the configured server names. This configuration works without out-of-the-box for HTTP traffic. For HTTPS, a certificate is naturally required.

For this reason the Ingress controller provides the flag –default-ssl-certificate. The secret referred to by this flag contains the default certificate to be used when accessing the catch-all server. If this flag is not provided NGINX will use a self-signed certificate.

For instance, if you have a TLS secret foo-tls in the default namespace, add –default-ssl-certificate=default/foo-tls in the nginx-controller deployment.

SSL Passthrough¶
The –enable-ssl-passthrough flag enables the SSL Passthrough feature, which is disabled by default. This is required to enable passthrough backends in Ingress objects.

Warning

This feature is implemented by intercepting all traffic on the configured HTTPS port (default: 443) and handing it over to a local TCP proxy. This bypasses NGINX completely and introduces a non-negligible performance penalty.

SSL Passthrough leverages SNI and reads the virtual domain from the TLS negotiation, which requires compatible clients. After a connection has been accepted by the TLS listener, it is handled by the controller itself and piped back and forth between the backend and the client.

If there is no hostname matching the requested host name, the request is handed over to NGINX on the configured passthrough proxy port (default: 442), which proxies the request to the default backend.

Note

Unlike HTTP backends, traffic to Passthrough backends is sent to the clusterIP of the backing Service instead of individual Endpoints.

HTTP Strict Transport Security¶
HTTP Strict Transport Security (HSTS) is an opt-in security enhancement specified through the use of a special response header. Once a supported browser receives this header that browser will prevent any communications from being sent over HTTP to the specified domain and will instead send all communications over HTTPS.

HSTS is enabled by default.

To disable this behavior use hsts: "false" in the configuration ConfigMap.

Server-side HTTPS enforcement through redirect¶
By default the controller redirects HTTP clients to the HTTPS port 443 using a 308 Permanent Redirect response if TLS is enabled for that Ingress.

This can be disabled globally using ssl-redirect: "false" in the NGINX config map, or per-Ingress with the nginx.ingress.kubernetes.io/ssl-redirect: "false" annotation in the particular resource.

Tip

When using SSL offloading outside of cluster (e.g. AWS ELB) it may be useful to enforce a redirect to HTTPS even when there is no TLS certificate available. This can be achieved by using the nginx.ingress.kubernetes.io/force-ssl-redirect: "true" annotation in the particular resource.

Automated Certificate Management with Kube-Lego¶
Tip

Kube-Lego has reached end-of-life and is being replaced by cert-manager.

Kube-Lego automatically requests missing or expired certificates from Let’s Encrypt by monitoring ingress resources and their referenced secrets.

To enable this for an ingress resource you have to add an annotation:

kubectl annotate ing ingress-demo kubernetes.io/tls-acme="true"
To setup Kube-Lego you can take a look at this full example. The first version to fully support Kube-Lego is Nginx Ingress controller 0.8.

Default TLS Version and Ciphers¶
To provide the most secure baseline configuration possible,

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

Legacy TLS¶
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"

文章出自:CCIE那点事 http://www.jdccie.com/ 版权所有。本站文章除注明出处外,皆为作者原创文章,可自由引用,但请注明来源。 禁止全文转载。
本文链接:http://www.jdccie.com/?p=4130转载请注明转自CCIE那点事
如果喜欢:点此订阅本站
  • 相关文章
  • 为您推荐
  • 各种观点

暂时还木有人评论,坐等沙发!
发表评论

您必须 [ 登录 ] 才能发表留言!