Access control

Access control with Airlock IAM

Overview

Goal

Configure the Microgateway to enforce upfront authentication for a backend service.

Notes

This exercise uses Airlock IAM to authenticate users.

Therefore, access to the private Airlock IAM Docker Hub repository as well as a valid Airlock IAM license is required. This is currently restricted to Airlock customers and partners only.

Procedure-related prerequisites

    • Get access to the private Airlock IAM Docker Hub repository:
      1. To gain access the following steps must be taken:
      2. As a customer, you must have at least one account on Docker Hub.
      3. Create a support ticket for "access to Airlock IAM on Docker Hub" on https://techzone.ergon.ch and supply one or more Docker Hub account IDs.
    • Create a imagePullSecret with the name dockerregcred:
    • copy
      kubectl create secret docker-registry dockerregcred \
        --docker-server='https://index.docker.io/v1/' \
        --docker-username=<DOCKER_USER> \
        --docker-password=<DOCKER_PASSWORD> \
        --docker-email=<DOCKER_EMAIL>
    • To run the exercise a valid Airlock IAM license is required. Copy the license file to .templates/iam/secret/iam.lic before deploying the exercise.

Preparation

  1. Deploy the Kubernetes exercise
  2. Run the following commands:
  3. copy
    cd access-control/exercise/
    copy
    kubectl replace --force -k .
  4. The exercise has been deployed successfully.

The exercise does not contain any licenses. Therefore, Airlock Microgateway runs as Community Edition (see Features and support).

To run the exercise as Premium Edition, copy a valid license to .templates/microgateway/secret/microgateway.lic and execute kubectl replace --force -k . to re-deploy the Microgateway.

Test users

The table below lists the test users with their password and roles.

Username

Password

Roles

user1

password

wp-user, authenticated

wpadmin

password

wp-user, wp-admin, authenticated

Instruction

  1. Adapt the Microgateway configuration to restrict access to the Admin page
  2. Connect to the website:
    • Open the URL in your browser: https://<MINIKUBE_IP>/
  3. Click Admin in the menu
    • The following should be noticed:
    • Access is not restricted. The login form from the back-end is displayed.
    • Restrict access as follow:
    • Only users with the role wp-admin should be allowed to access /wordpress/wp-admin/ (Admin page).
  4. Edit Microgateway's configuration file.
  5. Edit the file config/config.yaml and configure the following settings:

    • Configure the following settings:
    • auth.access[].path
    • auth.access[].roles

    A session store is required to store the roles after authentication. For this exercise, a session store is already pre-configured.

    Use the (Microgateway) DSL reference to accomplish this task.

    details...

    The modified part of the config.yaml looks as follow:

    copy
          - name: wordpress 
            entry_path: 
              value: /wordpress/ 
            ... 
            auth: 
              flow: redirect 
              denied_access_url: /auth/ui/app/auth/application/access 
              access: 
                - path: 
                    pattern: ^%ENTRYDIR%/wp-admin/ 
                  roles: 
                    - wp-admin      
    
  6. Re-create the Microgateway resources with the new configuration.
  7. Delete all Microgateway resources:

    copy
    kubectl delete all,cm,secret,ingress -l app=microgateway

    Create all Microgateway resources:

    copy
    kubectl create -l app=microgateway -k .

    A running Microgateway does not automatically reload the new configmap. The existing Microgatway pod must be killed. This way a new pod is deployed with the adapted configuration.

  8. Check the status of the Microgateway pod.
  9. details...

    List the Microgateway pods:

    copy
    kubectl get pod
    copy
    kubectl get pod -l app=microgateway

    Show Microgateway pod details:

    copy
    kubectl describe pod -l app=microgateway

    Once the pod is ready to process requests, the output of the kubectl describe command shows that the pod is ready.

    ...
       Conditions: 
      Type              Status 
      Initialized       True 
      Ready             True 
      ContainersReady   True 
      PodScheduled      True
    ...     
  10. Connect to the website:
    • Open the URL in your browser: https://<MINIKUBE_IP>/
    • The following should be noticed:
    • Access to the Admin page is restricted to the role wp-admin.
    • Access to the Blog page is not restricted.
  11. Access is restricted to authenticated users as desired.
  1. Adapt the Microgateway configuration to restrict access to the Blog page
  2. Connect to the website:
    • Open the URL in your browser: https://<MINIKUBE_IP>/
  3. Click Blog in the menu
    • The following should be noticed:
    • Access is not restricted.
    • Restrict access as follow:
    • Users with the role wp-user should be allowed to access everything under /wordpress/ (except Admin page).
    • Users with the role wp-user should not be allowed to access /wordpress/wp-admin/ (Admin page).
  4. Edit Microgateway's configuration file.
    • Configure the following settings:
    • auth.access[].path
    • auth.access[].roles

    A session store is required to store the roles after authentication. For this exercise, a session store is already pre-configured.

    Use the (Microgateway) DSL reference to accomplish this task.

    details...

    The modified part of the config.yaml looks as follow:

    copy
          - name: wordpress
            entry_path:
              value: /wordpress/
            ...
            auth:
              flow: redirect
              denied_access_url: /auth/ui/app/auth/application/access
              access:
                - path:
                    pattern: ^%ENTRYDIR%/(?!wp-admin/.*)
                  roles:
                    - wp-user
                - path:
                    pattern: ^%ENTRYDIR%/wp-admin/
                  roles:
                    - wp-admin
    
  5. Re-create the Microgateway resources with the new configuration.
  6. Delete all Microgateway resources:

    copy
    kubectl delete all,cm,secret,ingress -l app=microgateway

    Create all Microgateway resources:

    copy
    kubectl create -l app=microgateway -k .

    A running Microgateway does not automatically reload the new configmap. The existing Microgatway pod must be killed. This way a new pod is deployed with the adapted configuration.

  7. Check the status of the Microgateway pod.
  8. details...

    List the Microgateway pods:

    copy
    kubectl get pod
    copy
    kubectl get pod -l app=microgateway

    Show Microgateway pod details:

    copy
    kubectl describe pod -l app=microgateway

    Once the pod is ready to process requests, the output of the kubectl describe command shows that the pod is ready.

    ...
       Conditions: 
      Type              Status 
      Initialized       True 
      Ready             True 
      ContainersReady   True 
      PodScheduled      True
    ...     
  9. Connect to the website:
    • Open the URL in your browser: https://<MINIKUBE_IP>/
    • The following should be noticed:
    • Access to the Admin page is restricted to the role wp-admin.
    • Access to the Blog page is restricted to the role of wp-user.
    • Users with the role wp-user are not allowed to access /wordpress/wp-admin/
  10. Access is restricted to authenticated users as desired.

Cleanup

  1. Delete Kubernetes resources from previously exercises or solutions
  2. Run the following commands:
  3. copy
    kubectl delete all,ing,cm,secrets,pv,pvc,sa,roles,rolebindings,clusterroles,clusterrolebindings -l purpose=microgateway-tutorial
  4. All relevant Kubernetes resources in the namespace have been deleted successfully.