"Security is not a product, but a process." - Bruce Schneier.

Introduction

Secrets are an important aspect of any application, containing sensitive information such as passwords, API keys, and certificates. Storing and managing secrets securely is crucial to maintaining the overall security of an application. While Kubernetes provides a built-in secrets management solution, it has been deemed least secure due to the way it stores secrets in a base64 encoded format. To address this issue, several key management services have been developed, such as AWS KMS, Azure Key Vault, and Hashicorp Vault, that offer a more secure way of storing secrets. However, the challenge remains on how to pass these secrets to the application securely. In this blog, we will explore three different approaches for securely passing secrets to applications in Kubernetes.

Kubernetes Built-in Secrets

Kubernetes has built-in support for secrets management through the Secrets API. This API allows you to store and manage sensitive information such as passwords, API keys, and TLS certificates in your Kubernetes cluster.

However, it's important to note that the default storage format for Kubernetes secrets is base64-encoded, which provides only a basic level of obfuscation. Anyone with access to the Kubernetes API can easily decode the secret and retrieve the sensitive information.

Additionally, Kubernetes secrets have some limitations, such as a maximum size of 1MB per secret and no built-in support for rotating secrets. As a result, using Kubernetes built-in secrets may not be sufficient for more complex security requirements.

For these reasons, it's recommended to consider other options for storing and managing secrets, such as using external key management services. However, even when using external key management services, it's still important to securely pass the secrets to the application. In the following sections, we'll explore three approaches for doing so.

Key Management Services

One of the best ways to securely store secrets is by using Key Management Services (KMS) provided by cloud providers or third-party vendors. KMS provides a centralized and secure way to manage keys, certificates, and secrets. These services allow for the secure storage of secrets and control over who can access them.

AWS KMS, Azure Key Vault, Google Cloud KMS, and HashiCorp Vault are some of the popular key management services that can be integrated with Kubernetes for secure secret management.

Approach 1 - Volumes

One way to securely pass secrets to your application in Kubernetes is to use volumes. This approach involves storing secrets in an external service, such as a Key Management Service (KMS), and then mounting the secret data into a volume in the pod. The application can then read the secrets from the mounted volume.

However, cloud-native applications generally like to receive secrets via environment variables, rather than from files. To address this, Kubernetes provides a CSI (Container Storage Interface) driver to sync Kubernetes secrets with the external storage provider. Using this driver, we can mount the secret data as a volume and expose it as environment variables to the application.

While this approach allows us to keep secrets secure in an external service, it still requires storing the secret data in Kubernetes secrets, which are stored in base64-encoded format and may not be the most secure option.

Approach 2 - Sidecar Container

Another approach to securely pass secrets to an application in Kubernetes is by using sidecar containers. With this approach, a sidecar container is added to the pod that is responsible for retrieving the secrets from an external service and passing them to the main application container via a shared volume or environment variables.

The sidecar container can be configured to retrieve the secrets from a Key Management Service or any other external service that is responsible for securely storing secrets. The main application container can then read the secrets from the shared volume or environment variables provided by the sidecar container.

As an example, we can use the Vault sidecar container with the official HashiCorp Vault Kubernetes integration. The sidecar container is responsible for retrieving the secrets from Vault, and the main application container can read the secrets from the shared volume or environment variables provided by the sidecar container.

This approach ensures that secrets are never stored in the pod's file system and are only passed securely to the main container.

However, it's important to note that while we are passing secrets securely to the container, if someone gains access to the container, they can access the secrets as well. So, it's important to implement additional security measures such as pod security policies and container runtime security to minimize the risk of unauthorized access to the secrets.

Approach 3 - Secret Injector

Another approach to securely pass secrets to applications in Kubernetes is by using a secret injector. This approach involves using a Kubernetes admission controller to automatically inject secrets into pods at runtime. One popular example of this approach is the Azure Key Vault to Kubernetes (akv2k8s) project. The akv2k8s project retrieves secrets from Azure Key Vault and injects them into pods using Kubernetes mutating webhooks.

When a pod is created or updated, the admission controller intercepts the pod creation request and adds the necessary environment variables and volumes to the pod specification. The environment variables and volumes are then populated with the secret values at runtime, ensuring that the application running inside the pod has access to the secrets.

One of the main advantages of this approach is that the secrets are not even accessible by the container running in the pod. Instead, only the application process running inside the container receives the secrets, which are injected at runtime.

This approach provides an extra layer of security as the secrets are never stored in the pod or container, and access to the secrets is strictly controlled by the Kubernetes API server.

However, it's important to note that the security of the secrets still relies on the security of the external service used. Any security issues or vulnerabilities in the external service can compromise the security of the secrets. It's also important to ensure that the Kubernetes admission controller is configured securely to prevent unauthorized access to the secrets during the injection.

Overall, the secret injector approach can be a powerful tool for securely passing secrets to applications in Kubernetes, and the akv2k8s project is a popular and well-maintained implementation of this approach.

Best Practices

While using Kubernetes for secret management, it is important to follow best practices to ensure the security of your secrets. Here are some best practices that you should consider:

1. Avoid using Kubernetes built-in secrets: As mentioned earlier, Kubernetes built-in secrets are not secure as secret data is stored in base64-encoded format. It is recommended to use a third-party secret management solution like Key Management Services.

2. Use RBAC for secret access control: Kubernetes provides Role-Based Access Control (RBAC) to control access to secrets. You should use RBAC to restrict access to secrets to only the necessary users or services.

3. Use short-lived secrets: Avoid using long-lived secrets, as it increases the risk of unauthorized access. Instead, use short-lived secrets that expire after a certain time.

4. Use secret rotation: Regularly rotate secrets, such as passwords and certificates, to minimize the risk of unauthorized access.

5. Use TLS for communication: Use Transport Layer Security (TLS) to encrypt communication between Kubernetes components and secret management systems.

6. Use encryption for secret data at rest: Encrypt the secret data at rest using encryption tools and techniques.

7. Implement least privilege access: Use the principle of least privilege to grant access to secret management systems, tools, and APIs.

8. Use container image scanning: Use container image scanning to detect and fix vulnerabilities in container images before deploying them to Kubernetes.

By following these best practices, you can ensure the security and confidentiality of your secrets in Kubernetes.

Conclusion

