diff --git a/README.md b/README.md index 9717ce5544..91b27cc03d 100644 --- a/README.md +++ b/README.md @@ -1,4 +1,4 @@ -# README +# KubeArmor ## Introduction to KubeArmor @@ -44,15 +44,15 @@ KubeArmor aims to protect containers themselves rather than interactions among c Please take a look at the following documents. -1. [Deployment Guide](documentation/deployment_guide.md) -2. [Security Policy Specification](documentation/security_policy_specification.md) -3. [Security Policy Examples](documentation/security_policy_examples.md) -4. [Technical Roadmap](documentation/technical_roadmap.md) +1. [Deployment Guide](getting-started/deployment_guide.md) +2. [Security Policy Specification](getting-started/security_policy_specification.md) +3. [Security Policy Examples](getting-started/security_policy_examples.md) +4. [Technical Roadmap](contribution/technical_roadmap.md) If you want to make a contribution, please refer to the following documents too. -1. [Contribution Guide](documentation/contribution_guide.md) -2. [Development Guide](documentation/development_guide.md) +1. [Contribution Guide](contribution/contribution_guide.md) +2. [Development Guide](contribution/development_guide.md) ## Community @@ -64,3 +64,4 @@ If you want to make a contribution, please refer to the following documents too. KubeArmor is licensed under the Apache License, Version 2.0. The eBPF-based container monitor is licensed under the General Public License, Version 2.0. + diff --git a/SUMMARY.md b/SUMMARY.md index 1275b75ed6..ecaa2acdd5 100644 --- a/SUMMARY.md +++ b/SUMMARY.md @@ -1,26 +1,29 @@ # Table of contents +* [KubeArmor](README.md) + ## Getting Started - * [Deployment Guide](documentation/deployment_guide.md) - * [Security Policy Specification](documentation/security_policy_specification.md) - * [Security Policy Examples](documentation/security_policy_examples.md) - * [Consideration in Policy Action](documentation/consideration_in_policy_action.md) +* [Deployment Guide](getting-started/deployment_guide.md) +* [Security Policy Specification](getting-started/security_policy_specification.md) +* [Security Policy Examples](getting-started/security_policy_examples.md) +* [Consideration in Policy Action](getting-started/consideration_in_policy_action.md) ## Contribution - * [Contribution Guide](documentation/contribution_guide.md) - * [Development Guide](documentation/development_guide.md) - * [Docker and Kubernetes Installation](documentation/k8s_installation_guide.md) - * [Technical Roadmap](documentation/technical_roadmap.md) +* [Contribution Guide](contribution/contribution_guide.md) +* [Development Guide](contribution/development_guide.md) +* [Docker and Kubernetes Installation](contribution/k8s_installation_guide.md) +* [Technical Roadmap](contribution/technical_roadmap.md) ## Examples - * [Multiubuntu](examples/multiubuntu.md) - * [Sock-Shop](examples/sock-shop.md) - * [Wordpress-MySQL](examples/wordpress-mysql.md) +* [Multiubuntu](examples/multiubuntu.md) +* [Sock-Shop](examples/sock-shop.md) +* [Wordpress-MySQL](examples/wordpress-mysql.md) ## Reference - * [Supported Capability List](documentation/supported_capability_list.md) - * [Supported Operation List](documentation/supported_operation_list.md) +* [Supported Capability List](reference/supported_capability_list.md) +* [Supported Operation List](reference/supported_operation_list.md) + diff --git a/documentation/contribution_guide.md b/contribution/contribution_guide.md similarity index 99% rename from documentation/contribution_guide.md rename to contribution/contribution_guide.md index a7b3778534..1d329b08f5 100644 --- a/documentation/contribution_guide.md +++ b/contribution/contribution_guide.md @@ -65,3 +65,4 @@ If you want to make a contribution, please follow the steps below. Finally, click the "Create pull request" button. Now, please let us review your code. We will merge all your changes into the master branch of KubeArmor. Once your changes are merged, you will get a notification, and the issue that you fixed will be closed as well. + diff --git a/documentation/development_guide.md b/contribution/development_guide.md similarity index 51% rename from documentation/development_guide.md rename to contribution/development_guide.md index 9661ca4df9..f019d87545 100644 --- a/documentation/development_guide.md +++ b/contribution/development_guide.md @@ -3,7 +3,6 @@ ## Development 1. Self-managed Kubernetes - * Requirements Here is the list of requirements for self-managed Kubernetes. @@ -19,14 +18,14 @@ Note that KubeArmor does not work on MiniKube because MiniKube does not support AppArmor. In addition, KubeArmor does not work with Docker Desktops on Windows and MacOS because such engines do not have a full Linux file system. - * \(Optional\) MicroK8s Setup + * \(Optional\) MicroK8s Setup - In order to install MicroK8s, please run the following command. + In order to install MicroK8s, please run the following command. - ```text - $ cd contributions/bare-metal/microk8s - (microk8s) $ ./install_microk8s.sh - ``` + ```text + $ cd contributions/bare-metal/microk8s + (microk8s) $ ./install_microk8s.sh + ``` * Environmetal Setup @@ -40,9 +39,7 @@ [setup.sh](https://github.com/accuknox/KubeArmor/blob/master/contributions/bare-metal/setup.sh) will automatically install BCC \(latest\), Go \(v1.15.2\), and Protobuf \(3.14.0\). Now, you are ready to develop any code for KubeArmor. Enjoy your journey with KubeArmor. - 2. Vagrant Environment - * Requirements Here is the list of requirements for a Vagrant environment @@ -59,74 +56,75 @@ (vagrant) $ ./setup.sh ``` - * VM Setup using Vagrant + * VM Setup using Vagrant - If you do not have ssh keys in '~/.ssh' yet, you need to run the following command in advance. + If you do not have ssh keys in '~/.ssh' yet, you need to run the following command in advance. - ```text - (vagrant) $ ssh-keygen -> [Enter] -> [Enter] -> [Enter] - ``` + ```text + (vagrant) $ ssh-keygen -> [Enter] -> [Enter] -> [Enter] + ``` - Now, it is time to create a VM for development. You can directly use the vagrant command to create a VM. + Now, it is time to create a VM for development. You can directly use the vagrant command to create a VM. - ```text - (vagrant) $ vagrant up - ``` + ```text + (vagrant) $ vagrant up + ``` - If you want to remove the created VM, please run the following command. + If you want to remove the created VM, please run the following command. - ```text - (vagrant) $ vagrant destroy - ``` + ```text + (vagrant) $ vagrant destroy + ``` - You are ready to develop the code for KubeArmor. Enjoy your journey with KubeArmor. + You are ready to develop the code for KubeArmor. Enjoy your journey with KubeArmor. - ```text - (vagrant) $ vagrant ssh - ``` + ```text + (vagrant) $ vagrant ssh + ``` ## Code Directories Here, we briefly give you the overview of KubeArmor's directories. - * Source code for KubeArmor \(/KubeArmor\) +* Source code for KubeArmor \(/KubeArmor\) + + ```text + KubeArmor/ + common - Libraries internally used + core - The main body (start point) of KubeArmor + discovery - Automated security policy discovery (under development) + enforcer - Runtime policy enforcer (enforcing security policies into LSMs) + feeder - gRPC-based feeder (sending audit/system logs to a log server) + monitor - eBPF-based container monitor (mapping process IDs to container IDs) + BPF - eBPF code for container monitor + log - Message logger (stdout) for KubeArmor + types - Type definitions + protobuf/ - Protocol buffer + ``` - ```text - KubeArmor/ - common - Libraries internally used - core - The main body (start point) of KubeArmor - discovery - Automated security policy discovery (under development) - enforcer - Runtime policy enforcer (enforcing security policies into LSMs) - feeder - gRPC-based feeder (sending audit/system logs to a log server) - monitor - eBPF-based container monitor (mapping process IDs to container IDs) - BPF - eBPF code for container monitor - log - Message logger (stdout) for KubeArmor - types - Type definitions - protobuf/ - Protocol buffer - ``` +* Source code for KubeArmor's log client - * Source code for KubeArmor's log client + ```text + LogClient/ - gRPC-based log server + protobuf/ - Protocol buffer + ``` - ```text - LogClient/ - gRPC-based log server - protobuf/ - Protocol buffer - ``` +* Source code for KubeArmor's custom resource defintion \(CRD\) - * Source code for KubeArmor's custom resource defintion \(CRD\) + ```text + pkg/k8s/ - CRD Code generated by Kube-Builder + ``` - ```text - pkg/k8s/ - CRD Code generated by Kube-Builder - ``` +* Scripts for GKE - * Scripts for GKE + ```text + GKE/ - scripts to set up the enforcer in a container-optimized OS (COS) + ``` - ```text - GKE/ - scripts to set up the enforcer in a container-optimized OS (COS) - ``` +* Files for testing - * Files for testing + ```text + examples/ - Example microservices for testing + tests/ - Automated test framework for KubeArmor + ``` - ```text - examples/ - Example microservices for testing - tests/ - Automated test framework for KubeArmor - ``` diff --git a/documentation/k8s_installation_guide.md b/contribution/k8s_installation_guide.md similarity index 97% rename from documentation/k8s_installation_guide.md rename to contribution/k8s_installation_guide.md index 5461874951..febe6c0a1a 100644 --- a/documentation/k8s_installation_guide.md +++ b/contribution/k8s_installation_guide.md @@ -1,4 +1,4 @@ -# Self-managed Kubernetes Installation +# Docker and Kubernetes Installation * Requirements @@ -61,3 +61,4 @@ ```text $ sudo kubeadm ... (the command that you get from the master node) ``` + diff --git a/documentation/technical_roadmap.md b/contribution/technical_roadmap.md similarity index 55% rename from documentation/technical_roadmap.md rename to contribution/technical_roadmap.md index f95a6bdd66..f5cd38a8b3 100644 --- a/documentation/technical_roadmap.md +++ b/contribution/technical_roadmap.md @@ -3,33 +3,25 @@ Here, we briefly share a plan for next releases \(e.g., including features, specs, and platform supports\). * Current Release - * Kubernetes Environments - - - Self-managed Kubernetes \(using kubeadm), MicroK8s, Google Kubernetes Engine \(GKE\) - + * Self-managed Kubernetes \(using kubeadm\), MicroK8s, Google Kubernetes Engine \(GKE\) * Container Platforms - - - Docker, Containerd - + * Docker, Containerd * LSM Supports - - - AppArmor - + * AppArmor * Features - - Monitor container behaviors at the system level - - - Enforce security policies against: + * Monitor container behaviors at the system level + * Enforce security policies against: ```text Process executions File accesses Network operations - Capabilities permitted + Capabilities permitted ``` - - Produce container-aware audit logs and system logs \(for failed system calls\) and write them into: + * Produce container-aware audit logs and system logs \(for failed system calls\) and write them into: ```text Standard output @@ -38,29 +30,25 @@ Here, we briefly share a plan for next releases \(e.g., including features, spec ``` * Next Release * Kubernetes Environments - - - \(extension\) Amazon Elastic Kubernetes Service \(EKS\), Azure Kubernetes Service \(AKS\) - + * \(extension\) Amazon Elastic Kubernetes Service \(EKS\), Azure Kubernetes Service \(AKS\) * LSM Supports - - - \(extension\) KRSI \(requiring Linux kernel v5.8 or newer\) - + * \(extension\) KRSI \(requiring Linux kernel v5.8 or newer\) * Features - - \(extension\) Produce container-aware logs and write them into: + * \(extension\) Produce container-aware logs and write them into: ```text Database (e.g., MySQL and MongoDB) ``` - - Automatically generate security policies for given containers against: + * Automatically generate security policies for given containers against: ```text Process executions - Files accesses + Files accesses ``` - - Enforce security policies \(using KRSI\) against: + * Enforce security policies \(using KRSI\) against: ```text Process executions @@ -69,30 +57,27 @@ Here, we briefly share a plan for next releases \(e.g., including features, spec Capabilities permitted ``` - - Produce telemetry data to monitoring systems + * Produce telemetry data to monitoring systems ```text Prometheus ``` * Future Releases * Container Platforms - - - \(extension\) Podman - + * \(extension\) Podman * LSM Supports - - - \(extension\) SELinux - + * \(extension\) SELinux * Features - - Produce container-aware logs and write them into: + * Produce container-aware logs and write them into: ```text Other systems (e.g., Kafka and Elasticsearch) ``` - - Enforce security policies against inter-container communications at the network level + * Enforce security policies against inter-container communications at the network level ```text Integration with network security solutions (e.g., Cilium) ``` + diff --git a/examples/sock-shop.md b/examples/sock-shop.md index 44fd9ff8b6..db64845609 100644 --- a/examples/sock-shop.md +++ b/examples/sock-shop.md @@ -8,3 +8,4 @@ To deploy the sock-shop microservice, please run the following commands. $ cd examples/sock-shop (examples/sock-shop) $ kubectl apply -f . ``` + diff --git a/examples/wordpress-mysql.md b/examples/wordpress-mysql.md index b7feb69dbd..eb5b631f8b 100644 --- a/examples/wordpress-mysql.md +++ b/examples/wordpress-mysql.md @@ -8,3 +8,4 @@ To deploy the wordpress-mysql microservice, please run the following commands. $ cd examples/wordpress-mysql (examples/wordpress-mysql) $ kubectl apply -f . ``` + diff --git a/documentation/consideration_in_policy_action.md b/getting-started/consideration_in_policy_action.md similarity index 99% rename from documentation/consideration_in_policy_action.md rename to getting-started/consideration_in_policy_action.md index 78141132dc..b8c8db27c9 100644 --- a/documentation/consideration_in_policy_action.md +++ b/getting-started/consideration_in_policy_action.md @@ -7,3 +7,4 @@ If the actions of all security policies for a container are 'Block', then these Here, we introduce an example of how security policies are handled differently. There are two pods: pod A with \(grp=1, role=A\) and pod B with \(grp=1, role=B\). Let us say that an operator wants to block the execution of a bash shell in those pods, so the operator first defines a policy with \(selector → grp=1, process → /bin/bash, action → block\). Then, /bin/bash cannot be executed in the pods while some other applications are still executable \(blacklist\). After that, let us say that the operator also wants for the pods with role=A to execute /app only. Then, this policy will be enforced into Pod A. At this point, a problem may occur. Since Pod A has an 'Allow' policy and a 'Block' policy together, the way to handle those policies is changed from a blacklist manner to a whitelist manner, which means that Pod A will be only able to execute /app. Here, if Pod A needs to only run /app, then everything will be fine. However, what if Pod A had to implicitly execute some other applications \(e.g., /agent\)? Then, there will be a severe problem since all applications except for /app will be blocked in Pod A. + diff --git a/documentation/deployment_guide.md b/getting-started/deployment_guide.md similarity index 99% rename from documentation/deployment_guide.md rename to getting-started/deployment_guide.md index 14f3ec8df2..206f74fa2d 100644 --- a/documentation/deployment_guide.md +++ b/getting-started/deployment_guide.md @@ -52,3 +52,4 @@ ```text Coming soon ``` + diff --git a/documentation/security_policy_examples.md b/getting-started/security_policy_examples.md similarity index 99% rename from documentation/security_policy_examples.md rename to getting-started/security_policy_examples.md index 8deb640775..4ddad253c7 100644 --- a/documentation/security_policy_examples.md +++ b/getting-started/security_policy_examples.md @@ -3,7 +3,6 @@ Here, we demonstrate how to define security policies using our example microservice \(multiubuntu\). * Process Execution Restriction - * Block a specific executable \([ksp-group-1-proc-path-block.yaml](https://github.com/accuknox/KubeArmor/tree/master/examples/multiubuntu/security-policies/ksp-group-1-proc-path-block.yaml)\) ```text @@ -25,7 +24,6 @@ Here, we demonstrate how to define security policies using our example microserv ``` * Explanation: The purpose of this policy is to block the execution of '/bin/sleep' in the containers with the 'group-1' label. For this, we define the 'group-1' label in selector -> matchLabels and the specific path \('/bin/sleep'\) in process -> matchPaths. Also, we put 'Block' as the action of this policy. - * Verification: After applying this policy, please get into one of the containers with the 'group-1' \(using "kubectl -n multiubuntu exec -it ubuntu-X-deployment-... -- bash"\) and run '/bin/sleep'. You will see that /bin/sleep is blocked. * Block all executables in a specific directory \([ksp-ubuntu-1-proc-dir-block.yaml](https://github.com/accuknox/KubeArmor/tree/master/examples/multiubuntu/security-policies/ksp-ubuntu-1-proc-dir-block.yaml)\) @@ -49,7 +47,6 @@ Here, we demonstrate how to define security policies using our example microserv ``` * Explanation: The purpose of this policy is to block all executables in the '/sbin' directory. Since we want to block all executables rather than a specific executable, we use matchDirectories to specify the executables in the '/sbin' directory at once. - * Verification: After applying this policy, please get into the container with the 'ubuntu-1' label and run '/sbin/route' to see if this command is allowed \(this command will be blocked\). * Block all executables in a specific directory and its subdirectories \([ksp-ubuntu-2-proc-dir-recursive-block.yaml](https://github.com/accuknox/KubeArmor/tree/master/examples/multiubuntu/security-policies/ksp-ubuntu-2-proc-dir-recursive-block.yaml)\) @@ -74,7 +71,6 @@ Here, we demonstrate how to define security policies using our example microserv ``` * Explanation: As the extension of the previous policy, we want to block all executables in the '/usr' directory and its subdirectories \(e.g., '/usr/bin', '/usr/sbin', and '/usr/local/bin'\). Thus, we add 'recursive: true' to extend the scope of the policy. - * Verification: After applying this policy, please get into the container with the 'ubuntu-2' label and run '/usr/bin/env' or '/usr/bin/whoami'. You will see that those commands are blocked. * Allow specific executables only \([ksp-ubuntu-3-proc-dir-allow.yaml](https://github.com/accuknox/KubeArmor/tree/master/examples/multiubuntu/security-policies/ksp-ubuntu-3-proc-dir-allow.yaml)\) @@ -102,7 +98,6 @@ Here, we demonstrate how to define security policies using our example microserv ``` * Explanation: Unlike the previous policies, we want the container with the 'ubuntu-3' label only to execute specific executables. To achieve this goal, we first define the scope of this policy using matchDirectories \(you can also use matchPaths\). Then, we define the 'Allow' action instead of the 'Block' action. - * Verification: In this policy, we allow some files \(i.e., /credentials/\*\) for verification. After applying this policy, please get into the container with the 'ubuntu-3' label and run 'cd /credentials', 'ls', and 'cat /credentials/password'. You will see that all of the binaries in /bin work well. Now, please simply run 'awk' or 'diff'. Then, those commands will be blocked since they are in /usr/bin. * Allow a specific executable to be launched by its owner only \([ksp-ubuntu-3-proc-path-owner-only.yaml](https://github.com/accuknox/KubeArmor/tree/master/examples/multiubuntu/security-policies/ksp-ubuntu-3-proc-path-owner-only.yaml)\) @@ -136,11 +131,8 @@ Here, we demonstrate how to define security policies using our example microserv ``` * Explanation: This policy aims to allow a specific user \(i.e., user1\) only to launch its own executable \(i.e., hello\), which means that we do not want for the root user to even launch /home/user1/hello. For this, we define a security policy similar to the above ones, but we specifically add 'ownerOnly: true'. - * Verification: For verification, we allow /bin/su and some files used by /bin/su to change users \(from 'root' to 'user1'\) in the policy. After applying this policy, please get into the container with the 'ubuntu-3' label and run '/home/user1/hello' first. This command will be blocked even though you are the 'root' user. Then, please run 'su - user1'. Now, you are the 'user1' user. Please run '/home/user1/hello' again. You will see that it works now. - * File Access Restriction - * Allow accessing specific files only \([ksp-ubuntu-4-file-path-readonly-allow.yaml](https://github.com/accuknox/KubeArmor/tree/master/examples/multiubuntu/security-policies/ksp-ubuntu-4-file-path-readonly-allow.yaml)\) ```text @@ -167,7 +159,6 @@ Here, we demonstrate how to define security policies using our example microserv ``` * Explanation: The purpose of this policy is to allow the container with the 'ubuntu-4' label to access '/secret.txt' and '/credentials/password' only. We also want the container to read '/credentials/password' only \(the write operation is blocked\) while allowing the container to read and write '/secret.txt'. - * Verification: For testing, we allow binaries in /bin. After applying this policy, please get into the container with the 'ubuntu-4' label and run 'cat /secret.txt' and 'cat /credentials/password'. You can see the contents in those files. Now, please run 'echo \"test\" >> /secret.txt'. This command will work fine. Please run 'echo \"test\" >> /credentials/password'. You will see that the write operation will be blocked. * Block all file accesses in a specific directory and its subdirectories \([ksp-ubuntu-5-file-dir-recursive-block.yaml](https://github.com/accuknox/KubeArmor/tree/master/examples/multiubuntu/security-policies/ksp-ubuntu-5-file-dir-recursive-block.yaml)\) @@ -192,11 +183,8 @@ Here, we demonstrate how to define security policies using our example microserv ``` * Explanation: In this policy, we do not want the container with the 'ubuntu-5' label to access any files in the '/credentials' directory and subdirectories. Thus, we use 'matchDirectories' and 'recursive: true' to define all files in the '/credentials' directory and its subdirectories. - * Verification: After applying this policy, please get into the container with the 'ubuntu-5' label and run 'cat /secret.txt'. You will see the contents of /secret.txt. Then, please run 'cat /credentials/password'. This command will be blocked due to the security policy. - * Network Operation Restriction - * Block ICMP packets \([ksp-ubuntu-5-net-icmp-block](https://github.com/accuknox/KubeArmor/tree/master/examples/multiubuntu/security-policies/ksp-ubuntu-5-net-icmp-block.yaml)\) ```text @@ -218,11 +206,8 @@ Here, we demonstrate how to define security policies using our example microserv ``` * Explanation: We want to block sending ICMP packets from the containers with the 'ubuntu-5' label while allowing packets for the other protocols \(e.g., TCP and UDP\). For this, we use 'matchProtocols' to define the protocol \(i.e., ICMP\) that we want to block. - * Verification: After applying this policy, please get into the container with the 'ubuntu-5' label and run 'curl www.accuknox.com'. This will work fine. Then, please run 'ping 8.8.8.8'. You will see 'permission denied' since the 'ping' command internally uese the ICMP protocol. - * Capabilities Restriction - * Block Raw Sockets \(i.e., non-TCP/UDP packets\) \([ksp-ubuntu-1-cap-net-raw-block.yaml](https://github.com/accuknox/KubeArmor/tree/master/examples/multiubuntu/security-policies/ksp-ubuntu-1-cap-net-raw-block.yaml)\) ```text @@ -244,5 +229,5 @@ Here, we demonstrate how to define security policies using our example microserv ``` * Explanation: We want to block any network operations using raw sockets from the containers with the 'ubuntu-2' label, meaning that containers cannot send non-TCP/UDP packets \(e.g., ICMP echo request or reply\) to other containers. To achieve this, we use matchCapabilities and specify the 'CAP\_NET\_RAW' capability to block raw socket creations inside the containers. Here, since we use stream and datagram sockets to TCP and UDP packets respectively, we can still send those packets to others. - * Verification: After applying this policy, please get into the container with the 'ubuntu-1' label and run 'curl www.accuknox.com'. This will work fine. Then, please run 'ping 8.8.8.8'. You will see 'operation not permitted' since the 'ping' command internally requires a raw socket to send ICMP packets. + diff --git a/documentation/security_policy_specification.md b/getting-started/security_policy_specification.md similarity index 96% rename from documentation/security_policy_specification.md rename to getting-started/security_policy_specification.md index 8d06e2cdb9..cb5a7f5b48 100644 --- a/documentation/security_policy_specification.md +++ b/getting-started/security_policy_specification.md @@ -107,7 +107,7 @@ Now, we will briefly explain how to define a security policy. * Selector - The selector part is relatively straightforward. Similar to other Kubernetes configurations, you can specify (a group of) pods based on labels. + The selector part is relatively straightforward. Similar to other Kubernetes configurations, you can specify \(a group of\) pods based on labels. ```text selector: @@ -144,7 +144,7 @@ Now, we will briefly explain how to define a security policy. In each match, there are three options. - * ownerOnly (static action: allow owner only; otherwise block all) + * ownerOnly \(static action: allow owner only; otherwise block all\) If this is enabled, the owners of the executable\(s\) defined with matchPaths and matchDirectories will be only allowed to execute. @@ -197,7 +197,7 @@ Now, we will briefly explain how to define a security policy. The only difference between 'process' and 'file' is the readOnly option. - * readOnly (static action: allow to read only; otherwise block all) + * readOnly \(static action: allow to read only; otherwise block all\) If this is enabled, the read operation will be only allowed, and any other operations \(e.g., write\) will be blocked. @@ -217,7 +217,7 @@ Now, we will briefly explain how to define a security policy. * Capabilities - In the case of capabilities, there is currently one match type: matchCapabilities. You can define specific capability names to allow or block using matchCapabilities. You can check available capabilities in [Capability List](supported_capability_list.md). + In the case of capabilities, there is currently one match type: matchCapabilities. You can define specific capability names to allow or block using matchCapabilities. You can check available capabilities in [Capability List](../reference/supported_capability_list.md). ```text capabilities: diff --git a/documentation/supported_capability_list.md b/reference/supported_capability_list.md similarity index 99% rename from documentation/supported_capability_list.md rename to reference/supported_capability_list.md index fef25f11c0..e8e52b09c3 100644 --- a/documentation/supported_capability_list.md +++ b/reference/supported_capability_list.md @@ -38,3 +38,4 @@ setfcap mac_override mac_admin ``` + diff --git a/documentation/supported_operation_list.md b/reference/supported_operation_list.md similarity index 98% rename from documentation/supported_operation_list.md rename to reference/supported_operation_list.md index 476888ecae..10b5d65ffc 100644 --- a/documentation/supported_operation_list.md +++ b/reference/supported_operation_list.md @@ -5,3 +5,4 @@ The operations that are currently supported are: ```text TBF ``` +