Single Sign-On with Azure AD

HTTPs has become a necessity for any public-facing website, given phishing attacks. Luckily, with the LetsEncrypt service and helpers in Kubernetes, it is very easy to set verified SSL certificates. In this chapter, we will see how to set up Ingress services and certificate managers to interface with LetsEncrypt.

Different approaches for authentication to the guestbook app will be explored in this chapter. We will look at the oauth2_proxy side car for adding authentication to the sample guest app using Azure AD. The reader will be able to secure apps with no built-in authentication easily. The authentication scheme can be extended to use GitHub, Google, GitLab, LinkedIn, or Facebook.

The following topics will be covered in this chapter:

• Authentication and common authentication providers
• Authentication versus authorization (AuthN versus AuthZ)
• Deploying...

Technical requirements

You'll need a modern browser, such as Chrome, Firefox, Safari, or Edge.

You can find the code files for this chapter at https://github.com/PacktPublishing/Hands-On-Kubernetes-on-Azure.

HTTPS support

Obtaining Secure Sockets Layer (SSL) certificates traditionally was an expensive business. If you want to do it cheaply, you could self-sign your certificates, but browsers would complain when opening up your site and identify it as not trusted. The LetsEncrypt service changes all that. You do get some extra benefits with commercial certificate providers, but the certificate issued by LetsEncrypt should be sufficient.

Installing Ingress

Exposing services to the public and routing was "an exercise left to the reader" when Kubernetes started. With the Ingress object, Kubernetes provides a clean way of securely exposing your services. It provides an SSL endpoint and name-based routing. Let's install...

Authentication versus authorization

Authentication (AuthN) is very often mixed up with authorization (AuthZ). It generally takes multiple attempts to understand the difference and we still get confused. The source of confusion is that most people think the authentication provider and the authorization provider are the same. In our WordPress example, WordPress provides the authentication (has the username and password) and authorization (stores the users under admin or user roles, for example). The implementation in the code (at least initially) would be mixing up authentication and authorization also (if (admin) do this; else do that). Even the names can be confusing. OAuth is an authorization protocol, whereas we are using the oauth2_proxy for authentication.

Authentication deals with identity (who are you?), and in general requires a trusted provider (such as Google, GitHub...

Deploying the oauth2_proxy side car

We are going to implement oauth2_proxy from bitly (https://github.com/bitly/oauth2_proxy). We will be following the steps indicated in the documentation for Azure AD (https://docs.microsoft.com/en-us/azure/active-directory/).

First, register an app with Azure AD as shown in the following screenshot:

Next, create a client ID secret by performing the following steps:

1. Select Certificates & secrets and go to New client secret:

2. Add the secret:

3. Click on the Copy icon and save the secret in a safe place:

4. Save the client and the tenant ID:

After creating the client ID secret, we will now launch oauth2_proxy with the following YAML file:

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: oauth2-proxy
  namespace: kube-system
spec:
  replicas: 1
  selector:
    matchLabels:
      app: oauth2-proxy
  template:
    metadata:
      labels...

Summary

In this chapter, we added access control to our guestbook application without actually changing the source code of it by using the sidecar pattern in Kubernetes (https://kubernetes.io/blog/2015/06/the-distributed-system-toolkit-patterns/). We started by getting the Kubernetes ingress objects to redirect to a https://.... secured site. Then we installed the certificate manager that interfaces with the LetsEncrypt API to request a certificate for the domain name you specified in the next steps. We leveraged a Certificate Issuer, which gets the certificate from LetsEncrypt, and created the actual certificate for a given Fully-Qualified Domain Name (FQDN). We then created an Ingress to the service with the certificate we'd created. Finally, we jumped into authentication (AuthN) and authorization (AuthZ), and showed you how to leverage AzureAD as an authentication provider...