In conclusion, secret management is an essential aspect of Kubernetes application deployment. While Kubernetes provides a built-in secrets management solution, it is not very secure and lacks some important features that are necessary for secure secret management.

Key Management Services such as AWS KMS, Azure Key Vault, and HashiCorp Vault provide a more secure and reliable way of storing secrets. To pass these secrets securely to the application, we explored three approaches: volumes, sidecar containers, and secret injectors. Each approach has its own advantages and limitations, and the choice of approach depends on the specific use case.

In addition to these approaches, there are also some best practices that can be followed for secure secret management, such as minimizing secret access, rotating secrets regularly, and implementing multi-factor authentication.

Overall, secure secret management is critical for the security and integrity of applications running in Kubernetes, and it is important to choose the right approach and follow best practices to ensure that secrets are kept safe and secure.

References

• Kubernetes Documentation on Secrets: https://kubernetes.io/docs/concepts/configuration/secret/

• Kubernetes Secrets Best Practices: https://kubernetes.io/docs/concepts/security/secrets-good-practices/

• Using Azure Key Vault with Kubernetes: https://docs.microsoft.com/en-us/azure/key-vault/general/key-vault-integrate-kubernetes

• Azure Key Vault to Kubernetes (akv2k8s) Project: https://github.com/Azure/akv2k8s

• HashiCorp Vault Kubernetes Integration: https://developer.hashicorp.com/vault/tutorials/kubernetes/kubernetes-sidecar#inject-secrets-into-the-pod

• Google Cloud Secrets Management: https://cloud.google.com/secret-manager

• AWS Secrets Manager: https://aws.amazon.com/secrets-manager/

"Secure your applications, not your network. Verify identity and enforce access controls in the application itself, where they can travel with the application wherever it goes." - John Kindervag, creator of the Zero Trust security model.

Introduction

In today's digital age, securing your applications and services is more critical than ever. One of the essential aspects of application security is authentication and authorization, which ensure that only authorized users have access to resources. Kubernetes is a popular container orchestration platform that is widely used to deploy and manage cloud-native applications. When deploying Kubernetes clusters, it is crucial to ensure that authentication and authorization are properly configured to protect your applications and services. In this article, we will explore the use of the Nginx Plus Ingress Controller with OpenID Connect (OIDC) policy for authentication and authorization in Kubernetes. We will dive into how to configure Nginx Plus Ingress Controller with OIDC policy to authenticate users.

Why OIDC Policy?

In the previous article, we explored how to configure the oauth2 proxy as an external authentication proxy with the Nginx ingress controller. Although this solution can work well, it requires managing the oauth2 proxy instance running in the cluster, including its security patches, and scalability, and relying on community support if anything goes wrong. In production environments, such solutions are not always ideal.

Nginx Plus ingress controller offers various authentication mechanisms out of the box, including OIDC authentication using OIDC policy. In this approach, the Ingress Controller handles authentication logic and session management without relying on an external authentication proxy.

This approach offers two significant advantages. First, we don't have to manage an external authentication proxy like the oauth2 proxy and its security. Second, we can perform authentication and authorization directly at the Nginx ingress controller, saving network traffic generated for each request as requests do not leave the ingress controller. This makes the process more efficient and secure.

How does OIDC Policy work?

When a user tries to access a protected resource, the Nginx Plus Ingress Controller first checks for a session cookie in the request. If a session cookie is present, it verifies the user's session details and returns a successful response, allowing the user to access the resource.

However, if the session cookie is not present, the Nginx Plus Ingress Controller redirects the user to the login page of the configured IdP (such as Google, GitHub, Azure AD, etc.). After the user logs in to the IdP and is redirected back to Ingress Controller's callback URL /_codexch, the Nginx plus ingress controller exchanges the code for user information with the IdP. It then creates a new session for the user using this information and sets a session cookie in the response.

With a valid session cookie, the user can access the requested resource through the Nginx ingress controller without being redirected to the IdP for subsequent requests.

OIDC Policy Configuration

To implement OIDC authentication with the Nginx Plus Ingress Controller, we need to create an OIDC policy. Before we do that, we need to create a Secret to store the client secret required for the OIDC flow.

First, create a new file called client-secret.yaml and paste the following into it:

apiVersion: v1
kind: Secret
metadata:
  name: oidc-secret
type: nginx.org/oidc
data:
  client-secret: <client-secret-in-base64-format>

Make sure to replace <client-secret-in-base64-format> with your client secret in base64 format. You can convert your secret to base64 format using the following command:

echo -n <client-secret> | base64

Once you have your client secret in base64 format, you can deploy the Secret by executing the following command:

kubectl apply -f client-secret.yaml

Next, we will create and deploy the OIDC policy. Create a new file called oidc-policy.yaml and paste the following into it:

apiVersion: k8s.nginx.org/v1
kind: Policy
metadata:
  name: oidc-policy
spec:
  oidc:
    clientID: <client-id>
    clientSecret: oidc-secret
    authEndpoint: <idp-auth-url>
    tokenEndpoint: <idp-token-url>
    jwksURI: <idp-jwt-key-set-url>
    scope: openid+profile+email

Replace the following fields with the corresponding values:

• <client-id>: the client ID provided by your IdP

• <idp-auth-url>: the authorization URL that will be used to check if the user is authenticated or not

• <idp-token-url>: the token URL used to exchange the code for an access token and ID token

• <idp-jwt-key-set-url>: the JWT encryption key set URL for decrypting the JWT token

Optionally, you can customize the scope by modifying the scope field. The default scope includes openid, profile, and email. For more information on OIDC scopes, check out the Auth0 documentation on scopes.

For example, if your IdP is Auth0, your OIDC policy would look similar to this:

apiVersion: k8s.nginx.org/v1
kind: Policy
metadata:
  name: oidc-policy
spec:
  oidc:
    clientID: <client-id>
    clientSecret: oidc-secret
    authEndpoint: https://mydomain.us.auth0.com/authorize
    tokenEndpoint: https://mydomain.us.auth0.com/oauth/token
    jwksURI: https://mydomain.us.auth0.com/.well-known/jwks.json
    scope: openid+profile+email

Once you have created the OIDC policy file, you can deploy it using the following command:

kubectl apply -f oidc-policy.yaml

With the OIDC policy deployed, the Nginx Plus Ingress Controller will handle the authentication logic and session management for you, without the need for an external authentication proxy.

