Multiple sub-domains with one path

Instead of using URLs to make different applications accessible, some Ingress resource use sub-domains. So if you have an application configured this way, your .yaml file would look like below: instead of having one host and multiple path, now we have multiple host, where each host represents a sub-domain and the single path redirects the request to the service. For a secure connection, a certificate, and therefore a secret, is required for each host, following the procedure already seen in Configuring TLS certificate.

cafe-ingress.yaml (sub-domain) 
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  name: <name>
  namespace: <namespace>
spec:
  tls:
  - hosts:
    - <subdomain1>.<host>
    secretName: <secret1>
  - hosts:
    - <subdomain2>.<host>
    secretName: <secret2>
  rules:
  - host: <subdomain1>.<host>
    http:
      paths:
      - path: /
        backend:
          serviceName: <service1>
          servicePort: <port1>
  - host: <subdomain2>.<host>
    http:
      paths:
      - path: /
        backend:
          serviceName: <service2>
          servicePort: <port2>

By connecting to your browser you can enter, for istance, values such as coffee.cafe.example.com or tea.cafe.example.com in the address bar.

Learn more about the tls.crt and tls.key keys

You may have noticed the particular wording "base64_encoded" inside the cafe-secret.yaml. In fact, it is necessary to insert the keys with a certain coding. We take our two keys, obtained with the certificate, and apply the following command

Convert "x509 format base64 decoded" to "x509 format base64 encoded"
$ base64 -w 0 cafe.example.com.pem
LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUhDakNDQlBLZ0F3SUJBZ0lRR0J6emlZVDR0V3BpT...
$ base64 -w 0 cafe.example.com.key
LS0tLS1CRUdJTiBSU0EgUFJJVkFURSBLRVktLS0tLQpNSUlFcEFJQkFBS0NBUUVBdjFyQzdvWVh3YU5yc...

We just have to paste the output of the .pem file into the tls.crt field and the output of the .key file into the tls.key field.

Create an Ingress with Basic Authentication

Authentication is not enabled by default for kubectl and Helm installations. In these steps, you’ll learn how to create an Ingress with basic authentication using annotations for the nginx ingress controller. Let's start by creating a basic auth file auth (it’s important the file generated is named auth, otherwise the Ingress returns a 503)

auth 
$ USER=<USERNAME>; PASSWORD=<PASSWORD>; echo "${USER}:$(openssl passwd -stdin -apr1 <<< ${PASSWORD})" >> auth
# For instance
$ USER=foo; PASSWORD=bar; echo "${USER}:$(openssl passwd -stdin -apr1 <<< ${PASSWORD})" >> auth
$ cat auth
foo:$apr1$FnyKCYKb$6IP2C45fZxMcoLwkOwf7k0

Then, create a secret

Create secret 
$ kubectl -n <namespace> create secret generic basic-auth --from-file=auth
secret/basic-auth created

Finally, add the following annotations in the ingress resource manifest above. In this way, when you connect via browser, a pop-up will appear, in which you can enter your previously chosen user and password.

Add annotations 
metadata:
  annotations:
    # type of authentication
    nginx.ingress.kubernetes.io/auth-type: basic
    # prevent the controller from redirecting (308) to HTTPS
    nginx.ingress.kubernetes.io/ssl-redirect: 'false'
    # name of the secret that contains the user/password definitions
    nginx.ingress.kubernetes.io/auth-secret: basic-auth
    # message to display with an appropriate context why the authentication is required
    nginx.ingress.kubernetes.io/auth-realm: 'Authentication Required '
    # custom max body size for file uploading like backing image uploading
    nginx.ingress.kubernetes.io/proxy-body-size: 10000m
  • No labels