Protecting a backend service

Overview

Goal

Configure the Microgateway to protect a simple backend service.

Notes

-

Preparation

  1. Deploy the Kubernetes exercise
  2. Run the following commands:
    3. copy
    cd protecting-a-backend-service/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?
    details...
    • The following should be noticed:
    • The request was received by Airlock Microgateway. The log message WR-SG-SUMMARY indicates that.
    • Without a back-end host configured in the config.yaml file, Airlock Microgateway connects to the default back-end which is http://backend:8080.
    • The request is rejected by Airlock Microgateway because there is no back-end reachable/available under this name (log message WR-SG-BACK-502).
  5. Find out the Kubernetes service name which should be protected by Microgateway.
    6. details...
    copy
    kubectl get svc

    The NAME of the Kubernetes service can be configured as back-end host in the Microgateway configuration.

  6. Edit Microgateway's configuration file.

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

    • For the mapping echoserver:
    • backend.name
    • backend.hosts[].name
    • backend.hosts[].protocol
    • backend.hosts[].port

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

    details...

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

    copy
        mappings: 
      - name: echoserver 
        ...
        ...
        backend: 
          name: echoserver 
          hosts: 
            - name: echoserver 
              protocol: http 
              port: 8080
  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. The log message WR-SG-SUMMARY with the key action:allowed indicates that the request has successfully proceeded.

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.