Nginx Plus Ingress Controller Configuration

Before we can use the newly deployed OIDC Policy, two prerequisite configurations need to be made in the Nginx Plus Ingress Controller: Zone synchronization and Resolver setup.

Zone synchronization ensures that the OIDC policy works properly across multiple replicas of the Ingress Controller. To enable this, we first need to create a headless service in the Nginx ingress controller namespace. Create a new file called nginx-ingress-headless.yaml and paste the following into it:

apiVersion: v1
kind: Service
metadata:
  name: nginx-ingress-headless
  namespace: nginx-ingress
spec:
  clusterIP: None
  selector:
    app: nginx-ingress

Make sure to specify the correct selector label for your Nginx ingress controller deployment. Deploy this service using the following command:

kubectl apply -f nginx-ingress-headless.yaml

Next, we need to add extra configuration to the Nginx ingress controller using a ConfigMap. Create a new file called nginx-config.yaml and paste the following into it:

kind: ConfigMap
apiVersion: v1
metadata:
  name: nginx-config
  namespace: nginx-ingress
data:
  # Zone Synchronization setup
  stream-snippets: |
    server {
        listen 12345;
        listen [::]:12345;
        zone_sync;
        zone_sync_server nginx-ingress-headless.nginx-ingress.svc.cluster.local:12345 resolve;
    }
  # Resolver setup
  resolver-addresses: <kube-dns-ip>
  resolver-valid: 5s

This configuration sets up zone synchronization and resolver setup for the OIDC policy. Make sure to replace <kube-dns-ip> with the cluster IP of the kube-dns service running inside your cluster. You can find the kube-dns cluster IP by running the following command:

kubectl -n kube-system get service kube-dns

Once you've created this configuration, you can deploy it using the following command:

kubectl apply -f nginx-config.yaml

With the prerequisite configurations in place, the next step is to create a Virtual Server and apply the OIDC policy to it.

Virtual Server Configuration

The virtual server is a custom resource definition provided by Nginx that offers more features compared to the standard Ingress resource. In combination with the OIDC policy, it enables secure access to your application. To create a virtual server, create a new file named virtual-server.yaml and add the following configuration to it:

apiVersion: k8s.nginx.org/v1
kind: VirtualServer
metadata:
  name: app-vs
spec:
  host: <your-domain>
  upstreams:
    - name: demo-app
      service: <app-service-name>
      port: 80
  policies:
    - name: oidc-policy
  routes:
    - path: /
      action:
        proxy:
          upstream: demo-app

Make sure to replace <your-domain> with a valid domain name and <app-service-name> with the name of the service you want to protect using the OIDC policy.

Execute the following command to deploy the virtual server and attach the OIDC policy to it:

kubectl apply -f virtual-server.yaml

Now, when a user tries to access your application, they will be redirected to the IdP configured in the OIDC policy. Only after successful authentication will the user be redirected to the application. Congratulations, you have successfully configured secure access to your application using Nginx plus Ingress Controller and OIDC policy!

What If...?

You want to provide additional user information to the application

By default, the OIDC policy provides the sub claim data via the header username to the application. However, if you need to pass other claim data to the application, you can add a custom location snippet inside the virtual server configuration.

For example, to add a custom header named email and pass the email claim information to the application, you can modify the virtual server configuration as follows:

...
routes:
    - path: /
      location-snippets: proxy_set_header email $jwt_claim_email;
      action:
        proxy:
          upstream: demo-app
...

This will add a new custom header named "email" and pass the email claim data to the application.

You want to provide a custom logout URL

When using the default /logout endpoint, a user will log out of the application. However, in some cases, you may also want the user to log out of the Identity Provider (IdP) or perform additional operations after the logout process. To achieve this, you can create a server snippet and specify a custom logout URL that the user will be redirected to after logging out of the application.

Here's an example server snippet that sets a custom logout redirect URL:

...
host: <your-domain>
  server-snippets: |
    set $logout_redirect "https://myidp.com/logout";
  upstreams:
    - name: demo-app
      service: demo-app-svc
      port: 80
...

Best Practices

1. Use HTTPS: Always use HTTPS when configuring the OIDC policy as it ensures secure communication between the application and IdP.

2. Keep IdP secrets safe: Store the IdP secrets securely in a key vault or a secure location accessible only to authorized personnel.

3. Avoid using custom snippets: Custom snippets can introduce unnecessary complexity and potential security risks to your configuration. Try to use the built-in features and directives provided by Nginx Ingress Controller whenever possible.

4. Use multiple replicas of the Ingress Controller to ensure high availability - this helps to prevent downtime if one replica fails.

5. Consider using a commercial version of Nginx Ingress Controller for enterprise-level support, advanced features, and improved scalability.

Conclusion

In conclusion, implementing OpenID Connect (OIDC) authentication with Nginx Plus Ingress Controller can provide a secure and reliable way to protect your applications from unauthorized access. With OIDC, you can take advantage of various identity providers such as Google, Facebook, Okta, etc., and enable Single Sign-On (SSO) for your users. Additionally, Nginx Plus Ingress Controller offers powerful features such as Virtual Servers and OIDC Policies to simplify the configuration process and ensure scalability.

However, it is important to keep in mind the best practices and potential pitfalls when using Nginx Plus Ingress Controller with OIDC. By following the recommended practices, such as avoiding custom snippets, keeping the configuration simple, and using Kubernetes best practices, you can ensure a smooth and secure deployment of your application.

Overall, the combination of Nginx Plus Ingress Controller and OIDC provides a powerful toolset for securing your applications and delivering a seamless user experience.

To explore other approaches for securing applications in a Kubernetes cluster, you can check out our previous blog post on Authentication & Authorization in Kubernetes Cluster — https://adityaoo7.hashnode.dev/authentication-authorization-in-kubernetes-cluster.

References

• OpenID Connect Official Documentation - https://openid.net/connect/

• Nginx Ingress Controller Official Documentation - https://docs.nginx.com/nginx-ingress-controller/intro/overview/

• OIDC Policy Official Documentation - https://docs.nginx.com/nginx-ingress-controller/configuration/policy-resource/#oidc

• OIDC policy example by Nginx - https://github.com/nginxinc/kubernetes-ingress/tree/v3.0.2/examples/custom-resources/oidc

