Skip to content

Commit

Permalink
add scanning scope field in the control
Browse files Browse the repository at this point in the history 
Signed-off-by: rcohencyberarmor <[email protected]>
  • Loading branch information
rcohencyberarmor committed Jul 17, 2023
1 parent 0e5330e commit a18099b
Show file tree
Hide file tree
Showing 232 changed files with 6,543 additions and 4,585 deletions.
70 changes: 40 additions & 30 deletions controls/C-0001-forbiddencontainerregistries.json
View file
Original file line number Diff line number Diff line change
@@ -1,32 +1,42 @@
{
"name": "Forbidden Container Registries",
"attributes": {
"armoBuiltin": true,
"microsoftMitreColumns": [
"Initial Access"
],
"controlTypeTags": [
"security",
"compliance"
],
"attackTracks": [
{
"attackTrack": "container",
"categories": [
"Initial access"
]
}
],
"actionRequired": "configuration"
},
"description": "In cases where the Kubernetes cluster is provided by a CSP (e.g., AKS in Azure, GKE in GCP, or EKS in AWS), compromised cloud credential can lead to the cluster takeover. Attackers may abuse cloud account credentials or IAM mechanism to the cluster\u2019s management layer.",
"remediation": "Limit the registries from which you pull container images from",
"rulesNames": [
"rule-identify-blocklisted-image-registries"
"name": "Forbidden Container Registries",
"attributes": {
"armoBuiltin": true,
"microsoftMitreColumns": [
"Initial Access"
],
"long_description": "Running a compromised image in a cluster can compromise the cluster. Attackers who get access to a private registry can plant their own compromised images in the registry. The latter can then be pulled by a user. In addition, users often use untrusted images from public registries (such as Docker Hub) that may be malicious. Building images based on untrusted base images can also lead to similar results.",
"test": "Checking image from pod spec, if the registry of the image is from the list of blocked registries we raise an alert.",
"controlID": "C-0001",
"baseScore": 7.0,
"example": "@controls/examples/c001.yaml"
}
"controlTypeTags": [
"security",
"compliance"
],
"attackTracks": [
{
"attackTrack": "container",
"categories": [
"Initial access"
]
}
],
"actionRequired": "configuration"
},
"description": "In cases where the Kubernetes cluster is provided by a CSP (e.g., AKS in Azure, GKE in GCP, or EKS in AWS), compromised cloud credential can lead to the cluster takeover. Attackers may abuse cloud account credentials or IAM mechanism to the cluster’s management layer.",
"remediation": "Limit the registries from which you pull container images from",
"rulesNames": [
"rule-identify-blocklisted-image-registries"
],
"long_description": "Running a compromised image in a cluster can compromise the cluster. Attackers who get access to a private registry can plant their own compromised images in the registry. The latter can then be pulled by a user. In addition, users often use untrusted images from public registries (such as Docker Hub) that may be malicious. Building images based on untrusted base images can also lead to similar results.",
"test": "Checking image from pod spec, if the registry of the image is from the list of blocked registries we raise an alert.",
"controlID": "C-0001",
"baseScore": 7,
"example": "@controls/examples/c001.yaml",
"scanningScope": {
"matches": [
[
"cluster"
],
[
"file"
]
]
}
}
56 changes: 33 additions & 23 deletions controls/C-0002-execintocontainer.json
View file
Original file line number Diff line number Diff line change
@@ -1,25 +1,35 @@
{
"name": "Exec into container",
"attributes": {
"armoBuiltin": true,
"microsoftMitreColumns": [
"Execution"
],
"rbacQuery": "Show who can access into pods",
"controlTypeTags": [
"compliance",
"security-impact"
]
},
"description": "Attackers with relevant permissions can run malicious commands in the context of legitimate containers in the cluster using \u201ckubectl exec\u201d command. This control determines which subjects have permissions to use this command.",
"remediation": "It is recommended to prohibit \u201ckubectl exec\u201d command in production environments. It is also recommended not to use subjects with this permission for daily cluster operations.",
"rulesNames": [
"exec-into-container",
"exec-into-container-v1"
"name": "Exec into container",
"attributes": {
"armoBuiltin": true,
"microsoftMitreColumns": [
"Execution"
],
"long_description": "Attackers who have permissions, can run malicious commands in containers in the cluster using exec command (\u201ckubectl exec\u201d). In this method, attackers can use legitimate images, such as an OS image (e.g., Ubuntu) as a backdoor container, and run their malicious code remotely by using \u201ckubectl exec\u201d.",
"test": "Check which subjects have RBAC permissions to exec into pods\u2013 if they have the \u201cpods/exec\u201d verb.",
"controlID": "C-0002",
"baseScore": 5.0,
"example": "@controls/examples/c002.yaml"
}
"rbacQuery": "Show who can access into pods",
"controlTypeTags": [
"compliance",
"security-impact"
]
},
"description": "Attackers with relevant permissions can run malicious commands in the context of legitimate containers in the cluster using “kubectl exec” command. This control determines which subjects have permissions to use this command.",
"remediation": "It is recommended to prohibit “kubectl exec” command in production environments. It is also recommended not to use subjects with this permission for daily cluster operations.",
"rulesNames": [
"exec-into-container",
"exec-into-container-v1"
],
"long_description": "Attackers who have permissions, can run malicious commands in containers in the cluster using exec command (“kubectl exec”). In this method, attackers can use legitimate images, such as an OS image (e.g., Ubuntu) as a backdoor container, and run their malicious code remotely by using “kubectl exec”.",
"test": "Check which subjects have RBAC permissions to exec into pods– if they have the “pods/exec” verb.",
"controlID": "C-0002",
"baseScore": 5,
"example": "@controls/examples/c002.yaml",
"scanningScope": {
"matches": [
[
"cluster"
],
[
"file"
]
]
}
}
60 changes: 35 additions & 25 deletions controls/C-0004-resourcesmemorylimitandrequest.json
View file
Original file line number Diff line number Diff line change
@@ -1,27 +1,37 @@
{
"name": "Resources memory limit and request",
"attributes": {
"armoBuiltin": true,
"controlTypeTags": [
"compliance",
"devops"
],
"attackTracks": [
{
"attackTrack": "container",
"categories": [
"Impact - service destruction"
]
}
],
"actionRequired": "configuration"
},
"description": "This control identifies all Pods for which the memory limit is not set.",
"remediation": "Set the memory limit or use exception mechanism to avoid unnecessary notifications.",
"rulesNames": [
"resources-memory-limit-and-request"
"name": "Resources memory limit and request",
"attributes": {
"armoBuiltin": true,
"controlTypeTags": [
"compliance",
"devops"
],
"controlID": "C-0004",
"example": "@controls/examples/c004.yaml",
"baseScore": 8.0
}
"attackTracks": [
{
"attackTrack": "container",
"categories": [
"Impact - service destruction"
]
}
],
"actionRequired": "configuration"
},
"description": "This control identifies all Pods for which the memory limit is not set.",
"remediation": "Set the memory limit or use exception mechanism to avoid unnecessary notifications.",
"rulesNames": [
"resources-memory-limit-and-request"
],
"controlID": "C-0004",
"example": "@controls/examples/c004.yaml",
"baseScore": 8,
"scanningScope": {
"matches": [
[
"cluster"
],
[
"file"
]
]
}
}
57 changes: 32 additions & 25 deletions controls/C-0005-apiserverinsecureportisenabled.json
View file
Original file line number Diff line number Diff line change
@@ -1,27 +1,34 @@
{
"name": "API server insecure port is enabled",
"attributes": {
"armoBuiltin": true,
"controlTypeTags": [
"security",
"compliance"
],
"attackTracks": [
{
"attackTrack": "kubeapi",
"categories": [
"Initial access"
]
}
]
},
"description": "Kubernetes control plane API is running with non-secure port enabled which allows attackers to gain unprotected access to the cluster.",
"remediation": "Set the insecure-port flag of the API server to zero.",
"rulesNames": [
"insecure-port-flag"
"name": "API server insecure port is enabled",
"attributes": {
"armoBuiltin": true,
"controlTypeTags": [
"security",
"compliance"
],
"long_description": "The control plane is the core of Kubernetes and gives users the ability to view containers, schedule new Pods, read Secrets, and execute commands in the cluster. Therefore, it should be protected. It is recommended to avoid control plane exposure to the Internet or to an untrusted network. The API server runs on ports 6443 and 8080. We recommend to block them in the firewall. Note also that port 8080, when accessed through the local machine, does not require TLS encryption, and the requests bypass authentication and authorization modules.",
"test": "Check if the insecure-port flag is set (in case of cloud vendor hosted Kubernetes service this verification will not be effective).",
"controlID": "C-0005",
"baseScore": 9.0
}
"attackTracks": [
{
"attackTrack": "kubeapi",
"categories": [
"Initial access"
]
}
]
},
"description": "Kubernetes control plane API is running with non-secure port enabled which allows attackers to gain unprotected access to the cluster.",
"remediation": "Set the insecure-port flag of the API server to zero.",
"rulesNames": [
"insecure-port-flag"
],
"long_description": "The control plane is the core of Kubernetes and gives users the ability to view containers, schedule new Pods, read Secrets, and execute commands in the cluster. Therefore, it should be protected. It is recommended to avoid control plane exposure to the Internet or to an untrusted network. The API server runs on ports 6443 and 8080. We recommend to block them in the firewall. Note also that port 8080, when accessed through the local machine, does not require TLS encryption, and the requests bypass authentication and authorization modules.",
"test": "Check if the insecure-port flag is set (in case of cloud vendor hosted Kubernetes service this verification will not be effective).",
"controlID": "C-0005",
"baseScore": 9,
"scanningScope": {
"matches": [
[
"cluster"
]
]
}
}
54 changes: 32 additions & 22 deletions controls/C-0007-datadestruction.json
View file
Original file line number Diff line number Diff line change
@@ -1,24 +1,34 @@
{
"name": "Data Destruction",
"attributes": {
"armoBuiltin": true,
"microsoftMitreColumns": [
"Impact"
],
"rbacQuery": "Data destruction",
"controlTypeTags": [
"compliance"
]
},
"description": "Attackers may attempt to destroy data and resources in the cluster. This includes deleting deployments, configurations, storage, and compute resources. This control identifies all subjects that can delete resources.",
"remediation": "You should follow the least privilege principle and minimize the number of subjects that can delete resources.",
"rulesNames": [
"rule-excessive-delete-rights",
"rule-excessive-delete-rights-v1"
"name": "Data Destruction",
"attributes": {
"armoBuiltin": true,
"microsoftMitreColumns": [
"Impact"
],
"long_description": "Attackers may attempt to destroy data and resources in the cluster. This includes deleting deployments, configurations, storage, and compute resources.",
"test": "Check which subjects have delete/deletecollection RBAC permissions on workloads.",
"controlID": "C-0007",
"baseScore": 5.0,
"example": "@controls/examples/c007.yaml"
}
"rbacQuery": "Data destruction",
"controlTypeTags": [
"compliance"
]
},
"description": "Attackers may attempt to destroy data and resources in the cluster. This includes deleting deployments, configurations, storage, and compute resources. This control identifies all subjects that can delete resources.",
"remediation": "You should follow the least privilege principle and minimize the number of subjects that can delete resources.",
"rulesNames": [
"rule-excessive-delete-rights",
"rule-excessive-delete-rights-v1"
],
"long_description": "Attackers may attempt to destroy data and resources in the cluster. This includes deleting deployments, configurations, storage, and compute resources.",
"test": "Check which subjects have delete/deletecollection RBAC permissions on workloads.",
"controlID": "C-0007",
"baseScore": 5,
"example": "@controls/examples/c007.yaml",
"scanningScope": {
"matches": [
[
"cluster"
],
[
"file"
]
]
}
}
60 changes: 35 additions & 25 deletions controls/C-0009-resourcelimits.json
View file
Original file line number Diff line number Diff line change
@@ -1,27 +1,37 @@
{
"name": "Resource limits",
"attributes": {
"armoBuiltin": true,
"controlTypeTags": [
"security"
],
"attackTracks": [
{
"attackTrack": "container",
"categories": [
"Impact - service destruction"
]
}
]
},
"description": "CPU and memory resources should have a limit set for every container or a namespace to prevent resource exhaustion. This control identifies all the Pods without resource limit definitions by checking their yaml definition file as well as their namespace LimitRange objects. It is also recommended to use ResourceQuota object to restrict overall namespace resources, but this is not verified by this control.",
"remediation": "Define LimitRange and Resource Limits in the namespace or in the deployment/POD yamls.",
"rulesNames": [
"resource-policies"
"name": "Resource limits",
"attributes": {
"armoBuiltin": true,
"controlTypeTags": [
"security"
],
"long_description": "CPU and memory resources should have a limit set for every container or a namespace to prevent resource exhaustion. This control identifies all the Pods without resource limit definitions by checking their yaml definition file as well as their namespace LimitRange objects. It is also recommended to use ResourceQuota object to restrict overall namespace resources, but this is not verified by this control.",
"test": " Check for each container if there is a \u2018limits\u2019 field defined for both cpu and memory",
"controlID": "C-0009",
"baseScore": 7.0,
"example": "@controls/examples/c009.yaml"
}
"attackTracks": [
{
"attackTrack": "container",
"categories": [
"Impact - service destruction"
]
}
]
},
"description": "CPU and memory resources should have a limit set for every container or a namespace to prevent resource exhaustion. This control identifies all the Pods without resource limit definitions by checking their yaml definition file as well as their namespace LimitRange objects. It is also recommended to use ResourceQuota object to restrict overall namespace resources, but this is not verified by this control.",
"remediation": "Define LimitRange and Resource Limits in the namespace or in the deployment/POD yamls.",
"rulesNames": [
"resource-policies"
],
"long_description": "CPU and memory resources should have a limit set for every container or a namespace to prevent resource exhaustion. This control identifies all the Pods without resource limit definitions by checking their yaml definition file as well as their namespace LimitRange objects. It is also recommended to use ResourceQuota object to restrict overall namespace resources, but this is not verified by this control.",
"test": " Check for each container if there is a ‘limits’ field defined for both cpu and memory",
"controlID": "C-0009",
"baseScore": 7,
"example": "@controls/examples/c009.yaml",
"scanningScope": {
"matches": [
[
"cluster"
],
[
"file"
]
]
}
}
Loading

0 comments on commit a18099b

Please sign in to comment.