Session handling

Overview

Goal

Configure the Microgateway to protect a simple backend service with session handling enabled.

Notes

-

Preparation

  1. Deploy the Kubernetes exercise
  2. Run the following commands:
    3. copy
    cd session-handling/exercise/
    copy
    kubectl apply -k .
  3. The exercise has been deployed successfully.

The exercise does not contain any licenses. Therefore, Airlock Microgateway runs as Community Edition

For more details see Features and support.

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

Instruction

  1. Change the Microgateway configuration
  2. Connect to the website:
    • Open the URL in your browser: https://<MINIKUBE_IP>/
  3. Watch the logs of the Microgateway pod.
    4. details...

    Check the logs of the Microgateway configbuilder.

    copy
    kubectl logs -l app=microgateway -c configbuilder -f

    Follow the logs of the Microgateway runtime container.

    copy
    kubectl logs -l app=microgateway -c microgateway -f

    Follow the logs of the Microgateway runtime container and filter for interesting log messages. Mainly these are the log messages with the log_id WR-SG-SUMMARY and WR-SG-BLOCK. Under some circumstances, WR-SG-REJECT or WR-SG-BACK is also very interesting.

    copy
    kubectl logs -l app=microgateway -c microgateway -f | grep -iE "WR-SG-(SUMMARY|BLOCK|REJECT|BACK)"
  4. Check the following:
    • Did Airlock Microgateway receive the request?
    • Did Airlock Microgateway forward the request to the back-end service?
    • Did Airlock Microgateway log the same sess_id for requests in the same session?
    details...
    • The following should be noticed:
    • The request was received by Airlock Microgateway. The log message WR-SG-SUMMARY indicates that.
    • The request has been forwarded to the back-end. The log keys "action":"allowed" and "back-end_url":"http..." in the log message WR-SG-SUMMARY show that.
    • The Microgateway default configuration for the Mapping is session_handling: ignore_session. In addition, the default configuration for the setting session.redis_hosts[] does not contain a Redis server. Therefore, the Microgateway is in sessionless mode. Because of that all incoming requests have the log key "sess_id":"<n/a>".
  5. Find out the Kubernetes service name for Redis.
    6. details...
    copy
    kubectl get svc

    The NAME of the Kubernetes service can be configured as a Redis host in the Microgateway configuration.

  6. Edit Microgateway's configuration file.

    7. Edit the file config/config.yaml and configure the following settings:

    • Globally:
    • session.redis_hosts[]
    • For the mapping echoserver:
    • session_handling: enforce_session

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

    details...

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

    copy
    ---
session:
  redis_hosts: [redis-master]

...
...
    mappings: 
      - name: echoserver 
        session_handling: enforce_session
  7. Apply the new configuration.

    8. After modifying the configuration file, apply the new configuration by running the following command:

    copy
    kubectl apply -k .
  8. Deploy the Microgateway with the new configuration.
    9. details...
    copy
    kubectl rollout restart deployment/microgateway

    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.

  9. Check the status of the Microgateway pod.
    10. 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>/
  11. The web application should be reachable from the browser.
  12. Watch the logs of the Microgateway pod.
    13. details...

    Check the logs of the Microgateway configbuilder.

    copy
    kubectl logs -l app=microgateway -c configbuilder -f

    Follow the logs of the Microgateway runtime container.

    copy
    kubectl logs -l app=microgateway -c microgateway -f

    Follow the logs of the Microgateway runtime container and filter for interesting log messages. Mainly these are the log messages with the log_id WR-SG-SUMMARY and WR-SG-BLOCK. Under some circumstances, WR-SG-REJECT or WR-SG-BACK is also very interesting.

    copy
    kubectl logs -l app=microgateway -c microgateway -f | grep -iE "WR-SG-(SUMMARY|BLOCK|REJECT|BACK)"
  13. Requests that belong to the same session have the identical value in the log key sess_id.

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
  3. All relevant Kubernetes resources in the namespace have been deleted successfully.