"Authentication and authorization represent the new perimeter in a world where identity is the new control plane." - Satya Nadella, CEO of Microsoft.

Introduction

In our previous article, we explored how Oauth2 Proxy can be used as an external authentication proxy to secure applications within a Kubernetes cluster. While this is a good solution for simple use cases with a single IdP, Oauth2 Proxy comes with some limitations:

• Oauth2 Proxy cannot integrate with SAML IdP, which is commonly used in enterprise systems for authentication and authorization.

• In B2B enterprise systems, client organizations may want to use their own IdP for authentication without disrupting the host organization's IdP - multiple IdP integration - which Oauth2 Proxy cannot handle.

• Oauth2 Proxy only supports a limited set of identity providers, such as OAuth2/OIDC providers.

This is where Dex IdP comes into play. In this article, We are going to see the integration of Dex IdP with Oauth2 Proxy.

Why Dex IdP?

Dex IdP is an open-source identity provider that can be used to federate authentication across multiple systems, making it an ideal choice for larger and more complex Kubernetes deployments. It allows you to integrate multiple identity providers, including OAuth2/OIDC providers, SAML, LDAP, and Active Directory, into one centralized system. Dex acts as a bridge between your applications and the identity providers, providing a seamless and secure authentication and authorization experience.

How does Dex IdP work?

When a user tries to log in to a system that is protected by Dex IdP:

1. Dex provides the user with multiple Identity Provider (IdP) options from which they can choose to log in to their respective IdP.

2. The user selects the particular IdP in which their account is present, and Dex redirects the user to that IdP.

3. The user logs in to the IdP, and after successful authentication, the IdP redirects the user back to Dex.

4. Dex creates a session for the user and redirects the user to the particular application they were trying to access.

Installation and Configuration of Dex IdP

There are multiple ways to install Dex on a Kubernetes cluster, but in this article, we will be using Helm Charts.

To get started, add the Dex Helm Charts repository:

helm repo add dex https://charts.dexidp.io

In this example, we will integrate two IdPs: SAML IdP and OIDC IdP in Dex. To do this, create a new values.yaml file and paste the following example configuration into it:

# Configures the ingress for Dex
ingress:
  enabled: true
  className: nginx
  hosts:
    - host: "<your-domain>"
      paths:
        - path: /dex
          pathType: Prefix

# Configures the Dex instance          
config:
  issuer: https://<your-domain>/dex
  storage:
    type: kubernetes
    config:
      inCluster: true
  web:
    http: 0.0.0.0:8080
  oauth2:
    responseTypes: ["code", "token", "id_token"]
  # Configures the connections for Dex
  connectors:
    - type: saml
      id: saml
      name: "Example SAML connection"
      config:
        entityIssuer: https://<your-domain>/dex/callback
        ssoURL: <saml-login-url>
        caData: <ca-certificate-in-base-64>
        redirectURI: https://<your-domain>/dex/callback
        # map your attributes here
        usernameAttr: username 
        emailAttr: email
    - type: microsoft
      id: microsoft
      name: "Example Azure AD OIDC connection"
      config:
        clientID: "<client-id>"
        clientSecret: "<client-secret>"
        redirectURI: https://<your-domain>/dex/callback
        tenant: <tenant-id>

  # Configures the Client configuration
  staticClients:
    - id: <dex-client-id>
      secret: <dex-client-secret>
      name: "Oauth2 Proxy Static Client"
      redirectURIs:
        - https://<your-domain>/oauth2/callback

There are several important modifications to make:

• host: Replace with your domain name.

• issuer: Replace with the issuer URL that will be used by your authentication method.

For SAML IdP:

• entityIssuer: Set to the Issuer value you want to send during AuthnRequest.

• ssoURL: Set to the SAML login URL.

• caData: Set to the CA certificate in base64 format.

• redirectURI: Set to the redirect URI that your IdP will call after successful authentication.

• usernameAttr and emailAttr: check attributes configured for SAML IdP and map accordingly here (e.g. if the SAML IdP is configured to return the username attribute as "uid", then set usernameAttr: "uid" in the config, and if the email attribute is configured as "mail", then set emailAttr: "mail").

For Azure AD OIDC IdP:

• clientID: Set to the Client ID provided by your IdP.

• clientSecret: Set to the Client Secret provided by your IdP.

• redirectURI: Set to the redirect URI that your IdP will call after successful authentication.

• tenant: Set to the Azure Tenant ID.

For Static Client (Oauth2 Proxy):

• id: Set to the Client ID that will be used by the Oauth2 Proxy when connecting to Dex IdP.

• secret: Set to the Client Secret that will be used by the Oauth2 Proxy when connecting to Dex IdP.

• redirectURIs: Set to the callback URI of the Oauth2 Proxy.

To deploy Dex, run the following command:

helm upgrade --install -n dex dex dex/dex --values values.yaml

This command will install and configure Dex on your Kubernetes cluster. Dex will be hosted at "http://<your-domain>/dex".

For more information on configuring Dex to work with your specific identity provider, check out the official documentation at https://dexidp.io/docs/connectors/.

Configuration of Oauth2 Proxy

To configure Oauth2 Proxy, you will follow similar steps as you did for configuring other IdPs inside Oauth2 Proxy. The difference will be that you will replace specific properties in the Deployment of Oauth2 Proxy with those that correspond to your Dex instance.

You will need to replace the following properties:

• oidc-issuer-url: This is the issuer URL you specified in Dex.

• OAUTH2_PROXY_CLIENT_ID: This is the static client ID you specified in Dex.

• OAUTH2_PROXY_CLIENT_SECRET: This is the static client secret you specified in Dex.

Here's an example Deployment file for Oauth2 Proxy that shows how these values can be replaced:

apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    k8s-app: oauth2-proxy
  name: oauth2-proxy
  namespace: oauth2-proxy-ns
