diff --git a/latest/404.html b/latest/404.html index 06c8c95..f56cc66 100644 --- a/latest/404.html +++ b/latest/404.html @@ -4,13 +4,13 @@ Redirecting - Redirecting to ../v0.6.12/404.html... + Redirecting to ../v0.6.15/404.html... \ No newline at end of file diff --git a/latest/architecture/index.html b/latest/architecture/index.html index c83070a..4b74088 100644 --- a/latest/architecture/index.html +++ b/latest/architecture/index.html @@ -4,13 +4,13 @@ Redirecting - Redirecting to ../../v0.6.12/architecture/... + Redirecting to ../../v0.6.15/architecture/... \ No newline at end of file diff --git a/latest/asff/index.html b/latest/asff/index.html index 439397a..76081e5 100644 --- a/latest/asff/index.html +++ b/latest/asff/index.html @@ -4,13 +4,13 @@ Redirecting - Redirecting to ../../v0.6.12/asff/... + Redirecting to ../../v0.6.15/asff/... \ No newline at end of file diff --git a/latest/controls/index.html b/latest/controls/index.html index d5ebfc9..7acbef9 100644 --- a/latest/controls/index.html +++ b/latest/controls/index.html @@ -4,13 +4,13 @@ Redirecting - Redirecting to ../../v0.6.12/controls/... + Redirecting to ../../v0.6.15/controls/... \ No newline at end of file diff --git a/latest/flags-and-commands/index.html b/latest/flags-and-commands/index.html index df58fb9..dc9def1 100644 --- a/latest/flags-and-commands/index.html +++ b/latest/flags-and-commands/index.html @@ -4,13 +4,13 @@ Redirecting - Redirecting to ../../v0.6.12/flags-and-commands/... + Redirecting to ../../v0.6.15/flags-and-commands/... \ No newline at end of file diff --git a/latest/index.html b/latest/index.html index ae7b41b..27ce3f3 100644 --- a/latest/index.html +++ b/latest/index.html @@ -4,13 +4,13 @@ Redirecting - Redirecting to ../v0.6.12/... + Redirecting to ../v0.6.15/... \ No newline at end of file diff --git a/latest/installation/index.html b/latest/installation/index.html index eac2903..62254af 100644 --- a/latest/installation/index.html +++ b/latest/installation/index.html @@ -4,13 +4,13 @@ Redirecting - Redirecting to ../../v0.6.12/installation/... + Redirecting to ../../v0.6.15/installation/... \ No newline at end of file diff --git a/latest/platforms/index.html b/latest/platforms/index.html index c916c34..4063ed4 100644 --- a/latest/platforms/index.html +++ b/latest/platforms/index.html @@ -4,13 +4,13 @@ Redirecting - Redirecting to ../../v0.6.12/platforms/... + Redirecting to ../../v0.6.15/platforms/... \ No newline at end of file diff --git a/latest/running/index.html b/latest/running/index.html index 30f8b06..8ae0c93 100644 --- a/latest/running/index.html +++ b/latest/running/index.html @@ -4,13 +4,13 @@ Redirecting - Redirecting to ../../v0.6.12/running/... + Redirecting to ../../v0.6.15/running/... \ No newline at end of file diff --git a/v0.6.15/404.html b/v0.6.15/404.html new file mode 100644 index 0000000..2053f06 --- /dev/null +++ b/v0.6.15/404.html @@ -0,0 +1,598 @@ + + + + + + + + + + + + + + + + + + + + + + + + Kube-bench + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ +
+
+ +
+ + + + + + + + +
+ + +
+ +
+ + + + + + +
+
+ + + +
+
+
+ + + + + +
+
+
+ + + +
+
+
+ + + +
+
+
+ + + +
+ +
+ +

404 - Not found

+ +
+
+ + + +
+ +
+ + + +
+
+
+
+ + + + + + + + + \ No newline at end of file diff --git a/v0.6.15/architecture/index.html b/v0.6.15/architecture/index.html new file mode 100644 index 0000000..4dab866 --- /dev/null +++ b/v0.6.15/architecture/index.html @@ -0,0 +1,811 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + Architecture - Kube-bench + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ + + + Skip to content + + +
+
+ +
+ + + + + + + + +
+ + +
+ +
+ + + + + + +
+
+ + + +
+
+
+ + + + + +
+
+
+ + + +
+
+
+ + + +
+
+
+ + + +
+ +
+ + + + +

Architecture

+ +

Test config YAML representation

+

The tests (or "controls") are maintained in YAML documents. There are different versions of these test YAML files reflecting different versions and platforms of the CIS Kubernetes Benchmark. You will find more information about the test file YAML definitions in our controls documentation.

+

Kube-bench benchmarks

+

The test files for the various versions of Benchmarks can be found in directories +with same name as the Benchmark versions under the cfg directory next to the kube-bench executable, +for example ./cfg/cis-1.5 will contain all test files for CIS Kubernetes Benchmark v1.5.1 which are: +master.yaml, controlplane.yaml, node.yaml, etcd.yaml, policies.yaml and config.yaml

+

Check the contents of the benchmark directory under cfg to see which targets are available for that benchmark. Each file except config.yaml represents a target (also known as a control in other parts of this documentation).

+

The following table shows the valid targets based on the CIS Benchmark version.

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
CIS BenchmarkTargets
cis-1.5master, controlplane, node, etcd, policies
cis-1.6master, controlplane, node, etcd, policies
cis-1.20master, controlplane, node, etcd, policies
cis-1.23master, controlplane, node, etcd, policies
cis-1.24master, controlplane, node, etcd, policies
cis-1.7master, controlplane, node, etcd, policies
gke-1.0master, controlplane, node, etcd, policies, managedservices
gke-1.2.0controlplane, node, policies, managedservices
eks-1.0.1controlplane, node, policies, managedservices
eks-1.1.0controlplane, node, policies, managedservices
eks-1.2.0controlplane, node, policies, managedservices
ack-1.0master, controlplane, node, etcd, policies, managedservices
aks-1.0controlplane, node, policies, managedservices
rh-0.7master,node
rh-1.0master, controlplane, node, etcd, policies
cis-1.6-k3smaster, controlplane, node, etcd, policies
+

The following table shows the valid DISA STIG versions

+ + + + + + + + + + + + + +
STIGTargets
eks-stig-kubernetes-v1r6master, controlplane, node, policies, managedservices
+ + + + + + + +
+
+ + + +
+ +
+ + + +
+
+
+
+ + + + + + + + + \ No newline at end of file diff --git a/v0.6.15/asff/index.html b/v0.6.15/asff/index.html new file mode 100644 index 0000000..e6f126a --- /dev/null +++ b/v0.6.15/asff/index.html @@ -0,0 +1,799 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + ASFF - Kube-bench + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ + + + Skip to content + + +
+
+ +
+ + + + + + + + +
+ + +
+ +
+ + + + + + +
+
+ + + +
+
+
+ + + + + +
+
+
+ + + +
+
+
+ + + +
+
+
+ + + +
+ +
+ + + + +

Integrating kube-bench with AWS Security Hub

+

You can configure kube-bench with the --asff to send findings to AWS Security Hub. There are some additional steps required so that kube-bench has information and permissions to send these findings.

+

Enable the AWS Security Hub integration

+
    +
  • You will need AWS Security Hub to be enabled in your account
    • +
  • In the Security Hub console, under Integrations, search for kube-bench
    • +
+

+ +

+ +
    +
  • Click on Accept findings. This gives information about the IAM permissions required to send findings to your Security Hub account. kube-bench runs within a pod on your EKS cluster, and will need to be associated with a Role that has these permissions.
    • +
+

Configure permissions in an IAM Role

+
    +
  • Grant these permissions to the IAM Role that the kube-bench pod will be associated with. There are two options:
    • +
  • You can run the kube-bench pod under a specific service account associated with an IAM role that has these permissions to write Security Hub findings.
    • +
  • Alternatively the pod can be granted permissions specified by the Role that your EKS node group uses.
    • +
+

Here is an example IAM Policy that you can attach to your EKS node group's IAM Role:

+
{
+    "Version": "2012-10-17",
+    "Statement": [
+        {
+            "Effect": "Allow",
+            "Action": "securityhub:BatchImportFindings",
+            "Resource": [
+                "arn:aws:securityhub:us-east-1::product/aqua-security/kube-bench"
+            ]
+        }
+    ]
+}
+
+

Modify the job configuration

+
    +
  • Modify the kube-bench Configmap in job-eks-asff.yaml to specify the AWS account, AWS region, and the EKS Cluster ARN.
    • +
  • In the same file, modify the image specifed in the Job to use the kube-bench image pushed to your ECR
    • +
  • [Optional] - If you have created a dedicated IAM role to be used with kube-bench as described above in Configure permissions in an IAM Role, you will need to add the IAM role arn to the kube-bench ServiceAccount in job-eks-asff.yaml.
    • +
  • Make sure that job-eks-asff.yaml specifies the container image you just pushed to your ECR registry.
    • +
+

You can now run kube-bench as a pod in your cluster: kubectl apply -f job-eks-asff.yaml

+

Findings will be generated for any kube-bench test that generates a [FAIL] or [WARN] output. If all tests pass, no findings will be generated. However, it's recommended that you consult the pod log output to check whether any findings were generated but could not be written to Security Hub.

+

+ +

