kubeaudit
is a command line software and a Go package deal to audit Kubernetes clusters for numerous totally different safety considerations, comparable to:
- run as non-root
- use a read-only root filesystem
- drop scary capabilities, do not add new ones
- do not run privileged
- and extra!
tldr. kubeaudit
makes positive you deploy safe containers!
Package deal
To make use of kubeaudit as a Go package deal, see the package deal docs.
The remainder of this README will give attention to how you can use kubeaudit as a command line software.
Command Line Interface (CLI)
Set up
Brew
Obtain a binary
Kubeaudit has official releases which might be blessed and steady: Official releases
DIY construct
Grasp might have newer options than the steady releases. When you want a more recent characteristic not but included in a launch, be sure you’re utilizing Go 1.17+ and run the next:
go get -v github.com/Shopify/kubeaudit
Begin utilizing kubeaudit
with the Fast Begin or view all of the supported instructions.
Kubectl Plugin
Prerequisite: kubectl v1.12.0 or later
With kubectl v1.12.0 introducing simple pluggability of exterior features, kubeaudit will be invoked as kubectl audit
by
- working
make plugin
and having$GOPATH/bin
accessible in your path.
or
- renaming the binary to
kubectl-audit
and having it accessible in your path.
Docker
We additionally launch a Docker picture: shopify/kubeaudit
. To run kubeaudit as a job in your cluster see Operating kubeaudit in a cluster.
Fast Begin
kubeaudit has three modes:
- Manifest mode
- Native mode
- Cluster mode
Manifest Mode
If a Kubernetes manifest file is supplied utilizing the -f/--manifest
flag, kubeaudit will audit the manifest file.
Instance command:
kubeaudit all -f "/path/to/manifest.yml"
Instance output:
$ kubeaudit all -f "inside/take a look at/fixtures/all_resources/deployment-apps-v1.yml"---------------- Outcomes for ---------------
apiVersion: apps/v1
type: Deployment
metadata:
identify: deployment
namespace: deployment-apps-v1
--------------------------------------------
-- [error] AppArmorAnnotationMissing
Message: AppArmor annotation lacking. The annotation 'container.apparmor.safety.beta.kubernetes.io/container' needs to be added.
Metadata:
Container: container
MissingAnnotation: container.apparmor.safety.beta.kubernetes.io/container
-- [error] AutomountServiceAccountTokenTrueAndDefaultSA
Message: Default service account with token mounted. automountServiceAccountToken needs to be set to 'false' or a non-default service account needs to be used.
-- [error] CapabilityShouldDropAll
Message: Functionality not set to ALL. Ideally, you need to drop ALL capabilities and add the precise ones you want to the add checklist.
Metadata:
Container: container
Functionality: AUDIT_WRITE
...
If no errors with a given minimal severity are discovered, the next is returned:
Autofix
Manifest mode additionally helps autofixing all safety points utilizing the autofix
command:
kubeaudit autofix -f "/path/to/manifest.yml"
To put in writing the fastened manifest to a brand new file as a substitute of modifying the supply file, use the -o/--output
flag.
kubeaudit autofix -f "/path/to/manifest.yml" -o "/path/to/fastened"
To repair a manifest primarily based on customized guidelines specified on a kubeaudit config file, use the -k/--kconfig
flag.
kubeaudit autofix -k "/path/to/kubeaudit-config.yml" -f "/path/to/manifest.yml" -o "/path/to/fastened"
Cluster Mode
Kubeaudit can detect whether it is working inside a container in a cluster. If that’s the case, it is going to attempt to audit all Kubernetes assets in that cluster:
Native Mode
Kubeaudit will strive to connect with a cluster utilizing the native kubeconfig file ($HOME/.kube/config
). A special kubeconfig location will be specified utilizing the --kubeconfig
flag. To specify a context of the kubeconfig, use the -c/--context
flag.
kubeaudit all --kubeconfig "/path/to/config" --context my_cluster
For extra data on kubernetes config information, see https://kubernetes.io/docs/ideas/configuration/organize-cluster-access-kubeconfig/
Audit Outcomes
Kubeaudit produces outcomes with three ranges of severity:
Error
: A safety difficulty or invalid kubernetes configurationWarning
: A greatest observe adviceInformation
: Informational, no motion required. This consists of outcomes which might be overridden
The minimal severity stage will be set utilizing the --minSeverity/-m
flag.
By default kubeaudit will output leads to a human-readable method. If the output is meant to be additional processed, it may be set to output JSON utilizing the --format json
flag. To output outcomes as logs (the earlier default) use --format logrus
. Some output codecs embody colours to make outcomes simpler to learn in a terminal. To disable colours (for instance, if you’re sending output to a textual content file), you need to use the --no-color
flag.
If there are outcomes of severity stage error
, kubeaudit will exit with exit code 2. This may be modified utilizing the --exitcode/-e
flag.
For all of the methods kubeaudit will be custom-made, see World Flags.
Instructions
Command | Description | Documentation |
---|---|---|
all |
Runs all accessible auditors, or these specified utilizing a kubeaudit config. | docs |
autofix |
Routinely fixes safety points. | docs |
model |
Prints the present kubeaudit model. |
Auditors
Auditors may also be run individually.
Command | Description | Documentation |
---|---|---|
apparmor |
Finds containers working with out AppArmor. | docs |
asat |
Finds pods utilizing an routinely mounted default service account | docs |
capabilities |
Finds containers that don’t drop the beneficial capabilities or add new ones. | docs |
deprecatedapis |
Finds any useful resource outlined with a deprecated API model. | docs |
hostns |
Finds containers which have HostPID, HostIPC or HostNetwork enabled. | docs |
picture |
Finds containers which don’t use the specified model of a picture (through the tag) or use a picture with no tag. | docs |
limits |
Finds containers which exceed the required CPU and reminiscence limits or don’t specify any. | docs |
mounts |
Finds containers which have delicate host paths mounted. | docs |
netpols |
Finds namespaces that would not have a default-deny community coverage. | docs |
nonroot |
Finds containers working as root. | docs |
privesc |
Finds containers that permit privilege escalation. | docs |
privileged |
Finds containers working as privileged. | docs |
rootfs |
Finds containers which would not have a read-only filesystem. | docs |
seccomp |
Finds containers working with out Seccomp. | docs |
World Flags
Brief | Lengthy | Description |
---|---|---|
–format | The output format to make use of (considered one of “fairly”, “logrus”, “json”) (default is “fairly”) | |
–kubeconfig | Path to native Kubernetes config file. Solely utilized in native mode (default is $HOME/.kube/config ) |
|
-c | –context | The identify of the kubeconfig context to make use of |
-f | –manifest | Path to the yaml configuration to audit. Solely utilized in manifest mode. Chances are you’ll use - to learn from stdin. |
-n | –namespace | Solely audit assets within the specified namespace. Not at present supported in manifest mode. |
-g | –includegenerated | Embody generated assets in scan (comparable to Pods generated by deployments). If you want kubeaudit to provide outcomes for generated assets (for instance if in case you have customized assets or need to catch orphaned assets the place the proprietor useful resource now not exists) you need to use this flag. |
-m | –minseverity | Set the bottom severity stage to report (considered one of “error”, “warning”, “information”) (default is “information”) |
-e | –exitcode | Exit code to make use of if there are outcomes with severity of “error”. Conventionally, 0 is used for achievement and all non-zero codes for an error. (default is 2) |
–no-color | Do not use colours within the output (default is fake) |
Configuration File
The kubeaudit config can be utilized for 2 issues:
- Enabling just some auditors
- Specifying configuration for auditors
Any configuration that may be specified utilizing flags for the person auditors will be represented utilizing the config.
The config has the next format:
enabledAuditors:
# Auditors are enabled by default if they aren't explicitly set to "false"
apparmor: false
asat: false
capabilities: true
deprecatedapis: true
hostns: true
picture: true
limits: true
mounts: true
netpols: true
nonroot: true
privesc: true
privileged: true
rootfs: true
seccomp: true
auditors:
capabilities:
# add capabilities wanted to the add checklist, so kubeaudit will not report errors
allowAddList: ['AUDIT_WRITE', 'CHOWN']
deprecatedapis:
# If no variations are specified and the'deprecatedapis' auditor is enabled, WARN
# outcomes will likely be genereted for the assets outlined with a deprecated API.
currentVersion: '1.22'
targetedVersion: '1.25'
picture:
# If no picture is specified and the 'picture' auditor is enabled, WARN outcomes
# will likely be generated for containers which use an ima ge with no tag
picture: 'myimage:mytag'
limits:
# If no limits are specified and the 'limits' auditor is enabled, WARN outcomes
# will likely be generated for containers which don't have any cpu or reminiscence limits specified
cpu: '750m'
reminiscence: '500m'
For extra particulars about every auditor, together with an outline of the auditor-specific configuration within the config, see the Auditor Docs.
Be aware: The kubeaudit config shouldn’t be the identical because the kubeconfig file specified with the --kubeconfig
flag, which refers back to the Kubernetes config file (see Native Mode). Additionally word that solely the all
and autofix
instructions assist utilizing a kubeaudit config. It won’t work with different instructions.
Be aware: If flags are utilized in mixture with the config file, flags will take priority.
Override Errors
Safety points will be ignored for particular containers or pods by including override labels. This implies the auditor will produce information
outcomes as a substitute of error
outcomes and the audit end result identify may have Allowed
appended to it. The labels are documented in every auditor’s documentation, however the basic format for auditors that assist overrides is as follows:
An override label consists of a key
and a worth
.
The key
is a mix of the override sort (container or pod) and an override identifier
which is exclusive to every auditor (see the docs for the precise auditor). The key
can take considered one of two kinds relying on the override sort:
- Container overrides, which override the auditor for that particular container, are formatted as follows:
container.audit.kubernetes.io/[container name].[override identifier]
- Pod overrides, which override the auditor for all containers throughout the pod, are formatted as follows:
audit.kubernetes.io/pod.[override identifier]
If the worth
is ready to a non-empty string, it will likely be displayed within the information
end result because the OverrideReason
:
$ kubeaudit asat -f "auditors/asat/fixtures/service-account-token-true-allowed.yml"---------------- Outcomes for ---------------
apiVersion: v1
type: ReplicationController
metadata:
identify: replicationcontroller
namespace: service-account-token-true-allowed
--------------------------------------------
-- [info] AutomountServiceAccountTokenTrueAndDefaultSAAllowed
Message: Audit end result overridden: Default service account with token mounted. automountServiceAccountToken needs to be set to 'false' or a non-default service account needs to be used.
Metadata:
OverrideReason: SomeReason
As per Kubernetes spec, worth
should be 63 characters or much less and should be empty or start and finish with an alphanumeric character ([a-z0-9A-Z]
) with dashes (-
), underscores (_
), dots (.
), and alphanumerics between.
A number of override labels (for a number of auditors) will be added to the identical useful resource.
See the precise auditor docs for the auditor you want to override for examples.
To be taught extra about labels, see https://kubernetes.io/docs/ideas/overview/working-with-objects/labels/
Contributing
If you would like to repair a bug, contribute a characteristic or simply right a typo, please be at liberty to take action so long as you observe our Code of Conduct.
- Create your personal fork!
- Get the supply:
go get github.com/Shopify/kubeaudit
- Go to the supply:
cd $GOPATH/src/github.com/Shopify/kubeaudit
- Add your forked repo as a fork:
git distant add fork https://github.com/you-are-awesome/kubeaudit
- Create your characteristic department:
git checkout -b awesome-new-feature
- Set up Sort
- Run the assessments to see every thing is working as anticipated:
make take a look at
(to run assessments with out Sort:USE_KIND=false make take a look at
) - Commit your modifications:
git commit -am 'Provides superior characteristic'
- Push to the department:
git push fork
- Signal the Contributor License Settlement
- Submit a PR (All PR should be labeled with
(Bug repair),
(New characteristic),
(Documentation replace), or
(Breaking modifications) )
- ???
- Revenue
Be aware that if you happen to did not signal the CLA earlier than opening your PR, you may re-run the verify by including a remark to the PR that claims “I’ve signed the CLA!”!