spec:
  replicas: 1
  selector:
    matchLabels:
      k8s-app: oauth2-proxy
  template:
    metadata:
      labels:
        k8s-app: oauth2-proxy
    spec:
      containers:
      - args:
        - --provider=oidc
        - --oidc-issuer-url=http://<your-domain>/dex
        - --scope=openid profile email
        - --email-domain=*
        - --upstream=static://200
        - --http-address=0.0.0.0:4180
        env:
        - name: OAUTH2_PROXY_CLIENT_ID
          value: <dex-client-id> # Replace with the client ID from Dex
        - name: OAUTH2_PROXY_CLIENT_SECRET
          value: <dex-client-secret> # Replace with the client secret from Dex
        - name: OAUTH2_PROXY_COOKIE_SECRET
          value: "bVbMfxlt8Wmq4E1OYTICqS_AZHTeVDUEdFP5LGbY05c"
        image: quay.io/oauth2-proxy/oauth2-proxy:latest
        imagePullPolicy: Always
        name: oauth2-proxy
        ports:
        - containerPort: 4180
          protocol: TCP
        resources:
          limits:
            cpu: 100m
            memory: 128Mi
          requests:
            cpu: 100m
            memory: 128Mi

After configuring and deploying Oauth2 Proxy with the values from your Dex instance, you will be able to use Dex as your identity provider.

Final Result

With Dex IdP and Oauth2 Proxy configured and deployed, you can now test the example by navigating to the domain specified in the manifest file for the host attribute. For example, if you set “example.com” as the host, visit http://example.com/ in your web browser.

After hitting the URL, you will be redirected to the Dex login page where you can choose an IdP to authenticate with from the options configured in Dex. The login page will look similar to this:

Select any one option to proceed with authentication. Once you have successfully logged in, you will be redirected back to the demo application, and you can begin to interact with it.

Congratulations, you have successfully integrated Dex IdP with Oauth2 Proxy! You can now use Dex to authenticate users to your web applications and APIs protected by Oauth2 Proxy.

Authorization using Dex IdP

In addition to authentication, Dex also supports authorization through the use of groups. When the groups claim is configured for an IdP, it is possible to require a user to be a member of a particular group to be successfully authenticated in Dex. Inside the connector configuration YAML file, we can pass groups to which access should be granted. Here is an example of how this can be done for a Microsoft OIDC connection:

...
  - type: microsoft
      id: microsoft
      name: "Example Azure AD OIDC connection"
      config:
        clientID: "<client-id>"
        clientSecret: "<client-secret>"
        redirectURI: https://<your-domain>/dex/callback
        tenant: <tenant-id>
        # Mention which groups are allowed access
        groups:
          - admin
          - developer
...

In this example, the groups property specifies that only users who are members of the admin or developer groups in the Azure AD instance will be allowed to access the protected resource. This way, you can perform authorization in Dex based on group membership.

Best Practices

1. Keep your certificates and secrets secure: Certificates and secrets play a crucial role in securing your authentication flow. Ensure that you store them in a secure location and rotate them frequently.

2. Use the latest versions: Always use the latest versions of Dex IdP and Oauth2 Proxy to take advantage of bug fixes and security patches.

3. Test thoroughly: Test your integration thoroughly before deploying it in production to ensure that everything is working as expected.

4. Use automation tools: Consider using automation tools to streamline the deployment and configuration of Dex IdP and Oauth2 Proxy, as it can save time and reduce the risk of manual errors.

5. Keep your configuration simple: Avoid overcomplicating your configuration. Keep your configuration simple and easy to maintain, and only include the necessary features.

By following these best practices, you can ensure that your Dex IdP and Oauth2 Proxy integration is secure, reliable, and easy to maintain.

Conclusion

In conclusion, integrating Dex and OAuth2 Proxy provides a secure and flexible solution for authenticating and authorizing users accessing your applications. Dex provides a centralized authentication service for your organization, while OAuth2 Proxy allows you to easily add authentication to your applications without needing to modify their code.

By following the steps outlined in this guide, you should now have a good understanding of how to integrate Dex and OAuth2 Proxy in your Kubernetes cluster. Remember to follow best practices when implementing this solution, such as regularly updating and securing your configurations, and testing thoroughly before deploying in production.

Overall, integrating Dex and OAuth2 Proxy can greatly enhance the security and usability of your applications, and enable your organization to better manage access control for your resources.

To explore other approaches for securing applications in a Kubernetes cluster, you can check out our previous blog post on Authentication & Authorization in Kubernetes Cluster — https://adityaoo7.hashnode.dev/authentication-authorization-in-kubernetes-cluster.

References

• Dex official documentation: https://dexidp.io/docs/

• Oauth2 Proxy official documentation: https://oauth2-proxy.github.io/oauth2-proxy/

• Kubernetes official documentation: https://kubernetes.io/docs/home/

"OAuth 2.0 and OpenID Connect (OIDC) have become the de facto standards for authentication and authorization in modern web applications and APIs. In the world of Kubernetes, these technologies provide a powerful framework for securing access to your cluster resources and applications." - Jeff Atwood, co-founder of Stack Overflow

Introduction

Securing a Kubernetes cluster involves implementing authentication and authorization at either the ingress layer or the application layer. Authenticating (and sometimes authorizing) users at the ingress layer can be more efficient, as it offloads authentication logic from applications. Multiple approaches exist for implementing ingress-level authentication and authorization, and one of the most popular options is to use an external authentication proxy. Oauth2 proxy is a powerful and open-source authentication proxy that can simplify the implementation of secure authentication and authorization in Kubernetes. In this article, we are going to see the integration of Oauth2 Proxy with the NGINX ingress controller (both open source and NGINX plus version).

Why Oauth2 Proxy?

Oauth2 Proxy provides a simple and configurable way to authenticate users using OAuth2 providers such as Google, GitHub, and Okta. It also offers authorization features based on email validation, domain check or group membership. OAuth2 Proxy is containerized, making it easy to deploy and manage in Kubernetes clusters. Additionally, it's open-source software with a thriving community that consistently updates and maintains the project.

How does Oauth2 Proxy work?

source - https://oauth2-proxy.github.io/oauth2-proxy/

1. When a user tries to access a protected resource, the NGINX ingress controller sends the request to OAuth2 Proxy to check if the user is authenticated.

2. OAuth2 Proxy checks for a session cookie in the request, and if present, verifies the user's session details and returns a successful response.

3. If the session cookie is not present, OAuth2 Proxy redirects the user to the login page of the configured IdP (such as Google or GitHub).

4. The user logs in to the IdP and is redirected back to OAuth2 Proxy, which receives the user's information from the IdP.

5. OAuth2 Proxy creates a new session for the user using this information and sets a session cookie in the response.

6. The NGINX ingress controller receives the successful response from OAuth2 Proxy and allows the user to access the requested resource.