+ + + + + + + +
+
+ + + +
+ +
+ + + +
+
+
+
+ + + + + + + + + \ No newline at end of file diff --git a/v0.6.15/assets/images/favicon.png b/v0.6.15/assets/images/favicon.png new file mode 100644 index 0000000..1cf13b9 Binary files /dev/null and b/v0.6.15/assets/images/favicon.png differ diff --git a/v0.6.15/assets/javascripts/bundle.10c6cd24.min.js b/v0.6.15/assets/javascripts/bundle.10c6cd24.min.js new file mode 100644 index 0000000..50d3a17 --- /dev/null +++ b/v0.6.15/assets/javascripts/bundle.10c6cd24.min.js @@ -0,0 +1,3 @@ +"use strict";(()=>{var Ui=Object.create;var Ar=Object.defineProperty;var Wi=Object.getOwnPropertyDescriptor;var Di=Object.getOwnPropertyNames,qt=Object.getOwnPropertySymbols,Ni=Object.getPrototypeOf,Cr=Object.prototype.hasOwnProperty,un=Object.prototype.propertyIsEnumerable;var fn=(e,t,r)=>t in e?Ar(e,t,{enumerable:!0,configurable:!0,writable:!0,value:r}):e[t]=r,j=(e,t)=>{for(var r in t||(t={}))Cr.call(t,r)&&fn(e,r,t[r]);if(qt)for(var r of qt(t))un.call(t,r)&&fn(e,r,t[r]);return e};var mn=(e,t)=>{var r={};for(var n in e)Cr.call(e,n)&&t.indexOf(n)<0&&(r[n]=e[n]);if(e!=null&&qt)for(var n of qt(e))t.indexOf(n)<0&&un.call(e,n)&&(r[n]=e[n]);return r};var Kt=(e,t)=>()=>(t||e((t={exports:{}}).exports,t),t.exports);var zi=(e,t,r,n)=>{if(t&&typeof t=="object"||typeof t=="function")for(let o of Di(t))!Cr.call(e,o)&&o!==r&&Ar(e,o,{get:()=>t[o],enumerable:!(n=Wi(t,o))||n.enumerable});return e};var Lt=(e,t,r)=>(r=e!=null?Ui(Ni(e)):{},zi(t||!e||!e.__esModule?Ar(r,"default",{value:e,enumerable:!0}):r,e));var hn=Kt((kr,dn)=>{(function(e,t){typeof kr=="object"&&typeof dn!="undefined"?t():typeof define=="function"&&define.amd?define(t):t()})(kr,function(){"use strict";function e(r){var n=!0,o=!1,i=null,a={text:!0,search:!0,url:!0,tel:!0,email:!0,password:!0,number:!0,date:!0,month:!0,week:!0,time:!0,datetime:!0,"datetime-local":!0};function s(M){return!!(M&&M!==document&&M.nodeName!=="HTML"&&M.nodeName!=="BODY"&&"classList"in M&&"contains"in M.classList)}function p(M){var Ne=M.type,R=M.tagName;return!!(R==="INPUT"&&a[Ne]&&!M.readOnly||R==="TEXTAREA"&&!M.readOnly||M.isContentEditable)}function c(M){M.classList.contains("focus-visible")||(M.classList.add("focus-visible"),M.setAttribute("data-focus-visible-added",""))}function l(M){M.hasAttribute("data-focus-visible-added")&&(M.classList.remove("focus-visible"),M.removeAttribute("data-focus-visible-added"))}function f(M){M.metaKey||M.altKey||M.ctrlKey||(s(r.activeElement)&&c(r.activeElement),n=!0)}function m(M){n=!1}function d(M){s(M.target)&&(n||p(M.target))&&c(M.target)}function h(M){s(M.target)&&(M.target.classList.contains("focus-visible")||M.target.hasAttribute("data-focus-visible-added"))&&(o=!0,window.clearTimeout(i),i=window.setTimeout(function(){o=!1},100),l(M.target))}function v(M){document.visibilityState==="hidden"&&(o&&(n=!0),Y())}function Y(){document.addEventListener("mousemove",K),document.addEventListener("mousedown",K),document.addEventListener("mouseup",K),document.addEventListener("pointermove",K),document.addEventListener("pointerdown",K),document.addEventListener("pointerup",K),document.addEventListener("touchmove",K),document.addEventListener("touchstart",K),document.addEventListener("touchend",K)}function X(){document.removeEventListener("mousemove",K),document.removeEventListener("mousedown",K),document.removeEventListener("mouseup",K),document.removeEventListener("pointermove",K),document.removeEventListener("pointerdown",K),document.removeEventListener("pointerup",K),document.removeEventListener("touchmove",K),document.removeEventListener("touchstart",K),document.removeEventListener("touchend",K)}function K(M){M.target.nodeName&&M.target.nodeName.toLowerCase()==="html"||(n=!1,X())}document.addEventListener("keydown",f,!0),document.addEventListener("mousedown",m,!0),document.addEventListener("pointerdown",m,!0),document.addEventListener("touchstart",m,!0),document.addEventListener("visibilitychange",v,!0),Y(),r.addEventListener("focus",d,!0),r.addEventListener("blur",h,!0),r.nodeType===Node.DOCUMENT_FRAGMENT_NODE&&r.host?r.host.setAttribute("data-js-focus-visible",""):r.nodeType===Node.DOCUMENT_NODE&&(document.documentElement.classList.add("js-focus-visible"),document.documentElement.setAttribute("data-js-focus-visible",""))}if(typeof window!="undefined"&&typeof document!="undefined"){window.applyFocusVisiblePolyfill=e;var t;try{t=new CustomEvent("focus-visible-polyfill-ready")}catch(r){t=document.createEvent("CustomEvent"),t.initCustomEvent("focus-visible-polyfill-ready",!1,!1,{})}window.dispatchEvent(t)}typeof document!="undefined"&&e(document)})});var bn=Kt(Rr=>{(function(e){var t=function(){try{return!!Symbol.iterator}catch(c){return!1}},r=t(),n=function(c){var l={next:function(){var f=c.shift();return{done:f===void 0,value:f}}};return r&&(l[Symbol.iterator]=function(){return l}),l},o=function(c){return encodeURIComponent(c).replace(/%20/g,"+")},i=function(c){return decodeURIComponent(String(c).replace(/\+/g," "))},a=function(){var c=function(f){Object.defineProperty(this,"_entries",{writable:!0,value:{}});var m=typeof f;if(m!=="undefined")if(m==="string")f!==""&&this._fromString(f);else if(f instanceof c){var d=this;f.forEach(function(X,K){d.append(K,X)})}else if(f!==null&&m==="object")if(Object.prototype.toString.call(f)==="[object Array]")for(var h=0;hd[0]?1:0}),c._entries&&(c._entries={});for(var f=0;f1?i(d[1]):"")}})})(typeof global!="undefined"?global:typeof window!="undefined"?window:typeof self!="undefined"?self:Rr);(function(e){var t=function(){try{var o=new e.URL("b","http://a");return o.pathname="c d",o.href==="http://a/c%20d"&&o.searchParams}catch(i){return!1}},r=function(){var o=e.URL,i=function(p,c){typeof p!="string"&&(p=String(p)),c&&typeof c!="string"&&(c=String(c));var l=document,f;if(c&&(e.location===void 0||c!==e.location.href)){c=c.toLowerCase(),l=document.implementation.createHTMLDocument(""),f=l.createElement("base"),f.href=c,l.head.appendChild(f);try{if(f.href.indexOf(c)!==0)throw new Error(f.href)}catch(M){throw new Error("URL unable to set base "+c+" due to "+M)}}var m=l.createElement("a");m.href=p,f&&(l.body.appendChild(m),m.href=m.href);var d=l.createElement("input");if(d.type="url",d.value=p,m.protocol===":"||!/:/.test(m.href)||!d.checkValidity()&&!c)throw new TypeError("Invalid URL");Object.defineProperty(this,"_anchorElement",{value:m});var h=new e.URLSearchParams(this.search),v=!0,Y=!0,X=this;["append","delete","set"].forEach(function(M){var Ne=h[M];h[M]=function(){Ne.apply(h,arguments),v&&(Y=!1,X.search=h.toString(),Y=!0)}}),Object.defineProperty(this,"searchParams",{value:h,enumerable:!0});var K=void 0;Object.defineProperty(this,"_updateSearchParams",{enumerable:!1,configurable:!1,writable:!1,value:function(){this.search!==K&&(K=this.search,Y&&(v=!1,this.searchParams._fromString(this.search),v=!0))}})},a=i.prototype,s=function(p){Object.defineProperty(a,p,{get:function(){return this._anchorElement[p]},set:function(c){this._anchorElement[p]=c},enumerable:!0})};["hash","host","hostname","port","protocol"].forEach(function(p){s(p)}),Object.defineProperty(a,"search",{get:function(){return this._anchorElement.search},set:function(p){this._anchorElement.search=p,this._updateSearchParams()},enumerable:!0}),Object.defineProperties(a,{toString:{get:function(){var p=this;return function(){return p.href}}},href:{get:function(){return this._anchorElement.href.replace(/\?$/,"")},set:function(p){this._anchorElement.href=p,this._updateSearchParams()},enumerable:!0},pathname:{get:function(){return this._anchorElement.pathname.replace(/(^\/?)/,"/")},set:function(p){this._anchorElement.pathname=p},enumerable:!0},origin:{get:function(){var p={"http:":80,"https:":443,"ftp:":21}[this._anchorElement.protocol],c=this._anchorElement.port!=p&&this._anchorElement.port!=="";return this._anchorElement.protocol+"//"+this._anchorElement.hostname+(c?":"+this._anchorElement.port:"")},enumerable:!0},password:{get:function(){return""},set:function(p){},enumerable:!0},username:{get:function(){return""},set:function(p){},enumerable:!0}}),i.createObjectURL=function(p){return o.createObjectURL.apply(o,arguments)},i.revokeObjectURL=function(p){return o.revokeObjectURL.apply(o,arguments)},e.URL=i};if(t()||r(),e.location!==void 0&&!("origin"in e.location)){var n=function(){return e.location.protocol+"//"+e.location.hostname+(e.location.port?":"+e.location.port:"")};try{Object.defineProperty(e.location,"origin",{get:n,enumerable:!0})}catch(o){setInterval(function(){e.location.origin=n()},100)}}})(typeof global!="undefined"?global:typeof window!="undefined"?window:typeof self!="undefined"?self:Rr)});var nn=Kt((Ut,rn)=>{(function(t,r){typeof Ut=="object"&&typeof rn=="object"?rn.exports=r():typeof define=="function"&&define.amd?define([],r):typeof Ut=="object"?Ut.ClipboardJS=r():t.ClipboardJS=r()})(Ut,function(){return function(){var e={686:function(n,o,i){"use strict";i.d(o,{default:function(){return Fi}});var a=i(279),s=i.n(a),p=i(370),c=i.n(p),l=i(817),f=i.n(l);function m(D){try{return document.execCommand(D)}catch(A){return!1}}var d=function(A){var L=f()(A);return m("cut"),L},h=d;function v(D){var A=document.documentElement.getAttribute("dir")==="rtl",L=document.createElement("textarea");L.style.fontSize="12pt",L.style.border="0",L.style.padding="0",L.style.margin="0",L.style.position="absolute",L.style[A?"right":"left"]="-9999px";var I=window.pageYOffset||document.documentElement.scrollTop;return L.style.top="".concat(I,"px"),L.setAttribute("readonly",""),L.value=D,L}var Y=function(A,L){var I=v(A);L.container.appendChild(I);var U=f()(I);return m("copy"),I.remove(),U},X=function(A){var L=arguments.length>1&&arguments[1]!==void 0?arguments[1]:{container:document.body},I="";return typeof A=="string"?I=Y(A,L):A instanceof HTMLInputElement&&!["text","search","url","tel","password"].includes(A==null?void 0:A.type)?I=Y(A.value,L):(I=f()(A),m("copy")),I},K=X;function M(D){"@babel/helpers - typeof";return typeof Symbol=="function"&&typeof Symbol.iterator=="symbol"?M=function(L){return typeof L}:M=function(L){return L&&typeof Symbol=="function"&&L.constructor===Symbol&&L!==Symbol.prototype?"symbol":typeof L},M(D)}var Ne=function(){var A=arguments.length>0&&arguments[0]!==void 0?arguments[0]:{},L=A.action,I=L===void 0?"copy":L,U=A.container,G=A.target,Pe=A.text;if(I!=="copy"&&I!=="cut")throw new Error('Invalid "action" value, use either "copy" or "cut"');if(G!==void 0)if(G&&M(G)==="object"&&G.nodeType===1){if(I==="copy"&&G.hasAttribute("disabled"))throw new Error('Invalid "target" attribute. Please use "readonly" instead of "disabled" attribute');if(I==="cut"&&(G.hasAttribute("readonly")||G.hasAttribute("disabled")))throw new Error(`Invalid "target" attribute. You can't cut text from elements with "readonly" or "disabled" attributes`)}else throw new Error('Invalid "target" value, use a valid Element');if(Pe)return K(Pe,{container:U});if(G)return I==="cut"?h(G):K(G,{container:U})},R=Ne;function B(D){"@babel/helpers - typeof";return typeof Symbol=="function"&&typeof Symbol.iterator=="symbol"?B=function(L){return typeof L}:B=function(L){return L&&typeof Symbol=="function"&&L.constructor===Symbol&&L!==Symbol.prototype?"symbol":typeof L},B(D)}function se(D,A){if(!(D instanceof A))throw new TypeError("Cannot call a class as a function")}function me(D,A){for(var L=0;L0&&arguments[0]!==void 0?arguments[0]:{};this.action=typeof U.action=="function"?U.action:this.defaultAction,this.target=typeof U.target=="function"?U.target:this.defaultTarget,this.text=typeof U.text=="function"?U.text:this.defaultText,this.container=B(U.container)==="object"?U.container:document.body}},{key:"listenClick",value:function(U){var G=this;this.listener=c()(U,"click",function(Pe){return G.onClick(Pe)})}},{key:"onClick",value:function(U){var G=U.delegateTarget||U.currentTarget,Pe=this.action(G)||"copy",Vt=R({action:Pe,container:this.container,target:this.target(G),text:this.text(G)});this.emit(Vt?"success":"error",{action:Pe,text:Vt,trigger:G,clearSelection:function(){G&&G.focus(),window.getSelection().removeAllRanges()}})}},{key:"defaultAction",value:function(U){return Lr("action",U)}},{key:"defaultTarget",value:function(U){var G=Lr("target",U);if(G)return document.querySelector(G)}},{key:"defaultText",value:function(U){return Lr("text",U)}},{key:"destroy",value:function(){this.listener.destroy()}}],[{key:"copy",value:function(U){var G=arguments.length>1&&arguments[1]!==void 0?arguments[1]:{container:document.body};return K(U,G)}},{key:"cut",value:function(U){return h(U)}},{key:"isSupported",value:function(){var U=arguments.length>0&&arguments[0]!==void 0?arguments[0]:["copy","cut"],G=typeof U=="string"?[U]:U,Pe=!!document.queryCommandSupported;return G.forEach(function(Vt){Pe=Pe&&!!document.queryCommandSupported(Vt)}),Pe}}]),L}(s()),Fi=ji},828:function(n){var o=9;if(typeof Element!="undefined"&&!Element.prototype.matches){var i=Element.prototype;i.matches=i.matchesSelector||i.mozMatchesSelector||i.msMatchesSelector||i.oMatchesSelector||i.webkitMatchesSelector}function a(s,p){for(;s&&s.nodeType!==o;){if(typeof s.matches=="function"&&s.matches(p))return s;s=s.parentNode}}n.exports=a},438:function(n,o,i){var a=i(828);function s(l,f,m,d,h){var v=c.apply(this,arguments);return l.addEventListener(m,v,h),{destroy:function(){l.removeEventListener(m,v,h)}}}function p(l,f,m,d,h){return typeof l.addEventListener=="function"?s.apply(null,arguments):typeof m=="function"?s.bind(null,document).apply(null,arguments):(typeof l=="string"&&(l=document.querySelectorAll(l)),Array.prototype.map.call(l,function(v){return s(v,f,m,d,h)}))}function c(l,f,m,d){return function(h){h.delegateTarget=a(h.target,f),h.delegateTarget&&d.call(l,h)}}n.exports=p},879:function(n,o){o.node=function(i){return i!==void 0&&i instanceof HTMLElement&&i.nodeType===1},o.nodeList=function(i){var a=Object.prototype.toString.call(i);return i!==void 0&&(a==="[object NodeList]"||a==="[object HTMLCollection]")&&"length"in i&&(i.length===0||o.node(i[0]))},o.string=function(i){return typeof i=="string"||i instanceof String},o.fn=function(i){var a=Object.prototype.toString.call(i);return a==="[object Function]"}},370:function(n,o,i){var a=i(879),s=i(438);function p(m,d,h){if(!m&&!d&&!h)throw new Error("Missing required arguments");if(!a.string(d))throw new TypeError("Second argument must be a String");if(!a.fn(h))throw new TypeError("Third argument must be a Function");if(a.node(m))return c(m,d,h);if(a.nodeList(m))return l(m,d,h);if(a.string(m))return f(m,d,h);throw new TypeError("First argument must be a String, HTMLElement, HTMLCollection, or NodeList")}function c(m,d,h){return m.addEventListener(d,h),{destroy:function(){m.removeEventListener(d,h)}}}function l(m,d,h){return Array.prototype.forEach.call(m,function(v){v.addEventListener(d,h)}),{destroy:function(){Array.prototype.forEach.call(m,function(v){v.removeEventListener(d,h)})}}}function f(m,d,h){return s(document.body,m,d,h)}n.exports=p},817:function(n){function o(i){var a;if(i.nodeName==="SELECT")i.focus(),a=i.value;else if(i.nodeName==="INPUT"||i.nodeName==="TEXTAREA"){var s=i.hasAttribute("readonly");s||i.setAttribute("readonly",""),i.select(),i.setSelectionRange(0,i.value.length),s||i.removeAttribute("readonly"),a=i.value}else{i.hasAttribute("contenteditable")&&i.focus();var p=window.getSelection(),c=document.createRange();c.selectNodeContents(i),p.removeAllRanges(),p.addRange(c),a=p.toString()}return a}n.exports=o},279:function(n){function o(){}o.prototype={on:function(i,a,s){var p=this.e||(this.e={});return(p[i]||(p[i]=[])).push({fn:a,ctx:s}),this},once:function(i,a,s){var p=this;function c(){p.off(i,c),a.apply(s,arguments)}return c._=a,this.on(i,c,s)},emit:function(i){var a=[].slice.call(arguments,1),s=((this.e||(this.e={}))[i]||[]).slice(),p=0,c=s.length;for(p;p{"use strict";var hs=/["'&<>]/;ii.exports=bs;function bs(e){var t=""+e,r=hs.exec(t);if(!r)return t;var n,o="",i=0,a=0;for(i=r.index;i{function e(n,o){parent.postMessage(n,o||"*")}function t(...n){return n.reduce((o,i)=>o.then(()=>new Promise(a=>{let s=document.createElement("script");s.src=i,s.onload=a,document.body.appendChild(s)})),Promise.resolve())}var r=class extends EventTarget{constructor(n){super(),this.url=n,this.m=i=>{i.source===this.w&&(this.dispatchEvent(new MessageEvent("message",{data:i.data})),this.onmessage&&this.onmessage(i))},this.e=(i,a,s,p,c)=>{if(a===`${this.url}`){let l=new ErrorEvent("error",{message:i,filename:a,lineno:s,colno:p,error:c});this.dispatchEvent(l),this.onerror&&this.onerror(l)}};let o=document.createElement("iframe");o.hidden=!0,document.body.appendChild(this.iframe=o),this.w.document.open(),this.w.document.write(` + + + + + + + + + + + + + + + +
+ +
+ + + + + + + + +
+ + +
+ +
+ + + + + + +
+
+ + + +
+
+
+ + + + + +
+
+
+ + + +
+
+
+ + + +
+
+
+ + + +
+ +
+ + + + +

Test and config files

+

kube-bench runs checks specified in controls files that are a YAML +representation of the CIS Kubernetes Benchmark checks (or other distribution-specific hardening guides).

+

Controls

+

controls is a YAML document that contains checks that must be run against a +specific Kubernetes node type, master or node and version.

+

controls is the fundamental input to kube-bench. The following is an example +of a basic controls:

+
---
+controls:
+id: 1
+text: "Master Node Security Configuration"
+type: "master"
+groups:
+- id: 1.1
+  text: API Server
+  checks:
+    - id: 1.1.1
+      text: "Ensure that the --allow-privileged argument is set (Scored)"
+      audit: "ps -ef | grep kube-apiserver | grep -v grep"
+      tests:
+      bin_op: or
+      test_items:
+      - flag: "--allow-privileged"
+        set: true
+      - flag: "--some-other-flag"
+        set: false
+      remediation: "Edit the /etc/kubernetes/config file on the master node and
+        set the KUBE_ALLOW_PRIV parameter to '--allow-privileged=false'"
+      scored: true
+- id: 1.2
+  text: Scheduler
+  checks:
+    - id: 1.2.1
+      text: "Ensure that the --profiling argument is set to false (Scored)"
+      audit: "ps -ef | grep kube-scheduler | grep -v grep"
+      tests:
+        bin_op: and
+        test_items:
+          - flag: "--profiling"
+            set: true
+          - flag: "--some-other-flag"
+            set: false
+      remediation: "Edit the /etc/kubernetes/config file on the master node and
+        set the KUBE_ALLOW_PRIV parameter to '--allow-privileged=false'"
+      scored: true
+
+

controls is composed of a hierarchy of groups, sub-groups and checks. Each of +the controls components have an id and a text description which are displayed +in the kube-bench output.

+

type specifies what kubernetes node type a controls is for. Possible values +for type are master and node.

+

Groups

+

groups is a list of subgroups that test the various Kubernetes components +that run on the node type specified in the controls.

+

For example, one subgroup checks parameters passed to the API server binary, while +another subgroup checks parameters passed to the controller-manager binary.

+
groups:
+- id: 1.1
+  text: API Server
+  # ...
+- id: 1.2
+  text: Scheduler
+  # ...
+
+

These subgroups have id, text fields which serve the same purposes described +in the previous paragraphs. The most important part of the subgroup is the +checks field which is the collection of actual checks that form the subgroup.

+

This is an example of a subgroup and checks in the subgroup.

+
id: 1.1
+text: API Server
+checks:
+  - id: 1.1.1
+    text: "Ensure that the --allow-privileged argument is set (Scored)"
+    audit: "ps -ef | grep kube-apiserver | grep -v grep"
+    tests:
+    # ...
+  - id: 1.1.2
+    text: "Ensure that the --anonymous-auth argument is set to false (Not Scored)"
+    audit: "ps -ef | grep kube-apiserver | grep -v grep"
+    tests:
+    # ...
+
+

kube-bench supports running a subgroup by specifying the subgroup id on the +command line, with the flag --group or -g.

+

Check

+

The CIS Kubernetes Benchmark recommends configurations to harden Kubernetes components. These recommendations are usually configuration options and can be +specified by flags to Kubernetes binaries, or in configuration files.

+

The Benchmark also provides commands to audit a Kubernetes installation, identify +places where the cluster security can be improved, and steps to remediate these +identified problems.

+

In kube-bench, check objects embody these recommendations. This an example +check object:

+
id: 1.1.1
+text: "Ensure that the --anonymous-auth argument is set to false (Not Scored)"
+audit: "ps -ef | grep kube-apiserver | grep -v grep"
+tests:
+  test_items:
+  - flag: "--anonymous-auth"
+    compare:
+      op: eq
+      value: false
+    set: true
+remediation: |
+  Edit the API server pod specification file kube-apiserver
+  on the master node and set the below parameter.
+  --anonymous-auth=false
+scored: false
+
+

A check object has an id, a text, an audit, a tests, remediation +and scored fields.

+

kube-bench supports running individual checks by specifying the check's id +as a comma-delimited list on the command line with the --check flag.

+

The audit field specifies the command to run for a check. The output of this +command is then evaluated for conformance with the CIS Kubernetes Benchmark +recommendation.

+

The audit is evaluated against criteria specified by the tests +object. tests contain bin_op and test_items.

+

test_items specify the criteria(s) the audit command's output should meet to +pass a check. This criteria is made up of keywords extracted from the output of +the audit command and operations that compare these keywords against +values expected by the CIS Kubernetes Benchmark.

+

There are three ways to run and extract keywords from the output of the command used, +| Command | Output var | +|---|---| +| audit | flag | +| audit_config | path | +| audit_env | env |

+

flag is used when the keyword is a command-line flag. The associated audit command could +be any binaries available on the system like ps command and a grep for the binary whose flag we are +checking:

+
ps -ef | grep somebinary | grep -v grep
+
+

Here is an example usage of the flag option:

+
# ...
+audit: "ps -ef | grep kube-apiserver | grep -v grep"
+tests:
+  test_items:
+  - flag: "--anonymous-auth"
+  # ...
+
+

path is used when the keyword is an option set in a JSON or YAML config file. +The associated audit_command command is usually cat /path/to/config-yaml-or-json. +For example:

+
# ...
+text: "Ensure that the --anonymous-auth argument is set to false (Not Scored)"
+audit: "cat /path/to/some/config"
+tests:
+  test_items:
+  - path: "{.someoption.value}"
+    # ...
+
+

env is used to check if the value is present within a specified environment variable. The presence of env is treated as an OR operation, if both flag and env are supplied it will use either to attempt pass the check. +The command used for checking the environment variables of a process is generated by default.

+

If the command being generated is causing errors, you can override the command used by setting audit_env on the check. +Similarly, if you don't want the environment checking command to be generated or run at all, specify disableEnvTesting as true on the check.

+

The example below will check if the flag --auto-tls is equal to false OR ETCD_AUTO_TLS is equal to false

+

  test_items:
+  - flag: "--auto-tls"
+    env: "ETCD_AUTO_TLS"
+    compare:
+      op: eq
+      value: false
+
+Note: flag, path and env will act as OR if more then one present.

+

test_item compares the output of the audit command and keywords using the +set and compare fields.

+
  test_items:
+  - flag: "--anonymous-auth"
+    compare:
+      op: eq
+      value: false
+    set: true
+
+

set checks if a keyword is present in the output of the audit command or a config file. The possible values for set are true and false.

+

If set is true, the check passes only if the keyword is present in the output +of the audit command, or config file. If set is false, the check passes only +if the keyword is not present in the output of the audit command, or config file. +set is true by default.

+

compare has two fields op and value to compare keywords with expected +value. op specifies which operation is used for the comparison, and value +specifies the value to compare against.

+
+

To use compare, set must true. The comparison will be ignored if set is +false

+
+

The op (operations) currently supported in kube-bench are: +- eq: tests if the keyword is equal to the compared value. +- noteq: tests if the keyword is unequal to the compared value. +- gt: tests if the keyword is greater than the compared value. +- gte: tests if the keyword is greater than or equal to the compared value. +- lt: tests if the keyword is less than the compared value. +- lte: tests if the keyword is less than or equal to the compared value. +- has: tests if the keyword contains the compared value. +- nothave: tests if the keyword does not contain the compared value. +- regex: tests if the flag value matches the compared value regular expression. + When defining regular expressions in YAML it is generally easier to wrap them in + single quotes, for example '^[abc]$', to avoid issues with string escaping. +- bitmask : tests if keyward is bitmasked with the compared value, common usege is for + comparing file permissions in linux.

+

Omitting checks

+

If you decide that a recommendation is not appropriate for your environment, you can choose to omit it by editing the test YAML file to give it the check type skip as in this example:

+
  checks:
+  - id: 2.1.1
+    text: "Ensure that the --allow-privileged argument is set to false (Scored)"
+    type: "skip"
+    scored: true
+
+

No tests will be run for this check and the output will be marked [INFO].

+

Configuration and Variables

+

Kubernetes component configuration and binary file locations and names +vary based on cluster deployment methods and Kubernetes distribution used. +For this reason, the locations of these binaries and config files are configurable +by editing the cfg/config.yaml file and these binaries and files can be +referenced in a controls file via variables.

+

The cfg/config.yaml file is a global configuration file. Configuration files +can be created for specific Kubernetes versions (distributions). Values in the +version-specific config overwrite similar values in cfg/config.yaml.

+

For example, the kube-apiserver in Red Hat OCP distribution is run as +hypershift openshift-kube-apiserver instead of the default kube-apiserver. +This difference can be specified by editing the master.apiserver.defaultbin +entry cfg/rh-0.7/config.yaml.

+

Below is the structure of cfg/config.yaml:

+
nodetype
+  |-- components
+    |-- component1
+  |-- component1
+    |-- bins
+    |-- defaultbin (optional)
+    |-- confs
+    |-- defaultconf (optional)
+    |-- svcs
+    |-- defaultsvc (optional)
+    |-- kubeconfig
+    |-- defaultkubeconfig (optional)
+
+

Every node type has a subsection that specifies the main configuration items.

+
    +
  • components: A list of components for the node type. For example master + will have an entry for apiserver, scheduler and controllermanager.
    • +
+

Each component has the following entries:

+
    +
  • bins: A list of candidate binaries for a component. kube-bench checks this + list and selects the first binary that is running on the node.
    • +
+

If none of the binaries in bins list is running, kube-bench checks if the + binary specified by defaultbin is running and terminates if none of the + binaries in both bins and defaultbin is running.

+

The selected binary for a component can be referenced in controls using a + variable in the form $<component>bin. In the example below, we reference + the selected API server binary with the variable $apiserverbin in an audit + command.

+
id: 1.1.1
+ text: "Ensure that the --anonymous-auth argument is set to false (Scored)"
+ audit: "ps -ef | grep $apiserverbin | grep -v grep"
+ # ...
+
+
    +
  • confs: A list of candidate configuration files for a component. kube-bench + checks this list and selects the first config file that is found on the node. + If none of the config files exists, kube-bench defaults conf to the value + of defaultconf.
    • +
+

The selected config for a component can be referenced in controls using a + variable in the form $<component>conf. In the example below, we reference the + selected API server config file with the variable $apiserverconf in an audit + command.

+
id: 1.4.1
+  text: "Ensure that the API server pod specification file permissions are
+  set to 644 or more restrictive (Scored)"
+  audit: "/bin/sh -c 'if test -e $apiserverconf; then stat -c %a $apiserverconf; fi'"
+
+
    +
  • svcs: A list of candidate unitfiles for a component. kube-bench checks this + list and selects the first unitfile that is found on the node. If none of the + unitfiles exists, kube-bench defaults unitfile to the value of defaultsvc.
    • +
+

The selected unitfile for a component can be referenced in controls via a + variable in the form $<component>svc. In the example below, the selected + kubelet unitfile is referenced with $kubeletsvc in the remediation of the + check.

+
id: 2.1.1
+  # ...
+  remediation: |
+    Edit the kubelet service file $kubeletsvc
+    on each worker node and set the below parameter in KUBELET_SYSTEM_PODS_ARGS variable.
+    --allow-privileged=false
+    Based on your system, restart the kubelet service. For example:
+    systemctl daemon-reload
+    systemctl restart kubelet.service
+  # ...
+
+
    +
  • +

    kubeconfig: A list of candidate kubeconfig files for a component. kube-bench + checks this list and selects the first file that is found on the node. If none + of the files exists, kube-bench defaults kubeconfig to the value of + defaultkubeconfig.

    +

    The selected kubeconfig for a component can be referenced in controls with a variable in the form $<component>kubeconfig. In the example below, the +selected kubelet kubeconfig is referenced with $kubeletkubeconfig in the +audit command.

    +
    id: 2.2.1
+  text: "Ensure that the kubelet.conf file permissions are set to 644 or
+  more restrictive (Scored)"
+  audit: "/bin/sh -c 'if test -e $kubeletkubeconfig; then stat -c %a $kubeletkubeconfig; fi'"
+  # ...
+
    +
    • +
+ + + + + + + +
+
+ + + +
+ +
+ +
+ +
+
+
+ + +
+ +
+
+
+ +
+
+
+
+ + + + + + + + + \ No newline at end of file diff --git a/v0.6.15/flags-and-commands/index.html b/v0.6.15/flags-and-commands/index.html new file mode 100644 index 0000000..9d3fbdd --- /dev/null +++ b/v0.6.15/flags-and-commands/index.html @@ -0,0 +1,1130 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Flags - Kube-bench + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ +
+ + + + + + + + +
+ + +
+ +
+ + + + + + +
+
+ + + +
+
+
+ + + + + +
+
+
+ + + +
+
+
+ + + +
+
+
+ + + +
+ +
+ + + + +

Flags

+ +

Commands

+ + + + + + + + + + + + + + + + + + + + + +
CommandDescription
helpPrints help about any command
runList of components to run
versionPrint kube-bench version
+

Flags

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
FlagDescription
--alsologtostderrlog to standard error as well as files
--asffSend findings to AWS Security Hub for any benchmark tests that fail or that generate a warning. See [this page][kube-bench-aws-security-hub] for more information on how to enable the kube-bench integration with AWS Security Hub.
--benchmarkManually specify CIS benchmark version
-c, --checkA comma-delimited list of checks to run as specified in Benchmark document.
--configconfig file (default is ./cfg/config.yaml)
--exit-codeSpecify the exit code for when checks fail
--groupRun all the checks under this comma-delimited list of groups.
--include-test-outputPrints the actual result when test fails.
--jsonPrints the results as JSON
--junitPrints the results as JUnit
--log_backtrace_at traceLocationwhen logging hits line file:N, emit a stack trace (default :0)
--logtostderrlog to standard error instead of files
--noremediationsDisable printing of remediations section to stdout.
--noresultsDisable printing of results section to stdout.
--nototalsDisable calculating and printing of totals for failed, passed, ... checks across all sections
--outputfileWrites the results to output file when run with --json or --junit
--pgsqlSave the results to PostgreSQL
--scoredRun the scored CIS checks (default true)
--skip stringList of comma separated values of checks to be skipped
--stderrthreshold severitylogs at or above this threshold go to stderr (default 2)
-v, --v Levellog level for V logs (default 0)
--unscoredRun the unscored CIS checks (default true)
--version stringManually specify Kubernetes version, automatically detected if unset
--vmodule moduleSpeccomma-separated list of pattern=N settings for file-filtered logging
+

Examples

+

Report kube-bench findings to AWS Security Hub

+

You can configure kube-bench with the --asff option to send findings to AWS Security Hub for any benchmark tests that fail or that generate a warning. See this page for more information on how to enable the kube-bench integration with AWS Security Hub.

+

Specifying the benchmark or Kubernetes version

+

kube-bench uses the Kubernetes API, or access to the kubectl or kubelet executables to try to determine the Kubernetes version, and hence which benchmark to run. If you wish to override this, or if none of these methods are available, you can specify either the Kubernetes version or CIS Benchmark as a command line parameter.

+

You can specify a particular version of Kubernetes by setting the --version flag or with the KUBE_BENCH_VERSION environment variable. The value of --version takes precedence over the value of KUBE_BENCH_VERSION.

+

For example, run kube-bench using the tests for Kubernetes version 1.13:

+
kube-bench --version 1.13
+
+

You can specify --benchmark to run a specific CIS Benchmark version:

+
kube-bench --benchmark cis-1.5
+
+

Note: It is an error to specify both --version and --benchmark flags together

+

Specifying Benchmark sections

+

If you want to run specific CIS Benchmark sections (i.e master, node, etcd, etc...) +you can use the run --targets subcommand.

+
kube-bench run --targets master,node
+
+

or

+
kube-bench run --targets master,node,etcd,policies
+
+

If no targets are specified, kube-bench will determine the appropriate targets based on the CIS Benchmark version and the components detected on the node. The detection is done by verifying which components are running, as defined in the config files (see Configuration.

+

Run specific check or group

+

kube-bench supports running individual checks by specifying the check's id +as a comma-delimited list on the command line with the --check | -c flag. +kube-bench --check="1.1.1,1.1.2,1.2.1,1.3.3"

+

kube-bench supports running all checks under group by specifying the group's id +as a comma-delimited list on the command line with the --group | -g flag. +kube-bench --check="1.1,2.2" +Will run all checks 1.1.X and 2.2.X.

+

Skip specific check or group

+

kube-bench supports skipping checks or groups by specifying the id +as a comma-delimited list on the command line with the --skip flag. +kube-bench --skip="1.1,1.2.1,1.3.3" +Will skip 1.1.X group and individual checks 1.2.1, 1.3.3. +Skipped checks returns [INFO] output.

+

Exit code

+

kube-bench supports using uniqe exit code when failing a check or more. +kube-bench --exit-code 42 +Will return 42 if one check or more failed, and 0 incase none failed. +Note: [WARN] is not [FAIL].

+

Output manipulation flags

+

There are four output states: +- [PASS] indicates that the test was run successfully, and passed. +- [FAIL] indicates that the test was run successfully, and failed. The remediation output describes how to correct the configuration, or includes an error message describing why the test could not be run. +- [WARN] means this test needs further attention, for example it is a test that needs to be run manually. Check the remediation output for further information. +- [INFO] is informational output that needs no further action.

+

Note: +- Some tests with Automated in their description must still be run manually +- If the user has to run a test manually, this always generates WARN +- If the test is Scored, and kube-bench was unable to run the test, this generates FAIL (because the test has not been passed, and as a Scored test, if it doesn't pass then it must be considered a failure). +- If the test is Not Scored, and kube-bench was unable to run the test, this generates WARN. +- If the test is Scored, type is empty, and there are no test_items present, it generates a WARN. This is to highlight tests that appear to be incompletely defined.

+

kube-bench supports multiple output manipulation flags. +kube-bench --include-test-output will print failing checks output in the results section +

[INFO] 1 Master Node Security Configuration
+[INFO] 1.1 Master Node Configuration Files
+[FAIL] 1.1.1 Ensure that the API server pod specification file permissions are set to 644 or more restrictive (Automated)
+         **permissions=777**
+

+

Note: --noresults --noremediations and --include-test-output will not effect the json output but only stdout. +Only --nototals will effect the json output and thats because it will not call the function to calculate totals.

+

Troubleshooting

+

Running kube-bench with the -v 3 parameter will generate debug logs that can be very helpful for debugging problems.

+

If you are using one of the example job*.yaml files, you will need to edit the command field, for example ["kube-bench", "-v", "3"]. Once the job has run, the logs can be retrieved using kubectl logs on the job's pod.

+ + + + + + + +
+
+ + + +
+ +
+ +
+ +
+
+
+ + +
+ +
+
+
+ +
+
+
+
+ + + + + + + + + \ No newline at end of file diff --git a/v0.6.15/images/asff-example-finding.png b/v0.6.15/images/asff-example-finding.png new file mode 100644 index 0000000..eb545ac Binary files /dev/null and b/v0.6.15/images/asff-example-finding.png differ diff --git a/v0.6.15/images/kube-bench-logo-only.png b/v0.6.15/images/kube-bench-logo-only.png new file mode 100644 index 0000000..6c56bfa Binary files /dev/null and b/v0.6.15/images/kube-bench-logo-only.png differ diff --git a/v0.6.15/images/kube-bench-security-hub.png b/v0.6.15/images/kube-bench-security-hub.png new file mode 100644 index 0000000..18cf056 Binary files /dev/null and b/v0.6.15/images/kube-bench-security-hub.png differ diff --git a/v0.6.15/images/kube-bench.jpg b/v0.6.15/images/kube-bench.jpg new file mode 100644 index 0000000..8174b52 Binary files /dev/null and b/v0.6.15/images/kube-bench.jpg differ diff --git a/v0.6.15/images/kube-bench.png b/v0.6.15/images/kube-bench.png new file mode 100644 index 0000000..6317992 Binary files /dev/null and b/v0.6.15/images/kube-bench.png differ diff --git a/v0.6.15/images/kube-bench.svg b/v0.6.15/images/kube-bench.svg new file mode 100644 index 0000000..928c3e8 --- /dev/null +++ b/v0.6.15/images/kube-bench.svg @@ -0,0 +1,86 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/v0.6.15/images/output.png b/v0.6.15/images/output.png new file mode 100644 index 0000000..b9c4d35 Binary files /dev/null and b/v0.6.15/images/output.png differ diff --git a/v0.6.15/index.html b/v0.6.15/index.html new file mode 100644 index 0000000..773f83f --- /dev/null +++ b/v0.6.15/index.html @@ -0,0 +1,650 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + Kube-bench + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ +
+ + + + + + + + +
+ + +
+ +
+ + + + + + +
+
+ + + +
+
+
+ + + + + +
+
+
+ + + +
+
+
+ + + +
+
+
+ + + +
+ +
+ + + + +

Kube-bench Logo +GitHub Release +Downloads +Docker Pulls +Go Report Card +Build Status +License +Coverage Status

+

Kube-bench

+

kube-bench is a Go application that checks whether Kubernetes is deployed securely by running the checks documented in the CIS Kubernetes Benchmark.

+

Tests are configured with YAML files, making this tool easy to update as test specifications evolve.

+
    +
  1. +

    kube-bench implements the CIS Kubernetes Benchmark as closely as possible. Please raise issues here if kube-bench is not correctly implementing the test as described in the Benchmark. To report issues in the Benchmark itself (for example, tests that you believe are inappropriate), please join the CIS community.

    +
    2. +
  2. +

    There is not a one-to-one mapping between releases of Kubernetes and releases of the CIS benchmark. See CIS Kubernetes Benchmark support to see which releases of Kubernetes are covered by different releases of the benchmark.

    +
    3. +
  3. +

    It is impossible to inspect the master nodes of managed clusters, e.g. GKE, EKS, AKS and ACK, using kube-bench as one does not have access to such nodes, although it is still possible to use kube-bench to check worker node configuration in these environments.

    +
    4. +
+

For help and more information go to our github discussions q&a

+ + + + + + + +
+
+ + + +
+ +
+ +
+ +
+
+
+ + +
+ +
+
+
+ +
+
+
+
+ + + + + + + + + \ No newline at end of file diff --git a/v0.6.15/installation/index.html b/v0.6.15/installation/index.html new file mode 100644 index 0000000..53ac28c --- /dev/null +++ b/v0.6.15/installation/index.html @@ -0,0 +1,832 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Installation - Kube-bench + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ +
+ + + + + + + + +
+ + +
+ +
+ + + + + + +
+
+ + + +
+
+
+ + + + + +
+
+
+ + + +
+
+
+ + + +
+
+
+ + + +
+ +
+ + + + +

Installation

+ +

Installation

+

You can choose to +* Run kube-bench from inside a container (sharing PID namespace with the host). See Running inside a container for additional details. +* Run a container that installs kube-bench on the host, and then run kube-bench directly on the host. See Installing from a container for additional details. +* install the latest binaries from the Releases page, though please note that you also need to download the config and test files from the cfg directory. See Download and Install binaries for details. +* Compile it from source. See Installing from sources for details.

+

Download and Install binaries

+

It is possible to manually install and run kube-bench release binaries. In order to do that, you must have access to your Kubernetes cluster nodes. Note that if you're using one of the managed Kubernetes services (e.g. EKS, AKS, GKE, ACK, OCP), you will not have access to the master nodes of your cluster and you can’t perform any tests on the master nodes.

+

First, log into one of the nodes using SSH.

+

Install kube-bench binary for your platform using the commands below. Note that there may be newer releases available. See releases page.

+

Ubuntu/Debian:

+
curl -L https://github.com/aquasecurity/kube-bench/releases/download/v0.6.2/kube-bench_0.6.2_linux_amd64.deb -o kube-bench_0.6.2_linux_amd64.deb
+
+sudo apt install ./kube-bench_0.6.2_linux_amd64.deb -f
+
+

RHEL:

+
curl -L https://github.com/aquasecurity/kube-bench/releases/download/v0.6.2/kube-bench_0.6.2_linux_amd64.rpm -o kube-bench_0.6.2_linux_amd64.rpm
+
+sudo yum install kube-bench_0.6.2_linux_amd64.rpm -y
+
+

Alternatively, you can manually download and extract the kube-bench binary:

+
curl -L https://github.com/aquasecurity/kube-bench/releases/download/v0.6.2/kube-bench_0.6.2_linux_amd64.tar.gz -o kube-bench_0.6.2_linux_amd64.tar.gz
+
+tar -xvf kube-bench_0.6.2_linux_amd64.tar.gz
+
+

You can then run kube-bench directly: +

kube-bench
+

+

If you manually downloaded the kube-bench binary (using curl command above), you have to specify the location of configuration directory and file. For example: +

./kube-bench --config-dir `pwd`/cfg --config `pwd`/cfg/config.yaml 
+

+

See previous section on Running kube-bench for further details on using the kube-bench binary.

+

Installing from sources

+

If Go is installed on the target machines, you can simply clone this repository and run as follows (assuming your GOPATH is set) as per this example:

+
# Create a target directory for the clone, inside the $GOPATH
+mkdir -p $GOPATH/src/github.com/aquasecurity/kube-bench
+
+# Clone this repository, using SSH
+git clone git@github.com:aquasecurity/kube-bench.git $GOPATH/src/github.com/aquasecurity/kube-bench
+
+# Install the pre-requisites
+go get github.com/aquasecurity/kube-bench
+
+# Change to the kube-bench directory
+cd $GOPATH/src/github.com/aquasecurity/kube-bench
+
+# Build the kube-bench binary
+go build -o kube-bench .
+
+# See all supported options
+./kube-bench --help
+
+# Run all checks
+./kube-bench
+
+

Installing from a container

+

This command copies the kube-bench binary and configuration files to your host from the Docker container: +binaries compiled for linux-x86-64 only (so they won't run on macOS or Windows) +

docker run --rm -v `pwd`:/host docker.io/aquasec/kube-bench:latest install
+

+

You can then run ./kube-bench.

+ + + + + + + +
+
+ + + +
+ +
+ +
+ +
+
+
+ + +
+ +
+
+
+ +
+
+
+
+ + + + + + + + + \ No newline at end of file diff --git a/v0.6.15/platforms/index.html b/v0.6.15/platforms/index.html new file mode 100644 index 0000000..efa595f --- /dev/null +++ b/v0.6.15/platforms/index.html @@ -0,0 +1,819 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Platforms - Kube-bench + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ +
+ + + + + + + + +
+ + +
+ +
+ + + + + + +
+
+ + + +
+
+
+ + + + + +
+
+
+ + + +
+
+
+ + + +
+
+
+ + + +
+ +
+ + + + +

Platforms

+ +

CIS Kubernetes Benchmark support

+

kube-bench supports running tests for Kubernetes. +Most of our supported benchmarks are defined in one of the following: + CIS Kubernetes Benchmarks + STIG Document Library

+

Some defined by other hardenening guides.

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
SourceKubernetes Benchmarkkube-bench configKubernetes versions
CIS1.5.1cis-1.51.15
CIS1.6.0cis-1.61.16-1.18
CIS1.20cis-1.201.19-1.21
CIS1.23cis-1.231.22-1.23
CIS1.24cis-1.241.24
CIS1.7cis-1.71.25
CISGKE 1.0.0gke-1.0GKE
CISGKE 1.2.0gke-1.2.0GKE
CISEKS 1.0.1eks-1.0.1EKS
CISEKS 1.1.0eks-1.1.0EKS
CISEKS 1.2.0eks-1.2.0EKS
CISACK 1.0.0ack-1.0ACK
CISAKS 1.0.0aks-1.0AKS
RHELRedHat OpenShift hardening guiderh-0.7OCP 3.10-3.11
CISOCP4 1.1.0rh-1.0OCP 4.1-
CIS1.6.0-k3scis-1.6-k3sk3s v1.16-v1.24
DISAKubernetes Ver 1, Rel 6eks-stig-kubernetes-v1r6EKS
CISTKGI 1.2.53tkgi-1.2.53vmware
+ + + + + + + +
+
+ + + +
+ +
+ +
+ +
+
+
+ + +
+ +
+
+
+ +
+
+
+
+ + + + + + + + + \ No newline at end of file diff --git a/v0.6.15/plugins/social/layouts/default.yml b/v0.6.15/plugins/social/layouts/default.yml new file mode 100644 index 0000000..d67e318 --- /dev/null +++ b/v0.6.15/plugins/social/layouts/default.yml @@ -0,0 +1,221 @@ +# Copyright (c) 2016-2023 Martin Donath + +# Permission is hereby granted, free of charge, to any person obtaining a copy +# of this software and associated documentation files (the "Software"), to +# deal in the Software without restriction, including without limitation the +# rights to use, copy, modify, merge, publish, distribute, sublicense, and/or +# sell copies of the Software, and to permit persons to whom the Software is +# furnished to do so, subject to the following conditions: + +# The above copyright notice and this permission notice shall be included in +# all copies or substantial portions of the Software. + +# THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR +# IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, +# FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO EVENT SHALL THE +# AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER +# LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING +# FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS +# IN THE SOFTWARE. + +# ----------------------------------------------------------------------------- +# Configuration +# ----------------------------------------------------------------------------- + +# Definitions +definitions: + + # Background image + - &background_image >- + {{ layout.background_image or "" }} + + # Background color (default: indigo) + - &background_color >- + {%- if layout.background_color -%} + {{ layout.background_color }} + {%- else -%} + {%- set palette = config.theme.palette or {} -%} + {%- if not palette is mapping -%} + {%- set palette = palette | first -%} + {%- endif -%} + {%- set primary = palette.get("primary", "indigo") -%} + {%- set primary = primary.replace(" ", "-") -%} + {{ { + "red": "#ef5552", + "pink": "#e92063", + "purple": "#ab47bd", + "deep-purple": "#7e56c2", + "indigo": "#4051b5", + "blue": "#2094f3", + "light-blue": "#02a6f2", + "cyan": "#00bdd6", + "teal": "#009485", + "green": "#4cae4f", + "light-green": "#8bc34b", + "lime": "#cbdc38", + "yellow": "#ffec3d", + "amber": "#ffc105", + "orange": "#ffa724", + "deep-orange": "#ff6e42", + "brown": "#795649", + "grey": "#757575", + "blue-grey": "#546d78", + "black": "#000000", + "white": "#ffffff" + }[primary] or "#4051b5" }} + {%- endif -%} + + # Text color (default: white) + - &color >- + {%- if layout.color -%} + {{ layout.color }} + {%- else -%} + {%- set palette = config.theme.palette or {} -%} + {%- if not palette is mapping -%} + {%- set palette = palette | first -%} + {%- endif -%} + {%- set primary = palette.get("primary", "indigo") -%} + {%- set primary = primary.replace(" ", "-") -%} + {{ { + "red": "#ffffff", + "pink": "#ffffff", + "purple": "#ffffff", + "deep-purple": "#ffffff", + "indigo": "#ffffff", + "blue": "#ffffff", + "light-blue": "#ffffff", + "cyan": "#ffffff", + "teal": "#ffffff", + "green": "#ffffff", + "light-green": "#ffffff", + "lime": "#000000", + "yellow": "#000000", + "amber": "#000000", + "orange": "#000000", + "deep-orange": "#ffffff", + "brown": "#ffffff", + "grey": "#ffffff", + "blue-grey": "#ffffff", + "black": "#ffffff", + "white": "#000000" + }[primary] or "#ffffff" }} + {%- endif -%} + + # Font family (default: Roboto) + - &font_family >- + {%- if layout.font_family -%} + {{ layout.font_family }} + {%- elif config.theme.font != false -%} + {{ config.theme.font.get("text", "Roboto") }} + {%- else -%} + Roboto + {%- endif -%} + + # Site name + - &site_name >- + {{ config.site_name }} + + # Page title + - &page_title >- + {{ page.meta.get("title", page.title) }} + + # Page title with site name + - &page_title_with_site_name >- + {%- if not page.is_homepage -%} + {{ page.meta.get("title", page.title) }} - {{ config.site_name }} + {%- else -%} + {{ page.meta.get("title", page.title) }} + {%- endif -%} + + # Page description + - &page_description >- + {{ page.meta.get("description", config.site_description) or "" }} + + # Logo + - &logo >- + {%- if config.theme.logo -%} + {{ config.docs_dir }}/{{ config.theme.logo }} + {%- endif -%} + + # Logo (icon) + - &logo_icon >- + {{ config.theme.icon.logo or "" }} + +# Meta tags +tags: + + # Open Graph + og:type: website + og:title: *page_title_with_site_name + og:description: *page_description + og:image: "{{ image.url }}" + og:image:type: "{{ image.type }}" + og:image:width: "{{ image.width }}" + og:image:height: "{{ image.height }}" + og:url: "{{ page.canonical_url }}" + + # Twitter + twitter:card: summary_large_image + twitter.title: *page_title_with_site_name + twitter:description: *page_description + twitter:image: "{{ image.url }}" + +# ----------------------------------------------------------------------------- +# Specification +# ----------------------------------------------------------------------------- + +# Card size and layers +size: { width: 1200, height: 630 } +layers: + + # Background + - background: + image: *background_image + color: *background_color + + # Logo + - size: { width: 144, height: 144 } + offset: { x: 992, y: 64 } + background: + image: *logo + icon: + value: *logo_icon + color: *color + + # Site name + - size: { width: 832, height: 42 } + offset: { x: 64, y: 64 } + typography: + content: *site_name + color: *color + font: + family: *font_family + style: Bold + + # Page title + - size: { width: 832, height: 310 } + offset: { x: 62, y: 160 } + typography: + content: *page_title + align: start + color: *color + line: + amount: 3 + height: 1.25 + font: + family: *font_family + style: Bold + + # Page description + - size: { width: 832, height: 64 } + offset: { x: 64, y: 512 } + typography: + content: *page_description + align: start + color: *color + line: + amount: 2 + height: 1.5 + font: + family: *font_family + style: Regular diff --git a/v0.6.15/plugins/social/layouts/default/accent.yml b/v0.6.15/plugins/social/layouts/default/accent.yml new file mode 100644 index 0000000..99684c7 --- /dev/null +++ b/v0.6.15/plugins/social/layouts/default/accent.yml @@ -0,0 +1,211 @@ +# Copyright (c) 2016-2023 Martin Donath + +# Permission is hereby granted, free of charge, to any person obtaining a copy +# of this software and associated documentation files (the "Software"), to +# deal in the Software without restriction, including without limitation the +# rights to use, copy, modify, merge, publish, distribute, sublicense, and/or +# sell copies of the Software, and to permit persons to whom the Software is +# furnished to do so, subject to the following conditions: + +# The above copyright notice and this permission notice shall be included in +# all copies or substantial portions of the Software. + +# THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR +# IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, +# FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO EVENT SHALL THE +# AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER +# LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING +# FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS +# IN THE SOFTWARE. + +# ----------------------------------------------------------------------------- +# Configuration +# ----------------------------------------------------------------------------- + +# Definitions +definitions: + + # Background image + - &background_image >- + {{ layout.background_image or "" }} + + # Background color (default: indigo) + - &background_color >- + {%- if layout.background_color -%} + {{ layout.background_color }} + {%- else -%} + {%- set palette = config.theme.palette or {} -%} + {%- if not palette is mapping -%} + {%- set palette = palette | first -%} + {%- endif -%} + {%- set accent = palette.get("accent", "indigo") -%} + {%- set accent = accent.replace(" ", "-") -%} + {{ { + "red": "#ff1a47", + "pink": "#f50056", + "purple": "#df41fb", + "deep-purple": "#7c4dff", + "indigo": "#526cfe", + "blue": "#4287ff", + "light-blue": "#0091eb", + "cyan": "#00bad6", + "teal": "#00bda4", + "green": "#00c753", + "light-green": "#63de17", + "lime": "#b0eb00", + "yellow": "#ffd500", + "amber": "#ffaa00", + "orange": "#ff9100", + "deep-orange": "#ff6e42" + }[accent] or "#4051b5" }} + {%- endif -%} + + # Text color (default: white) + - &color >- + {%- if layout.color -%} + {{ layout.color }} + {%- else -%} + {%- set palette = config.theme.palette or {} -%} + {%- if not palette is mapping -%} + {%- set palette = palette | first -%} + {%- endif -%} + {%- set accent = palette.get("accent", "indigo") -%} + {%- set accent = accent.replace(" ", "-") -%} + {{ { + "red": "#ffffff", + "pink": "#ffffff", + "purple": "#ffffff", + "deep-purple": "#ffffff", + "indigo": "#ffffff", + "blue": "#ffffff", + "light-blue": "#ffffff", + "cyan": "#ffffff", + "teal": "#ffffff", + "green": "#ffffff", + "light-green": "#ffffff", + "lime": "#000000", + "yellow": "#000000", + "amber": "#000000", + "orange": "#000000", + "deep-orange": "#ffffff" + }[accent] or "#ffffff" }} + {%- endif -%} + + # Font family (default: Roboto) + - &font_family >- + {%- if layout.font_family -%} + {{ layout.font_family }} + {%- elif config.theme.font != false -%} + {{ config.theme.font.get("text", "Roboto") }} + {%- else -%} + Roboto + {%- endif -%} + + # Site name + - &site_name >- + {{ config.site_name }} + + # Page title + - &page_title >- + {{ page.meta.get("title", page.title) }} + + # Page title with site name + - &page_title_with_site_name >- + {%- if not page.is_homepage -%} + {{ page.meta.get("title", page.title) }} - {{ config.site_name }} + {%- else -%} + {{ page.meta.get("title", page.title) }} + {%- endif -%} + + # Page description + - &page_description >- + {{ page.meta.get("description", config.site_description) or "" }} + + # Logo + - &logo >- + {%- if config.theme.logo -%} + {{ config.docs_dir }}/{{ config.theme.logo }} + {%- endif -%} + + # Logo (icon) + - &logo_icon >- + {{ config.theme.icon.logo or "" }} + +# Meta tags +tags: + + # Open Graph + og:type: website + og:title: *page_title_with_site_name + og:description: *page_description + og:image: "{{ image.url }}" + og:image:type: "{{ image.type }}" + og:image:width: "{{ image.width }}" + og:image:height: "{{ image.height }}" + og:url: "{{ page.canonical_url }}" + + # Twitter + twitter:card: summary_large_image + twitter.title: *page_title_with_site_name + twitter:description: *page_description + twitter:image: "{{ image.url }}" + +# ----------------------------------------------------------------------------- +# Specification +# ----------------------------------------------------------------------------- + +# Card size and layers +size: { width: 1200, height: 630 } +layers: + + # Background + - background: + image: *background_image + color: *background_color + + # Logo + - size: { width: 144, height: 144 } + offset: { x: 992, y: 64 } + background: + image: *logo + icon: + value: *logo_icon + color: *color + + # Site name + - size: { width: 832, height: 42 } + offset: { x: 64, y: 64 } + typography: + content: *site_name + color: *color + font: + family: *font_family + style: Bold + + # Page title + - size: { width: 832, height: 310 } + offset: { x: 62, y: 160 } + typography: + content: *page_title + align: start + color: *color + line: + amount: 3 + height: 1.25 + font: + family: *font_family + style: Bold + + # Page description + - size: { width: 832, height: 64 } + offset: { x: 64, y: 512 } + typography: + content: *page_description + align: start + color: *color + line: + amount: 2 + height: 1.5 + font: + family: *font_family + style: Regular diff --git a/v0.6.15/plugins/social/layouts/default/invert.yml b/v0.6.15/plugins/social/layouts/default/invert.yml new file mode 100644 index 0000000..eddc02e --- /dev/null +++ b/v0.6.15/plugins/social/layouts/default/invert.yml @@ -0,0 +1,221 @@ +# Copyright (c) 2016-2023 Martin Donath + +# Permission is hereby granted, free of charge, to any person obtaining a copy +# of this software and associated documentation files (the "Software"), to +# deal in the Software without restriction, including without limitation the +# rights to use, copy, modify, merge, publish, distribute, sublicense, and/or +# sell copies of the Software, and to permit persons to whom the Software is +# furnished to do so, subject to the following conditions: + +# The above copyright notice and this permission notice shall be included in +# all copies or substantial portions of the Software. + +# THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR +# IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, +# FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO EVENT SHALL THE +# AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER +# LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING +# FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS +# IN THE SOFTWARE. + +# ----------------------------------------------------------------------------- +# Configuration +# ----------------------------------------------------------------------------- + +# Definitions +definitions: + + # Background image + - &background_image >- + {{ layout.background_image or "" }} + + # Background color (default: white) + - &background_color >- + {%- if layout.background_color -%} + {{ layout.background_color }} + {%- else -%} + {%- set palette = config.theme.palette or {} -%} + {%- if not palette is mapping -%} + {%- set palette = palette | first -%} + {%- endif -%} + {%- set primary = palette.get("primary", "indigo") -%} + {%- set primary = primary.replace(" ", "-") -%} + {{ { + "red": "#ffffff", + "pink": "#ffffff", + "purple": "#ffffff", + "deep-purple": "#ffffff", + "indigo": "#ffffff", + "blue": "#ffffff", + "light-blue": "#ffffff", + "cyan": "#ffffff", + "teal": "#ffffff", + "green": "#ffffff", + "light-green": "#ffffff", + "lime": "#000000", + "yellow": "#000000", + "amber": "#000000", + "orange": "#000000", + "deep-orange": "#ffffff", + "brown": "#ffffff", + "grey": "#ffffff", + "blue-grey": "#ffffff", + "black": "#ffffff", + "white": "#000000" + }[primary] or "#ffffff" }} + {%- endif -%} + + # Text color (default: indigo) + - &color >- + {%- if layout.color -%} + {{ layout.color }} + {%- else -%} + {%- set palette = config.theme.palette or {} -%} + {%- if not palette is mapping -%} + {%- set palette = palette | first -%} + {%- endif -%} + {%- set primary = palette.get("primary", "indigo") -%} + {%- set primary = primary.replace(" ", "-") -%} + {{ { + "red": "#ef5552", + "pink": "#e92063", + "purple": "#ab47bd", + "deep-purple": "#7e56c2", + "indigo": "#4051b5", + "blue": "#2094f3", + "light-blue": "#02a6f2", + "cyan": "#00bdd6", + "teal": "#009485", + "green": "#4cae4f", + "light-green": "#8bc34b", + "lime": "#cbdc38", + "yellow": "#ffec3d", + "amber": "#ffc105", + "orange": "#ffa724", + "deep-orange": "#ff6e42", + "brown": "#795649", + "grey": "#757575", + "blue-grey": "#546d78", + "black": "#000000", + "white": "#ffffff" + }[primary] or "#4051b5" }} + {%- endif -%} + + # Font family (default: Roboto) + - &font_family >- + {%- if layout.font_family -%} + {{ layout.font_family }} + {%- elif config.theme.font != false -%} + {{ config.theme.font.get("text", "Roboto") }} + {%- else -%} + Roboto + {%- endif -%} + + # Site name + - &site_name >- + {{ config.site_name }} + + # Page title + - &page_title >- + {{ page.meta.get("title", page.title) }} + + # Page title with site name + - &page_title_with_site_name >- + {%- if not page.is_homepage -%} + {{ page.meta.get("title", page.title) }} - {{ config.site_name }} + {%- else -%} + {{ page.meta.get("title", page.title) }} + {%- endif -%} + + # Page description + - &page_description >- + {{ page.meta.get("description", config.site_description) or "" }} + + # Logo + - &logo >- + {%- if config.theme.logo -%} + {{ config.docs_dir }}/{{ config.theme.logo }} + {%- endif -%} + + # Logo (icon) + - &logo_icon >- + {{ config.theme.icon.logo or "" }} + +# Meta tags +tags: + + # Open Graph + og:type: website + og:title: *page_title_with_site_name + og:description: *page_description + og:image: "{{ image.url }}" + og:image:type: "{{ image.type }}" + og:image:width: "{{ image.width }}" + og:image:height: "{{ image.height }}" + og:url: "{{ page.canonical_url }}" + + # Twitter + twitter:card: summary_large_image + twitter.title: *page_title_with_site_name + twitter:description: *page_description + twitter:image: "{{ image.url }}" + +# ----------------------------------------------------------------------------- +# Specification +# ----------------------------------------------------------------------------- + +# Card size and layers +size: { width: 1200, height: 630 } +layers: + + # Background + - background: + image: *background_image + color: *background_color + + # Logo + - size: { width: 144, height: 144 } + offset: { x: 992, y: 64 } + background: + image: *logo + icon: + value: *logo_icon + color: *color + + # Site name + - size: { width: 832, height: 42 } + offset: { x: 64, y: 64 } + typography: + content: *site_name + color: *color + font: + family: *font_family + style: Bold + + # Page title + - size: { width: 832, height: 310 } + offset: { x: 62, y: 160 } + typography: + content: *page_title + align: start + color: *color + line: + amount: 3 + height: 1.25 + font: + family: *font_family + style: Bold + + # Page description + - size: { width: 832, height: 64 } + offset: { x: 64, y: 512 } + typography: + content: *page_description + align: start + color: *color + line: + amount: 2 + height: 1.5 + font: + family: *font_family + style: Regular diff --git a/v0.6.15/plugins/social/layouts/default/variant.yml b/v0.6.15/plugins/social/layouts/default/variant.yml new file mode 100644 index 0000000..158d2e8 --- /dev/null +++ b/v0.6.15/plugins/social/layouts/default/variant.yml @@ -0,0 +1,232 @@ +# Copyright (c) 2016-2023 Martin Donath + +# Permission is hereby granted, free of charge, to any person obtaining a copy +# of this software and associated documentation files (the "Software"), to +# deal in the Software without restriction, including without limitation the +# rights to use, copy, modify, merge, publish, distribute, sublicense, and/or +# sell copies of the Software, and to permit persons to whom the Software is +# furnished to do so, subject to the following conditions: + +# The above copyright notice and this permission notice shall be included in +# all copies or substantial portions of the Software. + +# THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR +# IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, +# FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO EVENT SHALL THE +# AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER +# LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING +# FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS +# IN THE SOFTWARE. + +# ----------------------------------------------------------------------------- +# Configuration +# ----------------------------------------------------------------------------- + +# Definitions +definitions: + + # Background image + - &background_image >- + {{ layout.background_image or "" }} + + # Background color (default: indigo) + - &background_color >- + {%- if layout.background_color -%} + {{ layout.background_color }} + {%- else -%} + {%- set palette = config.theme.palette or {} -%} + {%- if not palette is mapping -%} + {%- set palette = palette | first -%} + {%- endif -%} + {%- set primary = palette.get("primary", "indigo") -%} + {%- set primary = primary.replace(" ", "-") -%} + {{ { + "red": "#ef5552", + "pink": "#e92063", + "purple": "#ab47bd", + "deep-purple": "#7e56c2", + "indigo": "#4051b5", + "blue": "#2094f3", + "light-blue": "#02a6f2", + "cyan": "#00bdd6", + "teal": "#009485", + "green": "#4cae4f", + "light-green": "#8bc34b", + "lime": "#cbdc38", + "yellow": "#ffec3d", + "amber": "#ffc105", + "orange": "#ffa724", + "deep-orange": "#ff6e42", + "brown": "#795649", + "grey": "#757575", + "blue-grey": "#546d78", + "black": "#000000", + "white": "#ffffff" + }[primary] or "#4051b5" }} + {%- endif -%} + + # Text color (default: white) + - &color >- + {%- if layout.color -%} + {{ layout.color }} + {%- else -%} + {%- set palette = config.theme.palette or {} -%} + {%- if not palette is mapping -%} + {%- set palette = palette | first -%} + {%- endif -%} + {%- set primary = palette.get("primary", "indigo") -%} + {%- set primary = primary.replace(" ", "-") -%} + {{ { + "red": "#ffffff", + "pink": "#ffffff", + "purple": "#ffffff", + "deep-purple": "#ffffff", + "indigo": "#ffffff", + "blue": "#ffffff", + "light-blue": "#ffffff", + "cyan": "#ffffff", + "teal": "#ffffff", + "green": "#ffffff", + "light-green": "#ffffff", + "lime": "#000000", + "yellow": "#000000", + "amber": "#000000", + "orange": "#000000", + "deep-orange": "#ffffff", + "brown": "#ffffff", + "grey": "#ffffff", + "blue-grey": "#ffffff", + "black": "#ffffff", + "white": "#000000" + }[primary] or "#ffffff" }} + {%- endif -%} + + # Font family (default: Roboto) + - &font_family >- + {%- if layout.font_family -%} + {{ layout.font_family }} + {%- elif config.theme.font != false -%} + {{ config.theme.font.get("text", "Roboto") }} + {%- else -%} + Roboto + {%- endif -%} + + # Site name + - &site_name >- + {{ config.site_name }} + + # Page title + - &page_title >- + {{ page.meta.get("title", page.title) }} + + # Page title with site name + - &page_title_with_site_name >- + {%- if not page.is_homepage -%} + {{ page.meta.get("title", page.title) }} - {{ config.site_name }} + {%- else -%} + {{ page.meta.get("title", page.title) }} + {%- endif -%} + + # Page description + - &page_description >- + {{ page.meta.get("description", config.site_description) or "" }} + + # Page icon + - &page_icon >- + {{ page.meta.icon or "" }} + + # Logo + - &logo >- + {%- if config.theme.logo -%} + {{ config.docs_dir }}/{{ config.theme.logo }} + {%- endif -%} + + # Logo (icon) + - &logo_icon >- + {{ config.theme.icon.logo or "" }} + +# Meta tags +tags: + + # Open Graph + og:type: website + og:title: *page_title_with_site_name + og:description: *page_description + og:image: "{{ image.url }}" + og:image:type: "{{ image.type }}" + og:image:width: "{{ image.width }}" + og:image:height: "{{ image.height }}" + og:url: "{{ page.canonical_url }}" + + # Twitter + twitter:card: summary_large_image + twitter.title: *page_title_with_site_name + twitter:description: *page_description + twitter:image: "{{ image.url }}" + +# ----------------------------------------------------------------------------- +# Specification +# ----------------------------------------------------------------------------- + +# Card size and layers +size: { width: 1200, height: 630 } +layers: + + # Background + - background: + image: *background_image + color: *background_color + + # Page icon + - size: { width: 630, height: 630 } + offset: { x: 800, y: 0 } + icon: + value: *page_icon + color: "#00000033" + + # Logo + - size: { width: 64, height: 64 } + offset: { x: 64, y: 64 } + background: + image: *logo + icon: + value: *logo_icon + color: *color + + # Site name + - size: { width: 768, height: 42 } + offset: { x: 160, y: 74 } + typography: + content: *site_name + color: *color + font: + family: *font_family + style: Bold + + # Page title + - size: { width: 864, height: 256 } + offset: { x: 62, y: 192 } + typography: + content: *page_title + align: start + color: *color + line: + amount: 3 + height: 1.25 + font: + family: *font_family + style: Bold + + # Page description + - size: { width: 864, height: 64 } + offset: { x: 64, y: 512 } + typography: + content: *page_description + align: start + color: *color + line: + amount: 2 + height: 1.5 + font: + family: *font_family + style: Regular diff --git a/v0.6.15/running/index.html b/v0.6.15/running/index.html new file mode 100644 index 0000000..178e741 --- /dev/null +++ b/v0.6.15/running/index.html @@ -0,0 +1,1098 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + How to run - Kube-bench + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ +
+ + + + + + + + +
+ + +
+ +
+ + + + + + +
+
+ + + +
+
+
+ + + + + +
+
+
+ + + +
+
+
+ + + +
+
+
+ + + +
+ +
+ + + + +

How to run

+ +

Running kube-bench

+

If you run kube-bench directly from the command line you may need to be root / sudo to have access to all the config files.

+

By default kube-bench attempts to auto-detect the running version of Kubernetes, and map this to the corresponding CIS Benchmark version. For example, Kubernetes version 1.15 is mapped to CIS Benchmark version cis-1.15 which is the benchmark version valid for Kubernetes 1.15.

+

kube-bench also attempts to identify the components running on the node, and uses this to determine which tests to run (for example, only running the master node tests if the node is running an API server).

+

Please note +It is impossible to inspect the master nodes of managed clusters, e.g. GKE, EKS, AKS and ACK, using kube-bench as one does not have access to such nodes, although it is still possible to use kube-bench to check worker node configuration in these environments.

+

Running inside a container

+

You can avoid installing kube-bench on the host by running it inside a container using the host PID namespace and mounting the /etc and /var directories where the configuration and other files are located on the host so that kube-bench can check their existence and permissions.

+
docker run --pid=host -v /etc:/etc:ro -v /var:/var:ro -t docker.io/aquasec/kube-bench:latest --version 1.18
+
+
+

Note: the tests require either the kubelet or kubectl binary in the path in order to auto-detect the Kubernetes version. You can pass -v $(which kubectl):/usr/local/mount-from-host/bin/kubectl to resolve this. You will also need to pass in kubeconfig credentials. For example:

+
+
docker run --pid=host -v /etc:/etc:ro -v /var:/var:ro -v $(which kubectl):/usr/local/mount-from-host/bin/kubectl -v ~/.kube:/.kube -e KUBECONFIG=/.kube/config -t docker.io/aquasec/kube-bench:latest 
+
+

You can use your own configs by mounting them over the default ones in /opt/kube-bench/cfg/

+
docker run --pid=host -v /etc:/etc:ro -v /var:/var:ro -t -v path/to/my-config.yaml:/opt/kube-bench/cfg/config.yaml -v $(which kubectl):/usr/local/mount-from-host/bin/kubectl -v ~/.kube:/.kube -e KUBECONFIG=/.kube/config docker.io/aquasec/kube-bench:latest
+
+

Running in a Kubernetes cluster

+

You can run kube-bench inside a pod, but it will need access to the host's PID namespace in order to check the running processes, as well as access to some directories on the host where config files and other files are stored.

+

The job.yaml file (available in the root directory of the repository) can be applied to run the tests as a Kubernetes Job. For example:

+
$ kubectl apply -f job.yaml
+job.batch/kube-bench created
+
+$ kubectl get pods
+NAME                      READY   STATUS              RESTARTS   AGE
+kube-bench-j76s9   0/1     ContainerCreating   0          3s
+
+# Wait for a few seconds for the job to complete
+$ kubectl get pods
+NAME                      READY   STATUS      RESTARTS   AGE
+kube-bench-j76s9   0/1     Completed   0          11s
+
+# The results are held in the pod's logs
+kubectl logs kube-bench-j76s9
+[INFO] 1 Master Node Security Configuration
+[INFO] 1.1 API Server
+...
+
+

To run tests on the master node, the pod needs to be scheduled on that node. This involves setting a nodeSelector and tolerations in the pod spec.

+

The default labels applied to master nodes has changed since Kubernetes 1.11, so if you are using an older version you may need to modify the nodeSelector and tolerations to run the job on the master node.

+

Running in an AKS cluster

+
    +
  1. +

    Create an AKS cluster(e.g. 1.13.7) with RBAC enabled, otherwise there would be 4 failures

    +
    2. +
  2. +

    Use the kubectl-enter plugin to shell into a node +kubectl-enter {node-name} +or ssh to one agent node +could open nsg 22 port and assign a public ip for one agent node (only for testing purpose)

    +
    3. +
  3. +

    Run CIS benchmark to view results: +

    docker run --rm -v `pwd`:/host docker.io/aquasec/kube-bench:latest install
+./kube-bench 
+
    +kube-bench cannot be run on AKS master nodes

    +
    4. +
+

Running CIS benchmark in an EKS cluster

+

There is a job-eks.yaml file for running the kube-bench node checks on an EKS cluster. The significant difference on EKS is that it's not possible to schedule jobs onto the master node, so master checks can't be performed

+
    +
  1. To create an EKS Cluster refer to Getting Started with Amazon EKS in the Amazon EKS User Guide
    2. +
  2. Information on configuring eksctl, kubectl and the AWS CLI is within
    3. +
  3. Create an Amazon Elastic Container Registry (ECR) repository to host the kube-bench container image +
    aws ecr create-repository --repository-name k8s/kube-bench --image-tag-mutability MUTABLE
+
    4. +
  4. Download, build and push the kube-bench container image to your ECR repo +
    git clone https://github.com/aquasecurity/kube-bench.git
+cd kube-bench
+aws ecr get-login-password --region <AWS_REGION> | docker login --username AWS --password-stdin <AWS_ACCT_NUMBER>.dkr.ecr.<AWS_REGION>.amazonaws.com
+docker build -t k8s/kube-bench .
+docker tag k8s/kube-bench:latest <AWS_ACCT_NUMBER>.dkr.ecr.<AWS_REGION>.amazonaws.com/k8s/kube-bench:latest
+docker push <AWS_ACCT_NUMBER>.dkr.ecr.<AWS_REGION>.amazonaws.com/k8s/kube-bench:latest
+
    5. +
  5. Copy the URI of your pushed image, the URI format is like this: <AWS_ACCT_NUMBER>.dkr.ecr.<AWS_REGION>.amazonaws.com/k8s/kube-bench:latest
    6. +
  6. Replace the image value in job-eks.yaml with the URI from Step 4
    7. +
  7. Run the kube-bench job on a Pod in your Cluster: kubectl apply -f job-eks.yaml
    8. +
  8. Find the Pod that was created, it should be in the default namespace: kubectl get pods --all-namespaces
    9. +
  9. Retrieve the value of this Pod and output the report, note the Pod name will vary: kubectl logs kube-bench-<value>
    10. +
  10. You can save the report for later reference: kubectl logs kube-bench-<value> > kube-bench-report.txt
    11. +
+

Running DISA STIG in an EKS cluster

+

There is a job-eks-stig.yaml file for running the kube-bench node checks on an EKS cluster. The significant difference on EKS is that it's not possible to schedule jobs onto the master node, so master checks can't be performed

+
    +
  1. To create an EKS Cluster refer to Getting Started with Amazon EKS in the Amazon EKS User Guide
    2. +
  2. Information on configuring eksctl, kubectl and the AWS CLI is within
    3. +
  3. Create an Amazon Elastic Container Registry (ECR) repository to host the kube-bench container image +
    aws ecr create-repository --repository-name k8s/kube-bench --image-tag-mutability MUTABLE
+
    4. +
  4. Download, build and push the kube-bench container image to your ECR repo +
    git clone https://github.com/aquasecurity/kube-bench.git
+cd kube-bench
+aws ecr get-login-password --region <AWS_REGION> | docker login --username AWS --password-stdin <AWS_ACCT_NUMBER>.dkr.ecr.<AWS_REGION>.amazonaws.com
+docker build -t k8s/kube-bench .
+docker tag k8s/kube-bench:latest <AWS_ACCT_NUMBER>.dkr.ecr.<AWS_REGION>.amazonaws.com/k8s/kube-bench:latest
+docker push <AWS_ACCT_NUMBER>.dkr.ecr.<AWS_REGION>.amazonaws.com/k8s/kube-bench:latest
+
    5. +
  5. Copy the URI of your pushed image, the URI format is like this: <AWS_ACCT_NUMBER>.dkr.ecr.<AWS_REGION>.amazonaws.com/k8s/kube-bench:latest
    6. +
  6. Replace the image value in job-eks-stig.yaml with the URI from Step 4
    7. +
  7. Run the kube-bench job on a Pod in your Cluster: kubectl apply -f job-eks-stig.yaml
    8. +
  8. Find the Pod that was created, it should be in the default namespace: kubectl get pods --all-namespaces
    9. +
  9. Retrieve the value of this Pod and output the report, note the Pod name will vary: kubectl logs kube-bench-<value>
    10. +
  10. You can save the report for later reference: kubectl logs kube-bench-<value> > kube-bench-report.txt
    11. +
+

Running on OpenShift

+ + + + + + + + + + + + + + + + + +
OpenShift Hardening Guidekube-bench config
ocp-3.10 +rh-0.7
ocp-4.1 +rh-1.0
+

kube-bench includes a set of test files for Red Hat's OpenShift hardening guide for OCP 3.10 and 4.1. To run this you will need to specify --benchmark rh-07, or --version ocp-3.10 or,--version ocp-4.5 or --benchmark rh-1.0

+

kube-bench supports auto-detection, when you run the kube-bench command it will autodetect if running in openshift environment.

+

Since running kube-bench requires elevated privileges, the privileged SecurityContextConstraint needs to be applied to the ServiceAccount used for the Job:

+
oc create namespace kube-bench
+oc adm policy add-scc-to-user privileged --serviceaccount default
+oc apply -f job.yaml
+
+

Running in a GKE cluster

+ + + + + + + + + + + + + + + + + +
CIS BenchmarkTargets
gke-1.0master, controlplane, node, etcd, policies, managedservices
gke-1.2.0master, controlplane, node, policies, managedservices
+

kube-bench includes benchmarks for GKE. To run this you will need to specify --benchmark gke-1.0 or --benchmark gke-1.2.0 when you run the kube-bench command.

+

To run the benchmark as a job in your GKE cluster apply the included job-gke.yaml.

+
kubectl apply -f job-gke.yaml
+
+

Running in a ACK cluster

+ + + + + + + + + + + + + +
CIS BenchmarkTargets
ack-1.0master, controlplane, node, etcd, policies, managedservices
+

kube-bench includes benchmarks for Alibaba Cloud Container Service For Kubernetes (ACK). +To run this you will need to specify --benchmark ack-1.0 when you run the kube-bench command.

+

To run the benchmark as a job in your ACK cluster apply the included job-ack.yaml.

+
kubectl apply -f job-ack.yaml
+
+

Running in a VMware TKGI cluster

+ + + + + + + + + + + + + +
CIS BenchmarkTargets
tkgi-1.2.53master, etcd, controlplane, node, policies
+

kube-bench includes benchmarks for VMware tkgi platform. +To run this you will need to specify --benchmark tkgi-1.2.53 when you run the kube-bench command.

+

To run the benchmark as a job in your VMware tkgi cluster apply the included job-tkgi.yaml.

+
kubectl apply -f job-tkgi.yaml
+
+ + + + + + + +
+
+ + + +
+ +
+ +
+ +
+
+
+ + +
+ +
+
+
+ +
+
+
+
+ + + + + + + + + \ No newline at end of file diff --git a/v0.6.15/search/search_index.json b/v0.6.15/search/search_index.json new file mode 100644 index 0000000..c78900a --- /dev/null +++ b/v0.6.15/search/search_index.json @@ -0,0 +1 @@ +{"config":{"lang":["en"],"separator":"[\\s\\-]+","pipeline":["stopWordFilter"],"fields":{"title":{"boost":1000.0},"text":{"boost":1.0},"tags":{"boost":1000000.0}}},"docs":[{"location":"","title":"Overview","text":""},{"location":"#kube-bench","title":"Kube-bench","text":"

kube-bench is a Go application that checks whether Kubernetes is deployed securely by running the checks documented in the CIS Kubernetes Benchmark.

Tests are configured with YAML files, making this tool easy to update as test specifications evolve.

  1. kube-bench implements the CIS Kubernetes Benchmark as closely as possible. Please raise issues here if kube-bench is not correctly implementing the test as described in the Benchmark. To report issues in the Benchmark itself (for example, tests that you believe are inappropriate), please join the CIS community.

  2. There is not a one-to-one mapping between releases of Kubernetes and releases of the CIS benchmark. See CIS Kubernetes Benchmark support to see which releases of Kubernetes are covered by different releases of the benchmark.

  3. It is impossible to inspect the master nodes of managed clusters, e.g. GKE, EKS, AKS and ACK, using kube-bench as one does not have access to such nodes, although it is still possible to use kube-bench to check worker node configuration in these environments.

For help and more information go to our github discussions q&a

"},{"location":"architecture/","title":"Architecture","text":""},{"location":"architecture/#test-config-yaml-representation","title":"Test config YAML representation","text":"

The tests (or \"controls\") are maintained in YAML documents. There are different versions of these test YAML files reflecting different versions and platforms of the CIS Kubernetes Benchmark. You will find more information about the test file YAML definitions in our controls documentation.

"},{"location":"architecture/#kube-bench-benchmarks","title":"Kube-bench benchmarks","text":"

The test files for the various versions of Benchmarks can be found in directories with same name as the Benchmark versions under the cfg directory next to the kube-bench executable, for example ./cfg/cis-1.5 will contain all test files for CIS Kubernetes Benchmark v1.5.1 which are: master.yaml, controlplane.yaml, node.yaml, etcd.yaml, policies.yaml and config.yaml

Check the contents of the benchmark directory under cfg to see which targets are available for that benchmark. Each file except config.yaml represents a target (also known as a control in other parts of this documentation).

The following table shows the valid targets based on the CIS Benchmark version.

CIS Benchmark Targets cis-1.5 master, controlplane, node, etcd, policies cis-1.6 master, controlplane, node, etcd, policies cis-1.20 master, controlplane, node, etcd, policies cis-1.23 master, controlplane, node, etcd, policies cis-1.24 master, controlplane, node, etcd, policies cis-1.7 master, controlplane, node, etcd, policies gke-1.0 master, controlplane, node, etcd, policies, managedservices gke-1.2.0 controlplane, node, policies, managedservices eks-1.0.1 controlplane, node, policies, managedservices eks-1.1.0 controlplane, node, policies, managedservices eks-1.2.0 controlplane, node, policies, managedservices ack-1.0 master, controlplane, node, etcd, policies, managedservices aks-1.0 controlplane, node, policies, managedservices rh-0.7 master,node rh-1.0 master, controlplane, node, etcd, policies cis-1.6-k3s master, controlplane, node, etcd, policies

The following table shows the valid DISA STIG versions

STIG Targets eks-stig-kubernetes-v1r6 master, controlplane, node, policies, managedservices"},{"location":"asff/","title":"Integrating kube-bench with AWS Security Hub","text":"

You can configure kube-bench with the --asff to send findings to AWS Security Hub. There are some additional steps required so that kube-bench has information and permissions to send these findings.

"},{"location":"asff/#enable-the-aws-security-hub-integration","title":"Enable the AWS Security Hub integration","text":"
  • You will need AWS Security Hub to be enabled in your account
  • In the Security Hub console, under Integrations, search for kube-bench
  • Click on Accept findings. This gives information about the IAM permissions required to send findings to your Security Hub account. kube-bench runs within a pod on your EKS cluster, and will need to be associated with a Role that has these permissions.
"},{"location":"asff/#configure-permissions-in-an-iam-role","title":"Configure permissions in an IAM Role","text":"
  • Grant these permissions to the IAM Role that the kube-bench pod will be associated with. There are two options:
  • You can run the kube-bench pod under a specific service account associated with an IAM role that has these permissions to write Security Hub findings.
  • Alternatively the pod can be granted permissions specified by the Role that your EKS node group uses.

Here is an example IAM Policy that you can attach to your EKS node group's IAM Role: 

{\n\"Version\": \"2012-10-17\",\n\"Statement\": [\n{\n\"Effect\": \"Allow\",\n\"Action\": \"securityhub:BatchImportFindings\",\n\"Resource\": [\n\"arn:aws:securityhub:us-east-1::product/aqua-security/kube-bench\"\n]\n}\n]\n}\n
"},{"location":"asff/#modify-the-job-configuration","title":"Modify the job configuration","text":"
  • Modify the kube-bench Configmap in job-eks-asff.yaml to specify the AWS account, AWS region, and the EKS Cluster ARN.
  • In the same file, modify the image specifed in the Job to use the kube-bench image pushed to your ECR
  • [Optional] - If you have created a dedicated IAM role to be used with kube-bench as described above in Configure permissions in an IAM Role, you will need to add the IAM role arn to the kube-bench ServiceAccount in job-eks-asff.yaml.
  • Make sure that job-eks-asff.yaml specifies the container image you just pushed to your ECR registry.

You can now run kube-bench as a pod in your cluster: kubectl apply -f job-eks-asff.yaml

Findings will be generated for any kube-bench test that generates a [FAIL] or [WARN] output. If all tests pass, no findings will be generated. However, it's recommended that you consult the pod log output to check whether any findings were generated but could not be written to Security Hub.

"},{"location":"controls/","title":"Test and config files","text":"

kube-bench runs checks specified in controls files that are a YAML representation of the CIS Kubernetes Benchmark checks (or other distribution-specific hardening guides).

"},{"location":"controls/#controls","title":"Controls","text":"

controls is a YAML document that contains checks that must be run against a specific Kubernetes node type, master or node and version.

controls is the fundamental input to kube-bench. The following is an example of a basic controls:

---\ncontrols:\nid: 1\ntext: \"Master Node Security Configuration\"\ntype: \"master\"\ngroups:\n- id: 1.1\n  text: API Server\n  checks:\n    - id: 1.1.1\n      text: \"Ensure that the --allow-privileged argument is set (Scored)\"\n      audit: \"ps -ef | grep kube-apiserver | grep -v grep\"\n      tests:\n      bin_op: or\n      test_items:\n      - flag: \"--allow-privileged\"\n        set: true\n      - flag: \"--some-other-flag\"\n        set: false\n      remediation: \"Edit the /etc/kubernetes/config file on the master node and\n        set the KUBE_ALLOW_PRIV parameter to '--allow-privileged=false'\"\n      scored: true\n- id: 1.2\n  text: Scheduler\n  checks:\n    - id: 1.2.1\n      text: \"Ensure that the --profiling argument is set to false (Scored)\"\n      audit: \"ps -ef | grep kube-scheduler | grep -v grep\"\n      tests:\n        bin_op: and\n        test_items:\n          - flag: \"--profiling\"\n            set: true\n          - flag: \"--some-other-flag\"\n            set: false\n      remediation: \"Edit the /etc/kubernetes/config file on the master node and\n        set the KUBE_ALLOW_PRIV parameter to '--allow-privileged=false'\"\n      scored: true\n

controls is composed of a hierarchy of groups, sub-groups and checks. Each of the controls components have an id and a text description which are displayed in the kube-bench output.

type specifies what kubernetes node type a controls is for. Possible values for type are master and node.

"},{"location":"controls/#groups","title":"Groups","text":"

groups is a list of subgroups that test the various Kubernetes components that run on the node type specified in the controls.

For example, one subgroup checks parameters passed to the API server binary, while another subgroup checks parameters passed to the controller-manager binary.

groups:\n- id: 1.1\n  text: API Server\n  # ...\n- id: 1.2\n  text: Scheduler\n  # ...\n

These subgroups have id, text fields which serve the same purposes described in the previous paragraphs. The most important part of the subgroup is the checks field which is the collection of actual checks that form the subgroup.

This is an example of a subgroup and checks in the subgroup.

id: 1.1\ntext: API Server\nchecks:\n  - id: 1.1.1\n    text: \"Ensure that the --allow-privileged argument is set (Scored)\"\n    audit: \"ps -ef | grep kube-apiserver | grep -v grep\"\n    tests:\n    # ...\n  - id: 1.1.2\n    text: \"Ensure that the --anonymous-auth argument is set to false (Not Scored)\"\n    audit: \"ps -ef | grep kube-apiserver | grep -v grep\"\n    tests:\n    # ...\n

kube-bench supports running a subgroup by specifying the subgroup id on the command line, with the flag --group or -g.

"},{"location":"controls/#check","title":"Check","text":"

The CIS Kubernetes Benchmark recommends configurations to harden Kubernetes components. These recommendations are usually configuration options and can be specified by flags to Kubernetes binaries, or in configuration files.

The Benchmark also provides commands to audit a Kubernetes installation, identify places where the cluster security can be improved, and steps to remediate these identified problems.

In kube-bench, check objects embody these recommendations. This an example check object:

id: 1.1.1\ntext: \"Ensure that the --anonymous-auth argument is set to false (Not Scored)\"\naudit: \"ps -ef | grep kube-apiserver | grep -v grep\"\ntests:\n  test_items:\n  - flag: \"--anonymous-auth\"\n    compare:\n      op: eq\n      value: false\n    set: true\nremediation: |\n  Edit the API server pod specification file kube-apiserver\n  on the master node and set the below parameter.\n  --anonymous-auth=false\nscored: false\n

A check object has an id, a text, an audit, a tests, remediation and scored fields.

kube-bench supports running individual checks by specifying the check's id as a comma-delimited list on the command line with the --check flag.

The audit field specifies the command to run for a check. The output of this command is then evaluated for conformance with the CIS Kubernetes Benchmark recommendation.

The audit is evaluated against criteria specified by the tests object. tests contain bin_op and test_items.

test_items specify the criteria(s) the audit command's output should meet to pass a check. This criteria is made up of keywords extracted from the output of the audit command and operations that compare these keywords against values expected by the CIS Kubernetes Benchmark.

There are three ways to run and extract keywords from the output of the command used, | Command | Output var | |---|---| | audit | flag | | audit_config | path | | audit_env | env |

flag is used when the keyword is a command-line flag. The associated audit command could be any binaries available on the system like ps command and a grep for the binary whose flag we are checking:

ps -ef | grep somebinary | grep -v grep\n

Here is an example usage of the flag option:

# ...\naudit: \"ps -ef | grep kube-apiserver | grep -v grep\"\ntests:\n  test_items:\n  - flag: \"--anonymous-auth\"\n  # ...\n

path is used when the keyword is an option set in a JSON or YAML config file. The associated audit_command command is usually cat /path/to/config-yaml-or-json. For example:

# ...\ntext: \"Ensure that the --anonymous-auth argument is set to false (Not Scored)\"\naudit: \"cat /path/to/some/config\"\ntests:\n  test_items:\n  - path: \"{.someoption.value}\"\n    # ...\n

env is used to check if the value is present within a specified environment variable. The presence of env is treated as an OR operation, if both flag and env are supplied it will use either to attempt pass the check. The command used for checking the environment variables of a process is generated by default.

If the command being generated is causing errors, you can override the command used by setting audit_env on the check. Similarly, if you don't want the environment checking command to be generated or run at all, specify disableEnvTesting as true on the check.

The example below will check if the flag --auto-tls is equal to false OR ETCD_AUTO_TLS is equal to false

  test_items:\n  - flag: \"--auto-tls\"\n    env: \"ETCD_AUTO_TLS\"\n    compare:\n      op: eq\n      value: false\n
Note: flag, path and env will act as OR if more then one present.

test_item compares the output of the audit command and keywords using the set and compare fields.

  test_items:\n  - flag: \"--anonymous-auth\"\n    compare:\n      op: eq\n      value: false\n    set: true\n

set checks if a keyword is present in the output of the audit command or a config file. The possible values for set are true and false.

If set is true, the check passes only if the keyword is present in the output of the audit command, or config file. If set is false, the check passes only if the keyword is not present in the output of the audit command, or config file. set is true by default.

compare has two fields op and value to compare keywords with expected value. op specifies which operation is used for the comparison, and value specifies the value to compare against.

To use compare, set must true. The comparison will be ignored if set is false

The op (operations) currently supported in kube-bench are: - eq: tests if the keyword is equal to the compared value. - noteq: tests if the keyword is unequal to the compared value. - gt: tests if the keyword is greater than the compared value. - gte: tests if the keyword is greater than or equal to the compared value. - lt: tests if the keyword is less than the compared value. - lte: tests if the keyword is less than or equal to the compared value. - has: tests if the keyword contains the compared value. - nothave: tests if the keyword does not contain the compared value. - regex: tests if the flag value matches the compared value regular expression. When defining regular expressions in YAML it is generally easier to wrap them in single quotes, for example '^[abc]$', to avoid issues with string escaping. - bitmask : tests if keyward is bitmasked with the compared value, common usege is for comparing file permissions in linux.

"},{"location":"controls/#omitting-checks","title":"Omitting checks","text":"

If you decide that a recommendation is not appropriate for your environment, you can choose to omit it by editing the test YAML file to give it the check type skip as in this example:

  checks:\n- id: 2.1.1\ntext: \"Ensure that the --allow-privileged argument is set to false (Scored)\"\ntype: \"skip\"\nscored: true\n

No tests will be run for this check and the output will be marked [INFO].

"},{"location":"controls/#configuration-and-variables","title":"Configuration and Variables","text":"

Kubernetes component configuration and binary file locations and names vary based on cluster deployment methods and Kubernetes distribution used. For this reason, the locations of these binaries and config files are configurable by editing the cfg/config.yaml file and these binaries and files can be referenced in a controls file via variables.

The cfg/config.yaml file is a global configuration file. Configuration files can be created for specific Kubernetes versions (distributions). Values in the version-specific config overwrite similar values in cfg/config.yaml.

For example, the kube-apiserver in Red Hat OCP distribution is run as hypershift openshift-kube-apiserver instead of the default kube-apiserver. This difference can be specified by editing the master.apiserver.defaultbin entry cfg/rh-0.7/config.yaml.

Below is the structure of cfg/config.yaml:

nodetype\n  |-- components\n    |-- component1\n  |-- component1\n    |-- bins\n    |-- defaultbin (optional)\n    |-- confs\n    |-- defaultconf (optional)\n    |-- svcs\n    |-- defaultsvc (optional)\n    |-- kubeconfig\n    |-- defaultkubeconfig (optional)\n

Every node type has a subsection that specifies the main configuration items.

  • components: A list of components for the node type. For example master will have an entry for apiserver, scheduler and controllermanager.

Each component has the following entries:

  • bins: A list of candidate binaries for a component. kube-bench checks this list and selects the first binary that is running on the node.

If none of the binaries in bins list is running, kube-bench checks if the binary specified by defaultbin is running and terminates if none of the binaries in both bins and defaultbin is running.

The selected binary for a component can be referenced in controls using a variable in the form $<component>bin. In the example below, we reference the selected API server binary with the variable $apiserverbin in an audit command.

id: 1.1.1\n text: \"Ensure that the --anonymous-auth argument is set to false (Scored)\"\n audit: \"ps -ef | grep $apiserverbin | grep -v grep\"\n # ...\n
  • confs: A list of candidate configuration files for a component. kube-bench checks this list and selects the first config file that is found on the node. If none of the config files exists, kube-bench defaults conf to the value of defaultconf.

The selected config for a component can be referenced in controls using a variable in the form $<component>conf. In the example below, we reference the selected API server config file with the variable $apiserverconf in an audit command.

id: 1.4.1\n  text: \"Ensure that the API server pod specification file permissions are\n  set to 644 or more restrictive (Scored)\"\n  audit: \"/bin/sh -c 'if test -e $apiserverconf; then stat -c %a $apiserverconf; fi'\"\n
  • svcs: A list of candidate unitfiles for a component. kube-bench checks this list and selects the first unitfile that is found on the node. If none of the unitfiles exists, kube-bench defaults unitfile to the value of defaultsvc.

The selected unitfile for a component can be referenced in controls via a variable in the form $<component>svc. In the example below, the selected kubelet unitfile is referenced with $kubeletsvc in the remediation of the check.

id: 2.1.1\n  # ...\n  remediation: |\n    Edit the kubelet service file $kubeletsvc\n    on each worker node and set the below parameter in KUBELET_SYSTEM_PODS_ARGS variable.\n    --allow-privileged=false\n    Based on your system, restart the kubelet service. For example:\n    systemctl daemon-reload\n    systemctl restart kubelet.service\n  # ...\n

  • kubeconfig: A list of candidate kubeconfig files for a component. kube-bench checks this list and selects the first file that is found on the node. If none of the files exists, kube-bench defaults kubeconfig to the value of defaultkubeconfig.

    The selected kubeconfig for a component can be referenced in controls with a variable in the form $<component>kubeconfig. In the example below, the selected kubelet kubeconfig is referenced with $kubeletkubeconfig in the audit command.

    id: 2.2.1\n  text: \"Ensure that the kubelet.conf file permissions are set to 644 or\n  more restrictive (Scored)\"\n  audit: \"/bin/sh -c 'if test -e $kubeletkubeconfig; then stat -c %a $kubeletkubeconfig; fi'\"\n  # ...\n
"},{"location":"flags-and-commands/","title":"Flags","text":""},{"location":"flags-and-commands/#commands","title":"Commands","text":"Command Description help Prints help about any command run List of components to run version Print kube-bench version"},{"location":"flags-and-commands/#flags","title":"Flags","text":"Flag Description --alsologtostderr log to standard error as well as files --asff Send findings to AWS Security Hub for any benchmark tests that fail or that generate a warning. See [this page][kube-bench-aws-security-hub] for more information on how to enable the kube-bench integration with AWS Security Hub. --benchmark Manually specify CIS benchmark version -c, --check A comma-delimited list of checks to run as specified in Benchmark document. --config config file (default is ./cfg/config.yaml) --exit-code Specify the exit code for when checks fail --group Run all the checks under this comma-delimited list of groups. --include-test-output Prints the actual result when test fails. --json Prints the results as JSON --junit Prints the results as JUnit --log_backtrace_at traceLocation when logging hits line file:N, emit a stack trace (default :0) --logtostderr log to standard error instead of files --noremediations Disable printing of remediations section to stdout. --noresults Disable printing of results section to stdout. --nototals Disable calculating and printing of totals for failed, passed, ... checks across all sections --outputfile Writes the results to output file when run with --json or --junit --pgsql Save the results to PostgreSQL --scored Run the scored CIS checks (default true) --skip string List of comma separated values of checks to be skipped --stderrthreshold severity logs at or above this threshold go to stderr (default 2) -v, --v Level log level for V logs (default 0) --unscored Run the unscored CIS checks (default true) --version string Manually specify Kubernetes version, automatically detected if unset --vmodule moduleSpec comma-separated list of pattern=N settings for file-filtered logging"},{"location":"flags-and-commands/#examples","title":"Examples","text":""},{"location":"flags-and-commands/#report-kube-bench-findings-to-aws-security-hub","title":"Report kube-bench findings to AWS Security Hub","text":"

You can configure kube-bench with the --asff option to send findings to AWS Security Hub for any benchmark tests that fail or that generate a warning. See this page for more information on how to enable the kube-bench integration with AWS Security Hub.

"},{"location":"flags-and-commands/#specifying-the-benchmark-or-kubernetes-version","title":"Specifying the benchmark or Kubernetes version","text":"

kube-bench uses the Kubernetes API, or access to the kubectl or kubelet executables to try to determine the Kubernetes version, and hence which benchmark to run. If you wish to override this, or if none of these methods are available, you can specify either the Kubernetes version or CIS Benchmark as a command line parameter.

You can specify a particular version of Kubernetes by setting the --version flag or with the KUBE_BENCH_VERSION environment variable. The value of --version takes precedence over the value of KUBE_BENCH_VERSION.

For example, run kube-bench using the tests for Kubernetes version 1.13:

kube-bench --version 1.13\n

You can specify --benchmark to run a specific CIS Benchmark version:

kube-bench --benchmark cis-1.5\n

Note: It is an error to specify both --version and --benchmark flags together

"},{"location":"flags-and-commands/#specifying-benchmark-sections","title":"Specifying Benchmark sections","text":"

If you want to run specific CIS Benchmark sections (i.e master, node, etcd, etc...) you can use the run --targets subcommand.

kube-bench run --targets master,node\n

or

kube-bench run --targets master,node,etcd,policies\n

If no targets are specified, kube-bench will determine the appropriate targets based on the CIS Benchmark version and the components detected on the node. The detection is done by verifying which components are running, as defined in the config files (see Configuration.

"},{"location":"flags-and-commands/#run-specific-check-or-group","title":"Run specific check or group","text":"

kube-bench supports running individual checks by specifying the check's id as a comma-delimited list on the command line with the --check | -c flag. kube-bench --check=\"1.1.1,1.1.2,1.2.1,1.3.3\"

kube-bench supports running all checks under group by specifying the group's id as a comma-delimited list on the command line with the --group | -g flag. kube-bench --check=\"1.1,2.2\" Will run all checks 1.1.X and 2.2.X.

"},{"location":"flags-and-commands/#skip-specific-check-or-group","title":"Skip specific check or group","text":"

kube-bench supports skipping checks or groups by specifying the id as a comma-delimited list on the command line with the --skip flag. kube-bench --skip=\"1.1,1.2.1,1.3.3\" Will skip 1.1.X group and individual checks 1.2.1, 1.3.3. Skipped checks returns [INFO] output.

"},{"location":"flags-and-commands/#exit-code","title":"Exit code","text":"

kube-bench supports using uniqe exit code when failing a check or more. kube-bench --exit-code 42 Will return 42 if one check or more failed, and 0 incase none failed. Note: [WARN] is not [FAIL].

"},{"location":"flags-and-commands/#output-manipulation-flags","title":"Output manipulation flags","text":"

There are four output states: - [PASS] indicates that the test was run successfully, and passed. - [FAIL] indicates that the test was run successfully, and failed. The remediation output describes how to correct the configuration, or includes an error message describing why the test could not be run. - [WARN] means this test needs further attention, for example it is a test that needs to be run manually. Check the remediation output for further information. - [INFO] is informational output that needs no further action.

Note: - Some tests with Automated in their description must still be run manually - If the user has to run a test manually, this always generates WARN - If the test is Scored, and kube-bench was unable to run the test, this generates FAIL (because the test has not been passed, and as a Scored test, if it doesn't pass then it must be considered a failure). - If the test is Not Scored, and kube-bench was unable to run the test, this generates WARN. - If the test is Scored, type is empty, and there are no test_items present, it generates a WARN. This is to highlight tests that appear to be incompletely defined.

kube-bench supports multiple output manipulation flags. kube-bench --include-test-output will print failing checks output in the results section 

[INFO] 1 Master Node Security Configuration\n[INFO] 1.1 Master Node Configuration Files\n[FAIL] 1.1.1 Ensure that the API server pod specification file permissions are set to 644 or more restrictive (Automated)\n         **permissions=777**\n

Note: --noresults --noremediations and --include-test-output will not effect the json output but only stdout. Only --nototals will effect the json output and thats because it will not call the function to calculate totals.

"},{"location":"flags-and-commands/#troubleshooting","title":"Troubleshooting","text":"

Running kube-bench with the -v 3 parameter will generate debug logs that can be very helpful for debugging problems.

If you are using one of the example job*.yaml files, you will need to edit the command field, for example [\"kube-bench\", \"-v\", \"3\"]. Once the job has run, the logs can be retrieved using kubectl logs on the job's pod.

"},{"location":"installation/","title":"Installation","text":""},{"location":"installation/#installation","title":"Installation","text":"

You can choose to * Run kube-bench from inside a container (sharing PID namespace with the host). See Running inside a container for additional details. * Run a container that installs kube-bench on the host, and then run kube-bench directly on the host. See Installing from a container for additional details. * install the latest binaries from the Releases page, though please note that you also need to download the config and test files from the cfg directory. See Download and Install binaries for details. * Compile it from source. See Installing from sources for details.

"},{"location":"installation/#download-and-install-binaries","title":"Download and Install binaries","text":"

It is possible to manually install and run kube-bench release binaries. In order to do that, you must have access to your Kubernetes cluster nodes. Note that if you're using one of the managed Kubernetes services (e.g. EKS, AKS, GKE, ACK, OCP), you will not have access to the master nodes of your cluster and you can\u2019t perform any tests on the master nodes.

First, log into one of the nodes using SSH.

Install kube-bench binary for your platform using the commands below. Note that there may be newer releases available. See releases page.

Ubuntu/Debian:

curl -L https://github.com/aquasecurity/kube-bench/releases/download/v0.6.2/kube-bench_0.6.2_linux_amd64.deb -o kube-bench_0.6.2_linux_amd64.deb\n\nsudo apt install ./kube-bench_0.6.2_linux_amd64.deb -f\n

RHEL:

curl -L https://github.com/aquasecurity/kube-bench/releases/download/v0.6.2/kube-bench_0.6.2_linux_amd64.rpm -o kube-bench_0.6.2_linux_amd64.rpm\n\nsudo yum install kube-bench_0.6.2_linux_amd64.rpm -y\n

Alternatively, you can manually download and extract the kube-bench binary:

curl -L https://github.com/aquasecurity/kube-bench/releases/download/v0.6.2/kube-bench_0.6.2_linux_amd64.tar.gz -o kube-bench_0.6.2_linux_amd64.tar.gz\n\ntar -xvf kube-bench_0.6.2_linux_amd64.tar.gz\n

You can then run kube-bench directly: 

kube-bench\n

If you manually downloaded the kube-bench binary (using curl command above), you have to specify the location of configuration directory and file. For example: 

./kube-bench --config-dir `pwd`/cfg --config `pwd`/cfg/config.yaml \n

See previous section on Running kube-bench for further details on using the kube-bench binary.

"},{"location":"installation/#installing-from-sources","title":"Installing from sources","text":"

If Go is installed on the target machines, you can simply clone this repository and run as follows (assuming your GOPATH is set) as per this example:

# Create a target directory for the clone, inside the $GOPATH\nmkdir -p $GOPATH/src/github.com/aquasecurity/kube-bench\n\n#\u00a0Clone this repository, using SSH\ngit clone git@github.com:aquasecurity/kube-bench.git $GOPATH/src/github.com/aquasecurity/kube-bench\n\n#\u00a0Install the pre-requisites\ngo get github.com/aquasecurity/kube-bench\n\n#\u00a0Change to the kube-bench directory\ncd $GOPATH/src/github.com/aquasecurity/kube-bench\n\n#\u00a0Build the kube-bench binary\ngo build -o kube-bench .\n\n# See all supported options\n./kube-bench --help\n\n# Run all checks\n./kube-bench\n
"},{"location":"installation/#installing-from-a-container","title":"Installing from a container","text":"

This command copies the kube-bench binary and configuration files to your host from the Docker container: binaries compiled for linux-x86-64 only (so they won't run on macOS or Windows) 

docker run --rm -v `pwd`:/host docker.io/aquasec/kube-bench:latest install\n

You can then run ./kube-bench.

"},{"location":"platforms/","title":"Platforms","text":""},{"location":"platforms/#cis-kubernetes-benchmark-support","title":"CIS Kubernetes Benchmark support","text":"

kube-bench supports running tests for Kubernetes. Most of our supported benchmarks are defined in one of the following: CIS Kubernetes Benchmarks STIG Document Library

Some defined by other hardenening guides.

Source Kubernetes Benchmark kube-bench config Kubernetes versions CIS 1.5.1 cis-1.5 1.15 CIS 1.6.0 cis-1.6 1.16-1.18 CIS 1.20 cis-1.20 1.19-1.21 CIS 1.23 cis-1.23 1.22-1.23 CIS 1.24 cis-1.24 1.24 CIS 1.7 cis-1.7 1.25 CIS GKE 1.0.0 gke-1.0 GKE CIS GKE 1.2.0 gke-1.2.0 GKE CIS EKS 1.0.1 eks-1.0.1 EKS CIS EKS 1.1.0 eks-1.1.0 EKS CIS EKS 1.2.0 eks-1.2.0 EKS CIS ACK 1.0.0 ack-1.0 ACK CIS AKS 1.0.0 aks-1.0 AKS RHEL RedHat OpenShift hardening guide rh-0.7 OCP 3.10-3.11 CIS OCP4 1.1.0 rh-1.0 OCP 4.1- CIS 1.6.0-k3s cis-1.6-k3s k3s v1.16-v1.24 DISA Kubernetes Ver 1, Rel 6 eks-stig-kubernetes-v1r6 EKS CIS TKGI 1.2.53 tkgi-1.2.53 vmware"},{"location":"running/","title":"How to run","text":""},{"location":"running/#running-kube-bench","title":"Running kube-bench","text":"

If you run kube-bench directly from the command line you may need to be root / sudo to have access to all the config files.

By default kube-bench attempts to auto-detect the running version of Kubernetes, and map this to the corresponding CIS Benchmark version. For example, Kubernetes version 1.15 is mapped to CIS Benchmark version cis-1.15 which is the benchmark version valid for Kubernetes 1.15.

kube-bench also attempts to identify the components running on the node, and uses this to determine which tests to run (for example, only running the master node tests if the node is running an API server).

Please note It is impossible to inspect the master nodes of managed clusters, e.g. GKE, EKS, AKS and ACK, using kube-bench as one does not have access to such nodes, although it is still possible to use kube-bench to check worker node configuration in these environments.

"},{"location":"running/#running-inside-a-container","title":"Running inside a container","text":"

You can avoid installing kube-bench on the host by running it inside a container using the host PID namespace and mounting the /etc and /var directories where the configuration and other files are located on the host so that kube-bench can check their existence and permissions.

docker run --pid=host -v /etc:/etc:ro -v /var:/var:ro -t docker.io/aquasec/kube-bench:latest --version 1.18\n

Note: the tests require either the kubelet or kubectl binary in the path in order to auto-detect the Kubernetes version. You can pass -v $(which kubectl):/usr/local/mount-from-host/bin/kubectl to resolve this. You will also need to pass in kubeconfig credentials. For example:

docker run --pid=host -v /etc:/etc:ro -v /var:/var:ro -v $(which kubectl):/usr/local/mount-from-host/bin/kubectl -v ~/.kube:/.kube -e KUBECONFIG=/.kube/config -t docker.io/aquasec/kube-bench:latest \n

You can use your own configs by mounting them over the default ones in /opt/kube-bench/cfg/

docker run --pid=host -v /etc:/etc:ro -v /var:/var:ro -t -v path/to/my-config.yaml:/opt/kube-bench/cfg/config.yaml -v $(which kubectl):/usr/local/mount-from-host/bin/kubectl -v ~/.kube:/.kube -e KUBECONFIG=/.kube/config docker.io/aquasec/kube-bench:latest\n
"},{"location":"running/#running-in-a-kubernetes-cluster","title":"Running in a Kubernetes cluster","text":"

You can run kube-bench inside a pod, but it will need access to the host's PID namespace in order to check the running processes, as well as access to some directories on the host where config files and other files are stored.

The job.yaml file (available in the root directory of the repository) can be applied to run the tests as a Kubernetes Job. For example:

$ kubectl apply -f job.yaml\njob.batch/kube-bench created\n\n$ kubectl get pods\nNAME                      READY   STATUS              RESTARTS   AGE\nkube-bench-j76s9   0/1     ContainerCreating   0          3s\n\n# Wait for a few seconds for the job to complete\n$ kubectl get pods\nNAME                      READY   STATUS      RESTARTS   AGE\nkube-bench-j76s9   0/1     Completed   0          11s\n\n# The results are held in the pod's logs\nkubectl logs kube-bench-j76s9\n[INFO] 1 Master Node Security Configuration\n[INFO] 1.1 API Server\n...\n

To run tests on the master node, the pod needs to be scheduled on that node. This involves setting a nodeSelector and tolerations in the pod spec.

The default labels applied to master nodes has changed since Kubernetes 1.11, so if you are using an older version you may need to modify the nodeSelector and tolerations to run the job on the master node.

"},{"location":"running/#running-in-an-aks-cluster","title":"Running in an AKS cluster","text":"

  1. Create an AKS cluster(e.g. 1.13.7) with RBAC enabled, otherwise there would be 4 failures

  2. Use the kubectl-enter plugin to shell into a node kubectl-enter {node-name} or ssh to one agent node could open nsg 22 port and assign a public ip for one agent node (only for testing purpose)

  3. Run CIS benchmark to view results: 

    docker run --rm -v `pwd`:/host docker.io/aquasec/kube-bench:latest install\n./kube-bench \n
    kube-bench cannot be run on AKS master nodes

"},{"location":"running/#running-cis-benchmark-in-an-eks-cluster","title":"Running CIS benchmark in an EKS cluster","text":"

There is a job-eks.yaml file for running the kube-bench node checks on an EKS cluster. The significant difference on EKS is that it's not possible to schedule jobs onto the master node, so master checks can't be performed

  1. To create an EKS Cluster refer to Getting Started with Amazon EKS in the Amazon EKS User Guide
  2. Information on configuring eksctl, kubectl and the AWS CLI is within
  3. Create an Amazon Elastic Container Registry (ECR) repository to host the kube-bench container image 
    aws ecr create-repository --repository-name k8s/kube-bench --image-tag-mutability MUTABLE\n
  4. Download, build and push the kube-bench container image to your ECR repo 
    git clone https://github.com/aquasecurity/kube-bench.git\ncd kube-bench\naws ecr get-login-password --region <AWS_REGION> | docker login --username AWS --password-stdin <AWS_ACCT_NUMBER>.dkr.ecr.<AWS_REGION>.amazonaws.com\ndocker build -t k8s/kube-bench .\ndocker tag k8s/kube-bench:latest <AWS_ACCT_NUMBER>.dkr.ecr.<AWS_REGION>.amazonaws.com/k8s/kube-bench:latest\ndocker push <AWS_ACCT_NUMBER>.dkr.ecr.<AWS_REGION>.amazonaws.com/k8s/kube-bench:latest\n
  5. Copy the URI of your pushed image, the URI format is like this: <AWS_ACCT_NUMBER>.dkr.ecr.<AWS_REGION>.amazonaws.com/k8s/kube-bench:latest
  6. Replace the image value in job-eks.yaml with the URI from Step 4
  7. Run the kube-bench job on a Pod in your Cluster: kubectl apply -f job-eks.yaml
  8. Find the Pod that was created, it should be in the default namespace: kubectl get pods --all-namespaces
  9. Retrieve the value of this Pod and output the report, note the Pod name will vary: kubectl logs kube-bench-<value>
  10. You can save the report for later reference: kubectl logs kube-bench-<value> > kube-bench-report.txt
"},{"location":"running/#running-disa-stig-in-an-eks-cluster","title":"Running DISA STIG in an EKS cluster","text":"

There is a job-eks-stig.yaml file for running the kube-bench node checks on an EKS cluster. The significant difference on EKS is that it's not possible to schedule jobs onto the master node, so master checks can't be performed

  1. To create an EKS Cluster refer to Getting Started with Amazon EKS in the Amazon EKS User Guide
  2. Information on configuring eksctl, kubectl and the AWS CLI is within
  3. Create an Amazon Elastic Container Registry (ECR) repository to host the kube-bench container image 
    aws ecr create-repository --repository-name k8s/kube-bench --image-tag-mutability MUTABLE\n
  4. Download, build and push the kube-bench container image to your ECR repo 
    git clone https://github.com/aquasecurity/kube-bench.git\ncd kube-bench\naws ecr get-login-password --region <AWS_REGION> | docker login --username AWS --password-stdin <AWS_ACCT_NUMBER>.dkr.ecr.<AWS_REGION>.amazonaws.com\ndocker build -t k8s/kube-bench .\ndocker tag k8s/kube-bench:latest <AWS_ACCT_NUMBER>.dkr.ecr.<AWS_REGION>.amazonaws.com/k8s/kube-bench:latest\ndocker push <AWS_ACCT_NUMBER>.dkr.ecr.<AWS_REGION>.amazonaws.com/k8s/kube-bench:latest\n
  5. Copy the URI of your pushed image, the URI format is like this: <AWS_ACCT_NUMBER>.dkr.ecr.<AWS_REGION>.amazonaws.com/k8s/kube-bench:latest
  6. Replace the image value in job-eks-stig.yaml with the URI from Step 4
  7. Run the kube-bench job on a Pod in your Cluster: kubectl apply -f job-eks-stig.yaml
  8. Find the Pod that was created, it should be in the default namespace: kubectl get pods --all-namespaces
  9. Retrieve the value of this Pod and output the report, note the Pod name will vary: kubectl logs kube-bench-<value>
  10. You can save the report for later reference: kubectl logs kube-bench-<value> > kube-bench-report.txt
"},{"location":"running/#running-on-openshift","title":"Running on OpenShift","text":"OpenShift Hardening Guide kube-bench config ocp-3.10 + rh-0.7 ocp-4.1 + rh-1.0

kube-bench includes a set of test files for Red Hat's OpenShift hardening guide for OCP 3.10 and 4.1. To run this you will need to specify --benchmark rh-07, or --version ocp-3.10 or,--version ocp-4.5 or --benchmark rh-1.0

kube-bench supports auto-detection, when you run the kube-bench command it will autodetect if running in openshift environment.

Since running kube-bench requires elevated privileges, the privileged SecurityContextConstraint needs to be applied to the ServiceAccount used for the Job:

oc create namespace kube-bench\noc adm policy add-scc-to-user privileged --serviceaccount default\noc apply -f job.yaml\n
"},{"location":"running/#running-in-a-gke-cluster","title":"Running in a GKE cluster","text":"CIS Benchmark Targets gke-1.0 master, controlplane, node, etcd, policies, managedservices gke-1.2.0 master, controlplane, node, policies, managedservices

kube-bench includes benchmarks for GKE. To run this you will need to specify --benchmark gke-1.0 or --benchmark gke-1.2.0 when you run the kube-bench command.

To run the benchmark as a job in your GKE cluster apply the included job-gke.yaml.

kubectl apply -f job-gke.yaml\n
"},{"location":"running/#running-in-a-ack-cluster","title":"Running in a ACK cluster","text":"CIS Benchmark Targets ack-1.0 master, controlplane, node, etcd, policies, managedservices

kube-bench includes benchmarks for Alibaba Cloud Container Service For Kubernetes (ACK). To run this you will need to specify --benchmark ack-1.0 when you run the kube-bench command.

To run the benchmark as a job in your ACK cluster apply the included job-ack.yaml.

kubectl apply -f job-ack.yaml\n
"},{"location":"running/#running-in-a-vmware-tkgi-cluster","title":"Running in a VMware TKGI cluster","text":"CIS Benchmark Targets tkgi-1.2.53 master, etcd, controlplane, node, policies

kube-bench includes benchmarks for VMware tkgi platform. To run this you will need to specify --benchmark tkgi-1.2.53 when you run the kube-bench command.

To run the benchmark as a job in your VMware tkgi cluster apply the included job-tkgi.yaml.

kubectl apply -f job-tkgi.yaml\n
"}]} \ No newline at end of file diff --git a/v0.6.15/sitemap.xml b/v0.6.15/sitemap.xml new file mode 100644 index 0000000..6b80e78 --- /dev/null +++ b/v0.6.15/sitemap.xml @@ -0,0 +1,43 @@ + + + + https://aquasecurity.github.io/kube-bench/v0.6.15/ + 2023-06-06 + daily + + + https://aquasecurity.github.io/kube-bench/v0.6.15/architecture/ + 2023-06-06 + daily + + + https://aquasecurity.github.io/kube-bench/v0.6.15/asff/ + 2023-06-06 + daily + + + https://aquasecurity.github.io/kube-bench/v0.6.15/controls/ + 2023-06-06 + daily + + + https://aquasecurity.github.io/kube-bench/v0.6.15/flags-and-commands/ + 2023-06-06 + daily + + + https://aquasecurity.github.io/kube-bench/v0.6.15/installation/ + 2023-06-06 + daily + + + https://aquasecurity.github.io/kube-bench/v0.6.15/platforms/ + 2023-06-06 + daily + + + https://aquasecurity.github.io/kube-bench/v0.6.15/running/ + 2023-06-06 + daily + + \ No newline at end of file diff --git a/v0.6.15/sitemap.xml.gz b/v0.6.15/sitemap.xml.gz new file mode 100644 index 0000000..161ad13 Binary files /dev/null and b/v0.6.15/sitemap.xml.gz differ diff --git a/versions.json b/versions.json index 7d92897..1400d5f 100644 --- a/versions.json +++ b/versions.json @@ -1 +1 @@ -[{"version": "v0.6.12", "title": "v0.6.12", "aliases": ["latest"]}, {"version": "v0.6.11", "title": "v0.6.11", "aliases": []}, {"version": "v0.6.8", "title": "v0.6.8", "aliases": []}, {"version": "v0.6.7", "title": "v0.6.7", "aliases": []}, {"version": "v0.6.6", "title": "v0.6.6", "aliases": []}, {"version": "v0.6.5", "title": "v0.6.5", "aliases": []}, {"version": "v0.6.3", "title": "v0.6.3", "aliases": []}, {"version": "dev", "title": "dev", "aliases": []}] \ No newline at end of file +[{"version": "v0.6.15", "title": "v0.6.15", "aliases": ["latest"]}, {"version": "v0.6.12", "title": "v0.6.12", "aliases": []}, {"version": "v0.6.11", "title": "v0.6.11", "aliases": []}, {"version": "v0.6.8", "title": "v0.6.8", "aliases": []}, {"version": "v0.6.7", "title": "v0.6.7", "aliases": []}, {"version": "v0.6.6", "title": "v0.6.6", "aliases": []}, {"version": "v0.6.5", "title": "v0.6.5", "aliases": []}, {"version": "v0.6.3", "title": "v0.6.3", "aliases": []}, {"version": "dev", "title": "dev", "aliases": []}] \ No newline at end of file