{"id":18332578,"url":"https://github.com/tigera-solutions/cc-aks-security-compliance-workshop","last_synced_at":"2026-07-13T18:32:26.451Z","repository":{"id":152737611,"uuid":"626956379","full_name":"tigera-solutions/cc-aks-security-compliance-workshop","owner":"tigera-solutions","description":"This repository brings a hands-on workshop approach covering the Configuration Security and Compliance for an Azure Kubernetes Service cluster using Calico Cloud.","archived":false,"fork":false,"pushed_at":"2023-04-13T13:50:08.000Z","size":190,"stargazers_count":3,"open_issues_count":0,"forks_count":1,"subscribers_count":1,"default_branch":"main","last_synced_at":"2025-10-30T19:43:33.575Z","etag":null,"topics":["aks","azure","cc","compliance","regismartins","workshop"],"latest_commit_sha":null,"homepage":"","language":null,"has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":null,"status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/tigera-solutions.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":null,"funding":null,"license":null,"code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null}},"created_at":"2023-04-12T13:50:48.000Z","updated_at":"2025-07-13T08:37:00.000Z","dependencies_parsed_at":null,"dependency_job_id":"cff6315c-8846-437a-bdf7-47d12e9907e9","html_url":"https://github.com/tigera-solutions/cc-aks-security-compliance-workshop","commit_stats":null,"previous_names":[],"tags_count":0,"template":false,"template_full_name":null,"purl":"pkg:github/tigera-solutions/cc-aks-security-compliance-workshop","repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/tigera-solutions%2Fcc-aks-security-compliance-workshop","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/tigera-solutions%2Fcc-aks-security-compliance-workshop/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/tigera-solutions%2Fcc-aks-security-compliance-workshop/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/tigera-solutions%2Fcc-aks-security-compliance-workshop/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/tigera-solutions","download_url":"https://codeload.github.com/tigera-solutions/cc-aks-security-compliance-workshop/tar.gz/refs/heads/main","sbom_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/tigera-solutions%2Fcc-aks-security-compliance-workshop/sbom","scorecard":null,"host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":286080680,"owners_count":35432816,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2026-05-26T15:22:16.424Z","status":"online","status_checked_at":"2026-07-13T02:00:06.543Z","response_time":119,"last_error":null,"robots_txt_status":"success","robots_txt_updated_at":"2025-07-24T06:49:26.215Z","robots_txt_url":"https://github.com/robots.txt","online":true,"can_crawl_api":true,"host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":["aks","azure","cc","compliance","regismartins","workshop"],"created_at":"2024-11-05T19:39:26.998Z","updated_at":"2026-07-13T18:32:26.421Z","avatar_url":"https://github.com/tigera-solutions.png","language":null,"funding_links":[],"categories":[],"sub_categories":[],"readme":"# Microsoft Azure: Hands-on AKS workshop \u003c/br\u003e Configuration Security and Compliance\n\nIn this AKS-focused workshop, you will work with Microsoft Azure and Calico Cloud to learn how to design and deploy best practices to secure your Kubernetes environment and achieve compliance with regulatory frameworks such as PCI, SOC2 and GDPR. This 90-minute hands-on lab will guide you from building an AKS cluster, creating a Calico Cloud trial account and registering your AKS cluster to Calico Cloud for configuring and securing it for compliance. A sample application environment is designed to help implement:\n\n- Configuration security including Kubernetes Security Posture Management (KSPM) \n- Security policies for compliance\n- Compliance, evidence, and audit reporting\n\nYou will come away from this workshop with an understanding of how others in your industry are securing and observing cloud-native applications in Microsoft Azure, along with best practices that you can implement in your organization.\n\n---\n\n## Create a cluster an connect it to Calico Cloud.\n\nIf you don't have an AKS cluster created for this workshop, we recommend you create one. You can use the steps described here to create a Calico Cloud compatible AKS cluster to follow along with this workshop.\n\n   - [Azure AKS Cluster Creation - Azure CNI for Calico Cloud](./aks-azurecni.md)\n   \n   \u003e **Connect your cluster to** [Calico Cloud](https://calicocloud.io)\n\n---\n\n## Configure your cluster and install demo applications\n\nConfigure Calico parameters for this workshop, and install and configure demo applications.\n\n1. Clone this repository and change directory to it.\n   \n   ```bash\n   git clone https://github.com/tigera-solutions/cc-aks-security-compliance-workshop.git \u0026\u0026 \\\n   cd cc-aks-security-compliance-workshop\n   ```\n\n2. Apply the yamls in the `pre` directory. Those yamls will setup the context for this workshop.\n\n   ```bash\n   kubectl apply -f pre\n   ```\n\n---\n\n# How Calico supports compliance requirements\n\nTigera’s solutions, Calico Cloud and Calico Enterprise, enable north-south controls such as egress access, east-west controls such as microsegmentation, and enterprise security controls, policy enforcement, and compliance reporting across all Kubernetes distributions in both hybrid and multi-cloud environments. \n\n- [Download the whitepaper: PCI compliance for Hosts, VMs, containers, and Kubernetes](https://www.tigera.io/lp/kubernetes-pci-compliance/)\n- [Download the PCI DSS v4.0 Quick Reference Guide](https://docs-prv.pcisecuritystandards.org/PCI%20DSS/Supporting%20Document/PCI_DSS-QRG-v4_0.pdf)\n\nCalico provides the following features to help achieve PCI compliance.\n\n---\n\n## Access controls\n\nCalico provides methods to enable fine-grained access controls between your microservices and external databases, cloud services, APIs, and other applications that are protected behind a firewall. You can enforce controls from within the cluster using DNS egress policies, from a firewall outside the cluster using the egress gateway. Controls are applied on a fine-grained, per-pod basis.\n\n### Service Graph and Flow Visualizer\n\n| PCI Control # | Requirements| How Calico meets this requirements |\n| --- | --- | --- |\n| 1.1.2, 1.1.3 | Current network diagram that identifies all connections between the CDE (Cardholder Data Environmet) and other networks and systems | • Stay current with the network diagram for in-scope workloads in Kubernetes environments using Calico’s Dynamic Service Graph and flow visualizer |\n\nConnect to Calico Cloud GUI. From the menu select `Service Graph \u003e Default`. Explore the options.\n\n![service_graph](https://user-images.githubusercontent.com/104035488/192303379-efb43faa-1e71-41f2-9c54-c9b7f0538b34.gif)\n\nConnect to Calico Cloud GUI. From the menu select `Service Graph \u003e Flow Visualizations`. Explore the options.\n\n![flow-visualization](https://user-images.githubusercontent.com/104035488/192358472-112c832f-2fd7-4294-b8cc-fec166a9b11e.gif)\n\n\n---\n\n### Zero trust Security\n\n| PCI Control # | Requirements| How Calico meets this requirements |\n| --- | --- | --- |\n| 7.1, 7.2 | Restrict access to cardholder data by business need-to-know | • Use zero trust security features to implement a default-deny model (access to all data services should be specifically allowed; everything else should be denied)\u003cbr\u003e• Follow a zero trust security model and implement least-privilege access (all processes should only be able to access information necessary for their legitimate purpose)\n\nA global default deny policy ensures that unwanted traffic (ingress and egress) is denied by default. Pods without policy (or incorrect policy) are not allowed traffic until appropriate network policy is defined. Although the staging policy tool will help you find incorrect and missing policy, a global deny helps mitigate against other lateral malicious attacks.\n\nBy default, all traffic is allowed between the pods in a cluster. First, let's test connectivity between application components and across application stacks. All of these tests should succeed as there are no policies in place.\n\na. Test connectivity between workloads within each namespace, use dev and default namespaces as example\n\n   ```bash\n   # test connectivity within dev namespace, the expected result is \"HTTP/1.1 200 OK\" \n   kubectl -n dev exec -t centos -- sh -c 'curl -m3 -sI http://nginx-svc 2\u003e/dev/null | grep -i http'\n   ```\n\n   ```bash\n   # test connectivity within default namespace in 8080 port\n   kubectl exec -it $(kubectl -n default get po -l app=frontend -ojsonpath='{.items[0].metadata.name}') \\\n   -c server -- sh -c 'nc -zv recommendationservice 8080'\n   ```\n\nb. Test connectivity across namespaces dev/centos and default/frontend.\n\n   ```bash\n   # test connectivity from dev namespace to default namespace, the expected result is \"HTTP/1.1 200 OK\"\n   kubectl -n dev exec -t centos -- sh -c 'curl -m3 -sI http://frontend.default 2\u003e/dev/null | grep -i http'\n   ```\n\nc. Test connectivity from each namespace dev and default to the Internet.\n\n   ```bash\n   # test connectivity from dev namespace to the Internet, the expected result is \"HTTP/1.1 200 OK\"\n   kubectl -n dev exec -t centos -- sh -c 'curl -m3 -sI http://www.google.com 2\u003e/dev/null | grep -i http'\n   ```\n\n   ```bash\n   # test connectivity from default namespace to the Internet, the expected result is \"HTTP/1.1 200 OK\"\n   kubectl exec -it $(kubectl get po -l app=loadgenerator -ojsonpath='{.items[0].metadata.name}') \\\n   -c main -- sh -c 'curl -m3 -sI http://www.google.com 2\u003e/dev/null | grep -i http'\n   ```\n\nWe recommend that you create a global default deny policy after you complete writing policy for the traffic that you want to allow. Use the stage policy feature to get your allowed traffic working as expected, then lock down the cluster to block unwanted traffic.\n\n1. Create a staged global default deny policy. It will shows all the traffic that would be blocked if it were converted into a deny.\n\n   ```yaml\n   kubectl apply -f - \u003c\u003c-EOF\n   apiVersion: projectcalico.org/v3\n   kind: StagedGlobalNetworkPolicy\n   metadata:\n     name: default-deny\n   spec:\n     order: 2000\n     selector: \"projectcalico.org/namespace in {'dev','default','storefront'}\"\n     types:\n     - Ingress\n     - Egress\n   EOF\n   ```\n\n   The staged policy does not affect the traffic directly but allows you to view the policy impact if it were to be enforced. You can see the deny traffic in staged policy.\n\n\n2. Create other network policies to individually allow the traffic shown as blocked in step 1, until no connections are denied.\n  \n   Apply network policies to your application with explicity allow and deny control.\n\n   ```yaml\n   kubectl apply -f - \u003c\u003c-EOF   \n   apiVersion: projectcalico.org/v3\n   kind: NetworkPolicy\n   metadata:\n     name: default.centos\n     namespace: dev\n   spec:\n     tier: default\n     order: 800\n     selector: app == \"centos\"\n     egress:\n     - action: Allow\n       protocol: TCP\n       destination:\n         selector: app == \"nginx\"\n     types:\n       - Egress\n   EOF\n   ```\n\n   Test connectivity with policies in place.\n\n   a. The only connections between the components within namespaces dev are from centos to nginx, which should be allowed as configured by the policies.\n\n   ```bash\n   # test connectivity within dev namespace, the expected result is \"HTTP/1.1 200 OK\"\n   kubectl -n dev exec -t centos -- sh -c 'curl -m3 -sI http://nginx-svc 2\u003e/dev/null | grep -i http'\n   ```\n   \n   The connections within namespace default should be allowed as usual.\n   \n   ```bash\n   # test connectivity within default namespace in 8080 port\n   kubectl exec -it $(kubectl get po -l app=frontend -ojsonpath='{.items[0].metadata.name}') \\\n   -c server -- sh -c 'nc -zv recommendationservice 8080'\n   ``` \n\n   b. The connections across dev/centos pod and default/frontend pod should be blocked by the application policy.\n   \n   ```bash   \n   # test connectivity from dev namespace to default namespace, the expected result is \"command terminated with exit code 1\"\n   kubectl -n dev exec -t centos -- sh -c 'curl -m3 -sI http://frontend.default 2\u003e/dev/null | grep -i http'\n   ```\n\n   c. Test connectivity from each namespace dev and default to the Internet.\n   \n   ```bash   \n   # test connectivity from dev namespace to the Internet, the expected result is \"command terminated with exit code 1\"\n   kubectl -n dev exec -t centos -- sh -c 'curl -m3 -sI http://www.google.com 2\u003e/dev/null | grep -i http'\n   ```\n   \n   ```bash\n   # test connectivity from default namespace to the Internet, the expected result is \"HTTP/1.1 200 OK\"\n   kubectl exec -it $(kubectl get po -l app=loadgenerator -ojsonpath='{.items[0].metadata.name}') \\\n   -c main -- sh -c 'curl -m3 -sI http://www.google.com 2\u003e/dev/null | grep -i http'\n   ```\n\n   Implement explicitic policy to allow egress access from a workload in one namespace/pod, e.g. dev/centos, to default/frontend.\n   \n   a. Deploy egress policy between two namespaces dev and default.\n\n   ```yaml\n   kubectl apply -f - \u003c\u003c-EOF\n   apiVersion: projectcalico.org/v3\n   kind: NetworkPolicy\n   metadata:\n     name: platform.centos-to-frontend\n     namespace: dev\n   spec:\n     tier: platform\n     order: 100\n     selector: app == \"centos\"\n     egress:\n       - action: Allow\n         protocol: TCP\n         source: {}\n         destination:\n           selector: app == \"frontend\"\n           namespaceSelector: projectcalico.org/name == \"default\"\n       - action: Pass\n     types:\n       - Egress\n   EOF\n   ```\n\n   b. Test connectivity between dev/centos pod and default/frontend service again, should be allowed now.\n\n   ```bash   \n   kubectl -n dev exec -t centos -- sh -c 'curl -m3 -sI http://frontend.default 2\u003e/dev/null | grep -i http'\n   #output is HTTP/1.1 200 OK\n   ```\n\n   Apply the policies to allow the microservices to communicate with each other.\n\n   ```bash\n   kubectl apply -f manifests/east-west-traffic.yaml\n   ```\n\n3. Use the Calico Cloud GUI to enforce the default-deny staged policy. After enforcing a staged policy, it takes effect immediatelly. The default-deny policy will start to actually deny traffic.\n   \n---\n\n### Ingress and Egress access control using NetworkSets\n\n\n| PCI Control # | Requirements| How Calico meets this requirements |\n| --- | --- | --- |\n| 1.3, 1.3.1, 1.3.2, 1.3.3, 1.3.4, 1.3.5, 1.3.7 | Prohibit and/or manage access between internet and CDE | • Whitelist ingress access from the public internet only if the endpoint is providing a publicly accessible service\u003cbr\u003e• Whitelist egress access to the public internet from all in-covered components\u003cbr\u003e• Protect against forged source IP addresses with WireGuard (integrated in Calico)|\n\n1. Implement DNS policy to allow the external endpoint access from a specific workload, e.g. `dev/centos`.\n\n   a. Apply a policy to allow access to `api.twilio.com` endpoint using DNS rule.\n\n   ```yaml\n   kubectl apply -f - \u003c\u003c-EOF\n   apiVersion: projectcalico.org/v3\n   kind: GlobalNetworkPolicy\n   metadata:\n     name: security.external-domain-access\n   spec:\n     tier: security\n     selector: (app == \"centos\" \u0026\u0026 projectcalico.org/namespace == \"dev\")\n     order: 100\n     types:\n       - Egress\n     egress:\n     - action: Allow\n       source:\n         selector: app == 'centos'\n       destination:\n         domains:\n         - '*.twilio.com'\n   EOF\n   ```\n   \n   Test the access to the endpoints:\n\n   ```bash\n   # test egress access to api.twilio.com\n   kubectl -n dev exec -t centos -- sh -c 'curl -m3 -skI https://api.twilio.com 2\u003e/dev/null | grep -i http'\n   ```\n\n   ```bash\n   # test egress access to www.google.com\n   kubectl -n dev exec -t centos -- sh -c 'curl -m3 -skI https://www.google.com 2\u003e/dev/null | grep -i http'\n   ```\n\n   Access to the `api.twilio.com` endpoint should be allowed by the DNS policy and any other external endpoints like `www.google.com` should be denied.\n\n   b. Modify the policy to include `*.google.com` in dns policy and test egress access to www.google.com again.\n\n   ```bash\n   # test egress access to www.google.com again and it should be allowed.\n   kubectl -n dev exec -t centos -- sh -c 'curl -m3 -skI https://www.google.com 2\u003e/dev/null | grep -i http'\n   ```\n\n2. Edit the policy to use a `NetworkSet` with DNS domain instead of inline DNS rule.\n\n   a. Apply a policy to allow access to `api.twilio.com` endpoint using DNS policy.\n\n   Deploy the Network Set\n\n   ```yaml\n   kubectl apply -f - \u003c\u003c-EOF\n   kind: GlobalNetworkSet\n   apiVersion: projectcalico.org/v3\n   metadata:\n     name: allowed-dns\n     labels: \n       type: allowed-dns\n   spec:\n     allowedEgressDomains:\n     - '*.twilio.com'\n   EOF\n   ```\n\n   b. Deploy the DNS policy using the network set\n\n   ```yaml\n   kubectl apply -f - \u003c\u003c-EOF\n   apiVersion: projectcalico.org/v3\n   kind: GlobalNetworkPolicy\n   metadata:\n     name: security.external-domain-access\n   spec:\n     tier: security\n     selector: (app == \"centos\" \u0026\u0026 projectcalico.org/namespace == \"dev\")\n     order: 100\n     types:\n       - Egress\n     egress:\n     - action: Allow\n       destination:\n         selector: type == \"allowed-dns\"\n   EOF\n   ```\n\n   c. Test the access to the endpoints.\n\n   ```bash\n   # test egress access to api.twilio.com\n   kubectl -n dev exec -t centos -- sh -c 'curl -m3 -skI https://api.twilio.com 2\u003e/dev/null | grep -i http'\n   ```\n\n   ```bash\n   # test egress access to www.google.com\n   kubectl -n dev exec -t centos -- sh -c 'curl -m3 -skI https://www.google.com 2\u003e/dev/null | grep -i http'\n   ```\n\n   d. Modify the `NetworkSet` to include `*.google.com` in dns domain and test egress access to www.google.com again.\n\n   ```bash\n   # test egress access to www.google.com again and it should be allowed.\n   kubectl -n dev exec -t centos -- sh -c 'curl -m3 -skI https://www.google.com 2\u003e/dev/null | grep -i http'\n   ```\n\n3. The NetworkSet can also be used to block access from a specific ip address or cidr to an endpoint in your cluster. To demonstrate it, we are going to block the access from your workstation to the Online Boutique frontend-external service.\n\n   a. Test the access to the frontend-external service\n\n   ```bash\n   curl -sI -m3 $(kubectl get svc frontend-external -ojsonpath='{.status.loadBalancer.ingress[0].ip}') | grep -i http\n   ```\n   \n   b. Identify your workstation ip address and store it in a environment variable\n\n   ```bash\n   export MY_IP=$(curl ifconfig.me)\n   ```\n\n   c. Create a NetworkSet with your ip address on it.\n\n   ```yaml\n   kubectl apply -f - \u003c\u003c-EOF\n   kind: GlobalNetworkSet\n   apiVersion: projectcalico.org/v3\n   metadata:\n     name: ip-address-list\n     labels: \n       type: blocked-ips\n   spec:\n     nets:\n     - $MY_IP/32\n   EOF\n   ```\n   \n   d. Create the policy to deny access to the frontend service.\n\n   ```yaml\n   kubectl apply -f - \u003c\u003c-EOF\n   apiVersion: projectcalico.org/v3\n   kind: GlobalNetworkPolicy\n   metadata:\n     name: security.blockep-ips\n   spec:\n     tier: security\n     selector: app == \"frontend\"\n     order: 300\n     types:\n       - Ingress\n     ingress:\n     - action: Deny\n       source:\n         selector: type == \"blocked-ips\"\n       destination: {}\n   EOF\n   ```\n\n   e. Create a global alert for the blocked attempt from the ip-address-list to the frontend.\n\n   ```yaml\n   kubectl apply -f - \u003c\u003c-EOF   \n   apiVersion: projectcalico.org/v3\n   kind: GlobalAlert\n   metadata:\n     name: blocked-ips\n   spec:\n     description: \"A connection attempt from a blocked ip address just happened.\"\n     summary: \"[blocked-ip] ${source_ip} from ${source_name_aggr} networkset attempted to access ${dest_namespace}/${dest_name_aggr}\"\n     severity: 100\n     dataSet: flows\n     period: 1m\n     lookback: 1m\n     query: '(source_name = \"ip-address-list\")'\n     aggregateBy: [dest_namespace, dest_name_aggr, source_name_aggr, source_ip]\n     field: num_flows\n     metric: sum\n     condition: gt\n     threshold: 0\n   EOF\n   ```\n\n   a. Test the access to the frontend-external service. It is blocked now. Wait a few minutes and check the `Activity \u003e Alerts`.\n\n   ```bash\n   curl -sI -m3 $(kubectl get svc frontend-external -ojsonpath='{.status.loadBalancer.ingress[0].ip}') | grep -i http\n   ```\n\n---\n\n### Using Global Threatfeeds to detect and prevent web attacks\n\n\n| PCI Control # | Requirements| How Calico meets this requirements |\n| --- | --- | --- |\n| 6.5, 6.6 | Detect and prevent web attacks | • Use policy to implement fine-grained access controls for services |\n\n1. Protect workloads with GlobalThreatfeed from known bad actors.\n\n   Calicocloud offers [Global Threatfeed](https://docs.tigera.io/reference/resources/globalthreatfeed) resource to prevent known bad actors from accessing Kubernetes pods.\n\n   ```bash\n   kubectl get globalthreatfeeds\n   ```\n\n   \u003eOutput is \n   ```bash\n   NAME                           CREATED AT\n   alienvault.domainthreatfeeds   2021-09-28T15:01:33Z\n   alienvault.ipthreatfeeds       2021-09-28T15:01:33Z\n   ```\n\n   You can get these domain/ip list from yaml file, the url would be:\n\n   ```bash\n   kubectl get globalthreatfeeds alienvault.domainthreatfeeds -ojson | jq -r '.spec.pull.http.url'\n   kubectl get globalthreatfeeds alienvault.ipthreatfeeds -ojson | jq -r '.spec.pull.http.url'\n   ```\n\n   \u003eOutput is \n   ```bash\n   https://installer.calicocloud.io/feeds/v1/domains\n\n   https://installer.calicocloud.io/feeds/v1/ips\n   ```\n\n   1. Deploy the feodo Threatfeed\n\n      ```yaml\n      kubectl apply -f - \u003c\u003c-EOF\n      apiVersion: projectcalico.org/v3\n      kind: GlobalThreatFeed\n      metadata:\n        name: feodo-tracker\n      spec:\n        pull:\n          http:\n            url: https://feodotracker.abuse.ch/downloads/ipblocklist.txt\n        globalNetworkSet:\n          labels:\n            threatfeed: feodo\n      EOF\n      ```\n\n   2. Deploy the policy to block traffic from and to feodo Threatfeed\n\n      ```yaml\n      kubectl apply -f - \u003c\u003c-EOF\n      apiVersion: projectcalico.org/v3\n      kind: GlobalNetworkPolicy\n      metadata:\n        name: security.block-threadfeed\n      spec:\n        tier: security\n        order: 210\n        selector: all()\n        types:\n        - Egress\n        egress:\n        - action: Deny\n          destination:\n            selector: threatfeed == \"feodo\"\n      EOF\n      ```\n\n   3. Confirm and check the tracker threatfeed\n   \n      ```bash\n      kubectl get globalthreatfeeds \n      ```\n   \n      ```bash\n      NAME                           CREATED AT\n      alienvault.domainthreatfeeds   2022-02-11T19:21:26Z\n      alienvault.ipthreatfeeds       2022-02-11T19:21:26Z\n      feodo-tracker                  2022-02-11T22:21:43Z \n      ```\n    \n2. Generate alerts by accessing the IP from `feodo-tracker` list. \n\n   ```bash\n   # try to ping any of the IPs in from the feodo tracker list.\n   FIP=$(kubectl get globalnetworkset threatfeed.feodo-tracker -ojson | jq -r '.spec.nets[0]' | sed -e 's/^\"//' -e 's/\\/32//')\n   kubectl -n dev exec -t netshoot -- sh -c \"ping -c1 $FIP\"\n   ```\n\u003c!--   --\u003e\n3. Generate alerts by accessing the IP from `alienvault.ipthreatfeeds` list. \n\n   ```bash\n   # try to ping any of the IPs in from the ipthreatfeeds list.\n   AIP=$(kubectl get globalnetworkset threatfeed.alienvault.ipthreatfeeds -ojson | jq -r '.spec.nets[0]' | sed -e 's/^\"//' -e 's/\"$//' -e 's/\\/32//')\n   kubectl -n dev exec -t netshoot -- sh -c \"ping -c1 $AIP\"\n   ```\n\n4. Confirm you are able to see the alerts in alert list. \n\n---\n\n## Microsegmentation\n\nCalico eliminates the risks associated with lateral movement in the cluster to prevent access to sensitive data and other assets. Calico provides a unified, cloud-native segmentation model and single policy framework that works seamlessly across multiple application and workload environments. It enables faster response to security threats\nwith a cloud-native architecture that can dynamically enforce security policy changes across cloud environments in milliseconds in response to an attack.\n\n\n| PCI Control # | Requirements| How Calico meets this requirements |\n| --- | --- | --- |\n|1.1, 1.1.4, 1.1.6, 1.2.1, 1.2.2, 1.2.3 | Install and maintain a firewall configuration to protect cardholder data | • Identify everything covered by PCI requirements with a well-defined label (e.g. PCI=true)\u003cbr\u003e• Block all traffic between PCI and non-PCI workloads\u003cbr\u003e• Whitelist all traffic within PCI workloads |\n\n \n### Microsegmentation using label PCI = true on a namespace\n\n1. For the microsegmentation deploy a new example application\n\n   ```bash\n   kubectl apply -f manifests/storefront-pci.yaml\n   ```\n\n2. Verify that all the workloads has the label `PCI=true`.\n\n   ```bash\n   kubectl get pods -n storefront --show-labels\n   ```\n\n3. Create a policy that only allows endpoints with label PCI=true to communicate.\n\n   ```yaml\n   kubectl apply -f - \u003c\u003c-EOF\n   apiVersion: projectcalico.org/v3\n   kind: GlobalNetworkPolicy\n   metadata:\n     name: security.pci-whitelist\n   spec:\n     tier: security\n     order: 120\n     namespaceSelector: kubernetes.io/metadata.name == \"storefront\"\n     ingress:\n       - action: Allow\n         source:\n           selector: PCI == \"true\"\n         destination:\n           selector: PCI == \"true\"\n     egress:\n       - action: Allow\n         source:\n           selector: PCI == \"true\"\n         destination:\n           selector: PCI == \"true\"\n     types:\n       - Ingress\n       - Egress\n   EOF\n   ```\n\nNow only the pods labeled with PCI=true will be able to exchange information. Note that you can use different labels to create any sort of restrictions for the workloads communications.\n\n---\n\n## IDS/IPS\n\nCalico pinpoints the source of malicious activity, uses machine learning to identify anomalies, creates a security moat\naround critical workloads, deploys honeypods to capture zero-day attacks, and automatically quarantines potentially\nmalicious workloads to thwart an attack. It monitors inbound and outbound traffic (north-south) and east-west traffic\nthat is traversing the cluster environment. Calico provides threat feed integration and custom alerts, and can be\nconfigured to trigger automatic remediation.\n\n\n| PCI Control # | Requirements| How Calico meets this requirements |\n| --- | --- | --- |\n| 5.1, 5.2, 5.3, 5.4, 10.6, 11.4 | Protect all systems against malware with Intrusion Detection Systems (IDS)/Intrusion Prevention Systems (IPS) and network monitoring. Regularly update antivirus software. Review logs for anomalous and suspicious activity | • Detect and address anomalies and threats with Calico instead of antivirus software \u003cbr\u003e• Report and analyze compliance audit findings with Calico\u003cbr\u003e• Automatically quarantine compromised workloads\u003cbr\u003e• Get insights into statistical and behavioral anomalies with Calico flow logs\n\n---\n\nDPI / IDS\n\n### Deep Packet Inspection\n\n1. Create the DPI and the Intrusion Detection for the dev/nginx service.\n   ```yaml\n   kubectl apply -f - \u003c\u003c-EOF\n   apiVersion: projectcalico.org/v3\n   kind: DeepPacketInspection\n   metadata:\n     name: dpi-nginx\n     namespace: dev\n   spec:\n     selector: app == \"nginx\"\n   ---\n   apiVersion: operator.tigera.io/v1\n   kind: IntrusionDetection\n   metadata:\n     name: tigera-secure\n   spec:\n     componentResources:\n     - componentName: DeepPacketInspection\n       resourceRequirements:\n         limits:\n           cpu: \"1\"\n           memory: 1Gi\n         requests:\n           cpu: 100m\n           memory: 100Mi\n   EOF\n   ```\n\n2. Attack the nginx service\n\n   [Sid 1-21562 - MALWARE-CNC Win.Trojan.Bredolab variant outbound connection](https://www.snort.org/rule_docs/1-21562) \n   ```bash\n   kubectl -n dev exec -t netshoot -- sh -c \"curl -m2 http://nginx-svc/ -H 'User-Agent: Mozilla/4.0' -XPOST --data-raw 'smk=1234'\"\n   ```\n\n   [Sid 1-57461 - MALWARE-BACKDOOR Perl.Backdoor.PULSECHECK variant cnc connection](https://www.snort.org/rule_docs/1-57461)\n   ```bash\n   kubectl -n dev exec -t netshoot -- sh -c \"curl -m2 http://nginx-svc/secid_canceltoken.cgi -H 'X-CMD: Test' -H 'X-KEY: Test' -XPOST\"\n   ```\n\n   [Sid 1-1002 - SERVER-IIS cmd.exe access](https://www.snort.org/rule_docs/1-1002)\n   ```bash\n   kubectl -n dev exec -t netshoot -- sh -c \"curl -m2 http://nginx-svc/cmd.exe\"\n   ```\n   \n   [Sid 1-2585 - SERVER-WEBAPP nessus 2.x 404 probe](https://www.snort.org/rule_docs/1-2585)  \n   ```bash\n   kubectl -n dev exec -t netshoot -- sh -c \"curl -m2 http://nginx-svc/NessusTest\"\n   ```\n   \n   [Check the Snort Id here!](https://www.snort.org/search)\n\n---\n\n## Policy lifecycle management\n\n\nWith Calico, teams can create, preview, and deploy security policies based on the characteristics and metadata\nof a workload. These policies can provide an automated and scalable way to manage and isolate workloads for\nsecurity and compliance, in adherence with PCI compliance requirements. You can automate a validation step that\nensures your security policy works properly before being committed. Calico can deploy your policies in a “staged”\nmode that will display which traffic is being allowed or denied before the policy rule is enforced. The policy can then\nbe committed if it is operating properly. This step avoids any potential problems caused by incorrect, incomplete, or\nconflicting security policy definitions.\n\n\n| PCI Control # | Requirements| How Calico meets this requirements |\n| --- | --- | --- |\n| 1.1.1, 1.1.5, 1.1.7 | A formal process for approving and testing all network connections and changes to the rule sets | • Use Calico to record and review all policy changes that affect connectivity between covered components |\n| 10.1, 10.2, 10.3 | Implement and record audit trail for all access to system components | • Record all policy changes that impact connectivity to/from in-scope assets with Calico |\n\n1. Open a policy and check the change log\n\n![change-log](https://user-images.githubusercontent.com/104035488/192361358-33ad8ab4-0c86-4892-a775-4d3bfc72ba38.gif)\n\n---\n\n## Encryption\n\nCalico’s data-in-transit encryption provides category-leading performance and lower CPU utilization than legacy\napproaches based on IPsec and OpenVPN tunneling protocols. No matter where a threat originates, data encrypted\nby Calico is unreadable to anyone except the legitimate keyholder, thus protecting sensitive data should a perimeter\nbreach occur. It enables compliance with corporate and regulatory data protection requirements, such as PCI, that\nspecify the use of encryption. Calico’s encryption is 6X faster than any other solution on the market.\n\n| PCI Control # | Requirements| How Calico meets this requirements |\n| --- | --- | --- |\n| 4.1 | Data-in-transit encryption to safeguard sensitive data | • Secure and encrypt data in transit for all covered workloads|\n\n\n1. On AKS, the WireGuard is already installed in Ubuntu nodes.\n\n2. Enable WireGuard for the cluster\n\n   ```bash\n   kubectl patch felixconfiguration default --type='merge' -p '{\"spec\":{\"wireguardEnabled\":true}}'\n   ```\n\n3. Verify if enabled\n\n   ```bash\n   NODENAME=$(kubectl get nodes -o=jsonpath='{.items[0].metadata.name}')\n   kubectl get node $NODENAME -o yaml | grep -B2 -A5 annotation\n   ```\n\n4. Enable stats collection\n\n   ```bash\n   kubectl patch installation.operator.tigera.io default --type merge -p '{\"spec\":{\"nodeMetricsPort\":9091}}'\n   ```\n\n5. Apply Service, ServiceMonitor, NetworkPolicy manifests:\n\n   ```bash\n   kubectl apply -f manifests/wireguard-stats.yaml\n   ```\n\n6. Disable WireGuard for the cluster\n   ```bash\n   kubectl patch felixconfiguration default --type='merge' -p '{\"spec\":{\"wireguardEnabled\":false}}'\n   ```\n\n---\n\n## Compliance Reports\n\nContinuous compliance means employing a continual audit that shows what traffic was allowed in your infrastructure,\nwhat traffic was denied and why, and logs of who was trying to change what and whether those changes went into\neffect. Continuous compliance gives teams the ability to pinpoint any point in time and say with reasonable certainty\nwhether the organization was in compliance—and provide documentation to prove it. Calico’s compliance reports\nvisually describe the security controls in place in an easy-to-understand policy view. Calico also shows all workloads\nthat are in-scope and out-of-scope with your policy.\n\n\n| PCI Control # | Requirements| How Calico meets this requirements |\n| --- | --- | --- |\n| 2.2, 2.4 | Inventory the systems and make sure they meet industry-accepted system-hardening standards | • Keep a running inventory of all ephemeral workloads along with their networking and security controls\u003cbr\u003e• Leverage inventory report and CIS|\n\n1. On the Calico Cloud GUI, navigate to `Compliance`.\n\n![compliance-reports](https://user-images.githubusercontent.com/104035488/192358634-c873ffb5-f874-495f-8ba4-79806ff84654.gif)\n\n\n2. Explore the Compliance Reports.\n\n![cis-benchmark](https://user-images.githubusercontent.com/104035488/192358645-ab77c305-0a9d-4242-b37f-972dc22b4d84.gif)\n\n---\n\n# Thank you!\n\n--- \n\n**Useful links**\n\n- [Project Calico](https://www.tigera.io/project-calico/)\n- [Calico Academy - Get Calico Certified!](https://academy.tigera.io/)\n- [O’REILLY EBOOK: Kubernetes security and observability](https://www.tigera.io/lp/kubernetes-security-and-observability-ebook)\n- [Calico Users - Slack](https://slack.projectcalico.org/)\n\n**Follow us on social media**\n\n- [LinkedIn](https://www.linkedin.com/company/tigera/)\n- [Twitter](https://twitter.com/tigeraio)\n- [YouTube](https://www.youtube.com/channel/UC8uN3yhpeBeerGNwDiQbcgw/)\n- [Slack](https://calicousers.slack.com/)\n- [Github](https://github.com/tigera-solutions/)\n- [Discuss](https://discuss.projectcalico.tigera.io/)\n\n---\n\n[:arrow_up: Back to the top](/README.md#microsoft-azure-hands-on-aks-workshop--configuration-security-and-compliance)","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Ftigera-solutions%2Fcc-aks-security-compliance-workshop","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Ftigera-solutions%2Fcc-aks-security-compliance-workshop","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Ftigera-solutions%2Fcc-aks-security-compliance-workshop/lists"}