Installation and Configuration of Oauth2 Proxy

There are multiple ways to install Oauth2 Proxy, you can check them out at https://oauth2-proxy.github.io/oauth2-proxy/docs/. Here we are going with Kubernetes manifest files.

Create a new file oauth2-proxy.yaml and paste the following manifest into it. Make sure to change values annotated with comments according to your IdP configuration.

apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    k8s-app: oauth2-proxy
  name: oauth2-proxy
  namespace: oauth2-proxy-ns
spec:
  replicas: 1
  selector:
    matchLabels:
      k8s-app: oauth2-proxy
  template:
    metadata:
      labels:
        k8s-app: oauth2-proxy
    spec:
      containers:
      - args:
        - --provider=oidc
        # if using azure provide tenant id, other wise remove line below
        - --azure-tenant=<tenant-id> # replace with your tenant id
        - --oidc-issuer-url=<issuer-url> # replace with your OIDC IdP's issuer url
        - --scope=openid groups profile email
        - --email-domain=*
        - --upstream=static://200
        - --http-address=0.0.0.0:4180
        env:
        - name: OAUTH2_PROXY_CLIENT_ID
          value: <client-id> # replace with client id
        - name: OAUTH2_PROXY_CLIENT_SECRET
          value: <client-secret> # replace with client secret
        - name: OAUTH2_PROXY_COOKIE_SECRET
          value: "bVbMfxlt8Wmq4E1OYTICqS_AZHTeVDUEdFP5LGbY05c" # replace with value of: python -c 'import os,base64; print(base64.urlsafe_b64encode(os.urandom(32)).decode())'
        image: quay.io/oauth2-proxy/oauth2-proxy:latest
        imagePullPolicy: Always
        name: oauth2-proxy
        ports:
        - containerPort: 4180
          protocol: TCP
        resources:
          limits:
            cpu: 100m
            memory: 128Mi
          requests:
            cpu: 100m
            memory: 128Mi
---
apiVersion: v1
kind: Service
metadata:
  labels:
    k8s-app: oauth2-proxy
  name: oauth2-proxy
  namespace: oauth2-proxy-ns
spec:
  ports:
  - name: http
    port: 4180
    protocol: TCP
    targetPort: 4180
  selector:
    k8s-app: oauth2-proxy

---
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: oauth2-proxy
  namespace: oauth2-proxy-ns
  annotations:
    # For ingress-nginx (open source nginx ingress controller) only.
    nginx.ingress.kubernetes.io/proxy-body-size: "2000m"
    nginx.ingress.kubernetes.io/proxy-buffer-size: "32k"
    # For nginx-ingress (NGINX plus ingress controller) only.
    nginx.org/client-max-body-size: "2000m"
    nginx.org/proxy-buffer-size: "32k"
spec:
  ingressClassName: nginx
  rules:
  - host: "example.com" # change to your domain
    http:
      paths:
      - path: /oauth2
        pathType: Prefix
        backend:
          service:
            name: oauth2-proxy
            port:
              number: 4180

There are several important modifications to make:

• azure-tenant: If you're using Azure as your identity provider, you'll need to specify the tenant ID of your Azure account. If you're not using Azure, you can remove this line from the manifest.

• oidc-issuer-url: The issuer URL is typically specified in your identity provider's portal. For example, the issuer URL for Azure is https://sts.windows.net/<tenant-id>/.

• OAUTH2_PROXY_CLIENT_ID: This is the client ID provided by your identity provider. For example, in Azure, your client ID will be the application ID of the enterprise application you created.

• OAUTH2_PROXY_CLIENT_SECRET: This is the client secret provided/generated by your identity provider. For example, in Azure, you can create a secret in the Enterprise application by going to the Certificates and Secrets section and providing it here as the client secret.

• OAUTH2_PROXY_COOKIE_SECRET: This secret is used during cookie data encryption. You can provide a random secret, or generate one by running the following command on a Python-installed machine:

python -c 'import os,base64;print(base64.urlsafe_b64encode(os.urandom(32)).decode())'

• host: Change the hostname to your specific domain name.

• Make sure to use annotations specified for your particular version of the NGINX Ingress Controller. These annotations are helpful when the cookie size is larger than usual. For example, Azure’s cookies are often larger than normal.

To deploy OAuth2 Proxy in your Kubernetes cluster, simply run the following command:

kubectl apply -f oauth2-proxy.yaml

Once deployed, OAuth2 Proxy will be hosted at “http://example.com/oauth2".

For more information on configuring OAuth2 Proxy to work with your specific identity provider, check out the official documentation at https://oauth2-proxy.github.io/oauth2-proxy/docs/configuration/oauth_provider.

Configuration of NGINX Ingress Controller

Now that you have successfully installed and configured Oauth2 Proxy, it's time to configure the NGINX ingress controller. The NGINX ingress controller comes in two versions: the open-source version (commonly referred to as ingress-nginx) and the plus version (commonly referred to as nginx-ingress). Both versions offer similar base features, but the plus version includes additional features and an SLA, making it suitable for production use.

To enable authentication with Oauth2 Proxy, the NGINX ingress controller provides several annotations that can be used to integrate Oauth2 Proxy as an external authentication proxy. These annotations are applied per ingress, which means that you can use different authentication methods for different applications. For this example, create a new file called demo-app.yaml and paste the following manifest into it:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: demo-app
  namespace: demo-app-ns
  labels:
    app: demo-app
spec:
  replicas: 1
  selector:
    matchLabels:
      app: demo-app
  template:
    metadata:
      labels:
        app: demo-app
    spec:
      containers:
      - name: nginx
        image: nginx
        ports:
        - name: http
          containerPort: 80
        imagePullPolicy: IfNotPresent
---
apiVersion: v1
kind: Service
metadata:
  name: demo-app-svc
  namespace: demo-app-ns
  labels:
    app: demo-app
spec:
  selector:
    app: demo-app
  ports:
    - protocol: TCP
      port: 80
      targetPort: 80
---
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  annotations:
    nginx.ingress.kubernetes.io/auth-url: "https://$host/oauth2/auth"
    nginx.ingress.kubernetes.io/auth-signin: "https://$host/oauth2/start?rd=$escaped_request_uri"
  name: demo-app-ingress
  namespace: demo-app-ns
