Following on from my last post where i use self signed certificates this post discusses how to use a 'proper' cert to do this properly and get rid of all the warnings. I did all of this in an AKS environment in Azure but the steps would be exactly the same for self hosted kubernetes or any other platform like EKS
The first step to doing this is to get a proper private key, generate a certificate signing request from that and then get the proper key back from your cert provider - so lets go through the steps for that.
This step can be run on any machine with openssl installed - it doesn't have to be done anywhere near the cluster.
The first step is to create a small config file to feed into the command line - annoying it does seem possible to just do this via flags to the command you have to have a config file or build something ugly with command redirection - its simpler in my view to just do it with a config file.
IN my case i create a file called san.conf which had the following config
[ req ]
default_bits = 2048
distinguished_name = req_distinguished_name
req_extensions = req_ext
prompt = no
[ req_distinguished_name ]
C = DE
CN = shortnameiwanttogivemysite
[req_ext]
subjectAltName = @alt_names
[alt_names]
DNS.1 = fullyqualifieddomainnameformysite
You should just be able to use this directly for you site just replace the 2 lines in orange - for example they may be
CN = widgets
DNS1 = widgets.contoso.com
(whats the deal with this contoso.com that MS use in all their demos anyway????)
once you have that file you can run the following openssl command line to generate the private key and the certificate signing request in one step
openssl req -config san.conf -newkey rsa:2048 -keyout widgets.key -out widgets.req -nodes
note the file names can be anything you like - i personally find it clearer to name them .key (for the private key) , .req (for the cert signing request) and .cert (for the actual cert later on)
The last parameter -nodes disables having a password in the private key which makes the late steps easier - you may want to have this though in your environment in which case you'll need to figure out how to deal with that in the later steps......
once i have my .req file i can open that in any text editor and paste the text into my friendly cert provider (whoever that may be) - the format will be something like
-----BEGIN CERTIFICATE REQUEST-----
blahblahblah
-----END CERTIFICATE REQUEST-----
The provider will then generate a cert for you.
Now in my case there were loads of options to choose from to download this cert - i chose the following one (this will vary by supplier of course)
OK - now I've done the cert part the file i actually need to make use of are the private key (.key) and the certificate chain (.cert).
Now i just need to associate them with my ingress.
The first step of that is to create a secret containing the 2 files - this is a simple process in kubernetes - i just run the following code:
kubectl create secret tls widgetsecret --key widget.key --cert widget.cert
There is then a secret created (in the default namespace as nothing as specified) - this secret contains the key pair needed to make the https ingress work.
Now all i need to do is associate this secret to the ingress.
to do this i just add this line in orange
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
name: widget-ingress
annotations:
kubernetes.io/ingress.class: nginx
nginx.ingress.kubernetes.io/ssl-redirect: "false"
spec:
tls:
- hosts:
- widget.contoso.com
secretName: widgetsecret
rules:
- host: widget.contoso.com
http:
paths:
- backend:
serviceName: widgetapp
servicePort: 9000
This creates the link from the ingress to the secret.
And that's it - it just works - its actually simpler than the self signed thing to setup.......
For AKS the key should really be in key vault instead so that should be the next steps for me to make it more secure
Happy ingressing.......
Comments
Post a Comment