spec:
  ingressClassName: nginx
  rules:
  - host: "example.com"
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: demo-app-svc
            port:
              number: 80

• nginx.ingress.kubernetes.io/auth-url: This annotation specifies the URL where the ingress controller will forward authentication requests. In our example, we set it to Oauth2 Proxy’s /auth endpoint, which returns a 202 Accepted or 401 Unauthorized response.

• nginx.ingress.kubernetes.io/auth-signin: This annotation specifies the URL where users will be redirected when authentication is required. In our example, we redirect users to the /start endpoint, where Oauth2 Proxy will begin the Oauth cycle and authenticate the user.

To deploy the demo application, execute the following command:

kubectl apply -f demo-app.yaml

This will deploy the demo application in your Kubernetes cluster and make it accessible at http://example.com.

Final Result

With the NGINX ingress controller and demo application configured, we can now test out our example. Navigate to the domain you specified in the manifest file for the host attribute. For instance, if you set “example.com” as the host, visit http://example.com/ in your web browser.

Upon accessing the application URL, you will be automatically redirected to the login page of your Identity Provider (IdP) to authenticate. For example, the Azure AD IdPs login page would be like this:

Once you have successfully logged in, you will be redirected back to the demo application, and you can begin to interact with it.

Congratulations, you have successfully integrated OAuth2 Proxy with the NGINX ingress controller to provide secure external access to your Kubernetes application.

Authorization using Oauth2 Proxy

OAuth2 proxy provides powerful authorization features that can help you to restrict access to your applications. You can use one or more of the following query parameters in the /auth endpoint to configure the authorization settings:

allowed_emails: This parameter allows you to specify a comma-separated list of email addresses that are allowed to access the application. For example:

nginx.ingress.kubernetes.io/auth-url: “https://$host/oauth2/auth?allowed_emails=dev1@example.com,dev2@example.com"

When a user logs in, their email address is checked against the list of allowed email addresses. If it matches one of the email addresses on the list, access is granted.

allowed_email_domains: This parameter allows you to specify a comma-separated list of email domains that are allowed to access the application. For example:

nginx.ingress.kubernetes.io/auth-url: “https://$host/oauth2/auth?allowed_email_domains=example.com,foobar.com"

When a user logs in, their email domain is checked against the list of allowed email domains. If it matches one of the domains on the list, access is granted.

allowed_groups: This parameter allows you to specify a comma-separated list of groups whose members are allowed to access the application. For example:

nginx.ingress.kubernetes.io/auth-url: “https://$host/oauth2/auth?allowed_groups=admin,mgmt"

After a user logs in, the OAuth2 proxy checks if they are a member of one of the allowed groups. If they are a member of one of the groups on the list, access is granted.

By using one or more of these parameters, you can control who has access to your applications and ensure that only authorized users can log in.

Best Practices

1. Keep OAuth2 Proxy and Nginx Ingress Controller up-to-date with the latest releases to ensure the security of your environment.

2. Use separate OAuth2 Proxy instances for different Kubernetes namespaces or applications to increase the security of your environment.

3. Use a dedicated service account for OAuth2 Proxy and grant it only the necessary permissions to limit its access to the cluster.

4. Avoid storing OAuth2 Proxy secrets, such as client ID and secret, in plain text files or environment variables. Use Kubernetes secrets to store them securely.

5. Use HTTPS for all communication between OAuth2 Proxy and Nginx Ingress Controller to protect against eavesdropping and data tampering.

6. Use appropriate timeouts and limits for OAuth2 Proxy and Nginx Ingress Controller to prevent denial-of-service attacks and optimize resource utilization.

7. When configuring OAuth2 Proxy authorization, choose the most restrictive method possible for your use case. For example, use email validation instead of allowing all users from a particular domain, or use group membership validation instead of allowing all authenticated users.

8. When using group membership validation, use unique group names that are specific to your application. Avoid using common group names like “admin” or “user” as this can cause conflicts with other applications or services.

Conclusion

In conclusion, we have seen how to secure Kubernetes applications using OAuth2 Proxy and Nginx Ingress Controller. By integrating external authentication and authorization mechanisms, we can enhance the security of our applications and protect them from unauthorized access. We have learned how to install and configure OAuth2 Proxy and Nginx Ingress Controller, how to use annotations to customize their behaviour, and how to apply best practices to ensure the security of our environment.

Implementing these techniques will help you to build a robust and secure Kubernetes infrastructure that meets the highest standards of security and compliance. We encourage you to experiment with these tools and explore their full potential to create a safe and efficient environment for your applications. Thank you for reading, and we hope this article has been helpful to you!

To explore other approaches for securing applications in a Kubernetes cluster, you can check out our previous blog post on Authentication & Authorization in Kubernetes Cluster — https://adityaoo7.hashnode.dev/authentication-authorization-in-kubernetes-cluster.

References

1. The official OAuth2 Proxy documentation: https://oauth2-proxy.github.io/oauth2-proxy/

2. The official Nginx Ingress Controller documentation: https://docs.nginx.com/nginx-ingress-controller/intro/overview/

3. The Open Source Nginx Ingress Controller documentation: https://kubernetes.github.io/ingress-nginx/

4. Oauth2 Proxy endpoints: https://oauth2-proxy.github.io/oauth2-proxy/docs/features/endpoints

5. Kubernetes documentation on securing your cluster: https://kubernetes.io/docs/tasks/administer-cluster/securing-a-cluster/

“Security is not an afterthought, it should be the foundation of any technology implementation. In the world of Kubernetes, strong authentication is key to ensuring the safety and integrity of your application and data.” — Joe Beda, Co-creator of Kubernetes

Introduction

Kubernetes is a powerful platform that allows you to manage and deploy containerized applications. However, with all applications running on the same cluster, managing access control can be a challenge. This is where authentication & authorization (or ‘authN/authZ’) comes in.

By authenticating & authorizing users before accessing applications, you can manage access control more efficiently and save time by avoiding the need to implement authentication logic in every application. Additionally, authenticating users at the perimeter — or the edge of the cluster — ensures that traffic flowing inside the cluster is only from authenticated users, eliminating traffic from unauthenticated user requests and responses.

In this blog, we’ll explore the importance of authN/authZ in Kubernetes and the different ways available to secure your applications with authentication and authorization.

Authentication & Authorization

In a Kubernetes deployment, authentication and authorization can be configured using various methods such as X.509 client certificates, static passwords, or integrating with an IdP. By leveraging an IdP, you can centralize user management and ensure that your Kubernetes cluster is integrated with your existing identity and access management (IAM) infrastructure.

Two popular options are SAML and OIDC, which are often used as single sign-on (SSO) solutions. SAML handles both authentication and authorization by using a SAML Assertion token, while OIDC is built on top of the OAuth 2.0 protocol. With OIDC, the OIDC layer handles authentication (who the user is) and OAuth 2.0 handles authorization (what the user can access) by using an access token.

Approaches to Kubernetes AuthN/AuthZ

There are several perimeter solutions available for securing applications deployed in Kubernetes, including Ingress controllers and Service Mesh. In this article, we will focus on the Nginx Ingress controller, both the open-source and Nginx Plus versions. We will explore four approaches that can be used to integrate AuthN/AuthZ with the Nginx Ingress controller to secure our applications:

Approach 1 — Oauth2-proxy as an authentication proxy.

This approach leverages the Oauth2-proxy (https://oauth2-proxy.github.io/oauth2-proxy/) to handle authentication and pass authenticated requests to the Nginx Ingress controller. Oauth2-proxy is a reverse proxy that provides authentication service using integrating various Oauth2.0-supported IdPs. Advantages of this approach include:

• Easy integration with any OIDC IdP

• Access control based on email or group

However, there are some disadvantages to consider:

• *Support for only OIDC IdP, not SAML

• *Integration with only a single IdP at a time

• Need to manage this service and its security

*there’s a solution for this, refer to Approach 5

Approach 2 — Oauth2-proxy with Dex.

This approach builds upon Approach 1 by integrating the dex IdP (https://dexidp.io/) to allow for more advanced authentication scenarios. Dex is an identity service that provides authN/authZ to applications by integrating multiple IdPs of various types. Advantages of this approach include:

• Support for multi-IdP (multi-tenancy) scenarios

• More granular access control

However, there are some disadvantages to consider:

• Support for SAML is deprecated

• Need to manage this service and its security

Approach 3 — Nginx Plus Ingress Controller with OIDC policy.

This approach integrates an OIDC provider directly within the ingress controller itself by utilizing the OIDC policy provided by nginx plus ingress controller. Advantages of this approach include:

• Authentication is directly integrated into the ingress controller, so no need to manage separate services for authN

• A robust way to integrate with the ingress controller

However, there are some disadvantages to consider:

• *Support for only OIDC IdP, not SAML.

• *Integration with only a single IdP at a time.

• No access control based on the user’s role or group

*there’s a solution for this, refer to Approach 5

Approach 4 — Nginx Plus Ingress Controller with Istio Service Mesh.

This approach provides additional features, such as RBAC authorization, traffic management, and observability, in addition to the advantages of Approach 3 by using Istio service mesh (https://istio.io/). Advantages of this approach include:

• All of the advantages of Approach 3

• Access control based on roles

• More features such as traffic management and observability

However, there is one disadvantage to consider:

• *Support for only OIDC IdP, not SAML.

• *Integration with only a single IdP at a time.

• Need to manage both the ingress controller and service mesh.

*there’s a solution for this, refer to Approach 5

Approach 5 — Auth0 as External Identity Provider

This approach involves using Auth0 (https://auth0.com/) as an external identity provider to handle user authentication and authorization. Auth0 supports multiple IdPs, including OIDC and SAML, providing flexibility in choosing an appropriate IdP. Advantages of this approach include:

• Allows you to connect to multiple IdPs

• Supports a wide range of IdPs

However, there is one disadvantage to consider:

• Need to manage authorization at client side — Ingress Controller / Oauth2-Proxy.

Best Practices

Based on the approaches discussed, here are some best practices for configuring Kubernetes authentication using Nginx Ingress:

1. Use a supported IdP: While all of the approaches discussed support OIDC, Approach 1 and Approach 2 are the only ones that support SAML. When selecting an IdP, ensure that it is supported by the approach you choose.

2. Secure your authentication proxies: With Approach 1 and Approach 2, you will be managing a separate authentication proxy. It’s important to secure this service to ensure that unauthorized users cannot access your applications.

3. Consider your access control needs: Access control is an important aspect of authentication, and different approaches provide different levels of granularity. Consider your access control needs when selecting an approach.

4. Leverage the Nginx Plus OIDC policy: Approach 3 is a robust way to integrate with the ingress controller, but it has limited access control capabilities. Consider using the Nginx Plus OIDC policy for a more streamlined approach to authentication.

5. Use a service mesh for additional features: Approach 4 provides additional features like RBAC authorization, traffic management, and observability. Consider using a service mesh if these features are important for your use case.

6. Regularly review and update your authentication configuration: As with any security configuration, it’s important to regularly review and update your authentication configuration to ensure that it remains secure and up-to-date with the latest best practices.

Conclusion

In conclusion, securing applications in Kubernetes requires careful consideration of different authentication and authorization options, as well as understanding solutions like Ingress controllers and Service Mesh. We explored different approaches for integrating AuthN/AuthZ, each with its own advantages and disadvantages. When selecting a solution, it’s important to consider the specific needs of your application and deployment. As a best practice, we recommend using a centralized identity provider for managing user authentication and access control across your Kubernetes cluster.

Thank you for reading! In upcoming articles, we will explore the implementation of each approach in greater detail. Stay tuned for more insights on this topic!

References

Configure Oauth2-Proxy with IdPs — https://oauth2-proxy.github.io/oauth2-proxy/docs/configuration/oauth_provider

Connect Oauth2-Proxy with Dex — https://oauth2-proxy.github.io/oauth2-proxy/docs/configuration/oauth_provider#dex

Nginx Plus Ingress Controller OIDC Policy — https://docs.nginx.com/nginx-ingress-controller/configuration/policy-resource/#oidc

Integrate Nginx Ingress Controller with Istio Service Mesh — https://docs.nginx.com/nginx-ingress-controller/tutorials/nginx-ingress-istio/

SSO with Auth0 in nginx plus — https://docs.nginx.com/nginx/deployment-guides/single-sign-on/auth0/

AuthN/AuthZ using Auth0 and Istio — https://auth0.com/blog/securing-kubernetes-clusters-with-istio-and-auth0/