kubeaudit helps you audit your Kubernetes clusters against common security controls

Build Status Go Report Card GoDoc

Kubeaudit can now be used as both a command line tool (CLI) and as a Go package!

kubeaudit โ˜๏ธ ๐Ÿ”’ ๐Ÿ’ช

kubeaudit is a command line tool and a Go package to audit Kubernetes clusters for various different security concerns, such as:

  • run as non-root
  • use a read-only root filesystem
  • drop scary capabilities, don't add new ones
  • don't run privileged
  • and more!

tldr. kubeaudit makes sure you deploy secure containers!

Package

To use kubeaudit as a Go package, see the package docs.

The rest of this README will focus on how to use kubeaudit as a command line tool.

Command Line Interface (CLI)

Installation

Brew

brew install kubeaudit

Download a binary

Kubeaudit has official releases that are blessed and stable: Official releases

DIY build

Master may have newer features than the stable releases. If you need a newer feature not yet included in a release, make sure you're using Go 1.16+ and run the following:

go get -v github.com/Shopify/kubeaudit

Start using kubeaudit with the Quick Start or view all the supported commands.

Kubectl Plugin

Prerequisite: kubectl v1.12.0 or later

With kubectl v1.12.0 introducing easy pluggability of external functions, kubeaudit can be invoked as kubectl audit by

  • running make plugin and having $GOPATH/bin available in your path.

or

  • renaming the binary to kubectl-audit and having it available in your path.

Docker

We also release a Docker image: shopify/kubeaudit. To run kubeaudit as a job in your cluster see Running kubeaudit in a cluster.

Quick Start

kubeaudit has three modes:

  1. Manifest mode
  2. Local mode
  3. Cluster mode

Manifest Mode

If a Kubernetes manifest file is provided using the -f/--manifest flag, kubeaudit will audit the manifest file.

Example command:

kubeaudit all -f "/path/to/manifest.yml"

Example output:

$ kubeaudit all -f "internal/test/fixtures/all_resources/deployment-apps-v1.yml"

---------------- Results for ---------------

  apiVersion: apps/v1
  kind: Deployment
  metadata:
    name: deployment
    namespace: deployment-apps-v1

--------------------------------------------

-- [error] AppArmorAnnotationMissing
   Message: AppArmor annotation missing. The annotation 'container.apparmor.security.beta.kubernetes.io/container' should be added.
   Metadata:
      Container: container
      MissingAnnotation: container.apparmor.security.beta.kubernetes.io/container

-- [error] AutomountServiceAccountTokenTrueAndDefaultSA
   Message: Default service account with token mounted. automountServiceAccountToken should be set to 'false' or a non-default service account should be used.

-- [error] CapabilityShouldDropAll
   Message: Capability not set to ALL. Ideally, you should drop ALL capabilities and add the specific ones you need to the add list.
   Metadata:
      Container: container
      Capability: AUDIT_WRITE
...

If no errors with a given minimum severity are found, the following is returned:

All checks completed. 0 high-risk vulnerabilities found

Autofix

Manifest mode also supports autofixing all security issues using the autofix command:

kubeaudit autofix -f "/path/to/manifest.yml"

To write the fixed manifest to a new file instead of modifying the source file, use the -o/--output flag.

kubeaudit autofix -f "/path/to/manifest.yml" -o "/path/to/fixed"

To fix a manifest based on custom rules 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/fixed"

Cluster Mode

Kubeaudit can detect if it is running within a container in a cluster. If so, it will try to audit all Kubernetes resources in that cluster:

kubeaudit all

Local Mode

Kubeaudit will try to connect to a cluster using the local kubeconfig file ($HOME/.kube/config). A different kubeconfig location can be specified using the -c/--kubeconfig flag.

kubeaudit all -c "/path/to/config"

For more information on kubernetes config files, see https://kubernetes.io/docs/concepts/configuration/organize-cluster-access-kubeconfig/

Audit Results

Kubeaudit produces results with three levels of severity:

Error: A security issue or invalid kubernetes configuration Warning: A best practice recommendation Info: Informational, no action required. This includes results that are overridden

The minimum severity level can be set using the --minSeverity/-m flag.

By default kubeaudit will output results in a human-readable way. If the output is intended to be further processed, it can be set to output JSON using the --format json flag. To output results as logs (the previous default) use --format logrus.

If there are results of severity level error, kubeaudit will exit with exit code 2. This can be changed using the --exitcode/-e flag.

For all the ways kubeaudit can be customized, see Global Flags.

Commands

Command Description Documentation
all Runs all available auditors, or those specified using a kubeaudit config. docs
autofix Automatically fixes security issues. docs
version Prints the current kubeaudit version.

Auditors

Auditors can also be run individually.

Command Description Documentation
apparmor Finds containers running without AppArmor. docs
asat Finds pods using an automatically mounted default service account docs
capabilities Finds containers that do not drop the recommended capabilities or add new ones. docs
hostns Finds containers that have HostPID, HostIPC or HostNetwork enabled. docs
image Finds containers which do not use the desired version of an image (via the tag) or use an image without a tag. docs
limits Finds containers which exceed the specified CPU and memory limits or do not specify any. docs
mounts Finds containers that have sensitive host paths mounted. docs
netpols Finds namespaces that do not have a default-deny network policy. docs
nonroot Finds containers running as root. docs
privesc Finds containers that allow privilege escalation. docs
privileged Finds containers running as privileged. docs
rootfs Finds containers which do not have a read-only filesystem. docs
seccomp Finds containers running without Seccomp. docs

Global Flags

Short Long Description
--format The output format to use (one of "pretty", "logrus", "json") (default is "pretty")
-c --kubeconfig Path to local Kubernetes config file. Only used in local mode (default is $HOME/.kube/config)
-f --manifest Path to the yaml configuration to audit. Only used in manifest mode.
-n --namespace Only audit resources in the specified namespace. Not currently supported in manifest mode.
-m --minseverity Set the lowest severity level to report (one of "error", "warning", "info") (default "info")
-e --exitcode Exit code to use if there are results with severity of "error". Conventionally, 0 is used for success and all non-zero codes for an error. (default 2)

Configuration File

The kubeaudit config can be used for two things:

  1. Enabling only some auditors
  2. Specifying configuration for auditors

Any configuration that can be specified using flags for the individual auditors can be represented using the config.

The config has the following format:

enabledAuditors:
  # Auditors are enabled by default if they are not explicitly set to "false"
  apparmor: false
  asat: false
  capabilities: true
  hostns: true
  image: true
  limits: true
  mounts: true
  netpols: true
  nonroot: true
  privesc: true
  privileged: true
  rootfs: true
  seccomp: true
auditors:
  capabilities:
    # add capabilities needed to the add list, so kubeaudit won't report errors
    allowAddList: ['AUDIT_WRITE', 'CHOWN']
  image:
    # If no image is specified and the 'image' auditor is enabled, WARN results
    # will be generated for containers which use an image without a tag
    image: 'myimage:mytag'
  limits:
    # If no limits are specified and the 'limits' auditor is enabled, WARN results
    # will be generated for containers which have no cpu or memory limits specified
    cpu: '750m'
    memory: '500m'

For more details about each auditor, including a description of the auditor-specific configuration in the config, see the Auditor Docs.

Note: The kubeaudit config is not the same as the kubeconfig file specified with the -c/--kubeconfig flag, which refers to the Kubernetes config file (see Local Mode). Also note that only the all and autofix commands support using a kubeaudit config. It will not work with other commands.

Note: If flags are used in combination with the config file, flags will take precedence.

Override Errors

Security issues can be ignored for specific containers or pods by adding override labels. This means the auditor will produce info results instead of error results and the audit result name will have Allowed appended to it. The labels are documented in each auditor's documentation, but the general format for auditors that support overrides is as follows:

An override label consists of a key and a value.

The key is a combination of the override type (container or pod) and an override identifier which is unique to each auditor (see the docs for the specific auditor). The key can take one of two forms depending on the override type:

  1. Container overrides, which override the auditor for that specific container, are formatted as follows:
container.audit.kubernetes.io/[container name].[override identifier]
  1. Pod overrides, which override the auditor for all containers within the pod, are formatted as follows:
audit.kubernetes.io/pod.[override identifier]

If the value is set to a non-empty string, it will be displayed in the info result as the OverrideReason:

$ kubeaudit asat -f "auditors/asat/fixtures/service-account-token-true-allowed.yml"

---------------- Results for ---------------

  apiVersion: v1
  kind: ReplicationController
  metadata:
    name: replicationcontroller
    namespace: service-account-token-true-allowed

--------------------------------------------

-- [info] AutomountServiceAccountTokenTrueAndDefaultSAAllowed
   Message: Audit result overridden: Default service account with token mounted. automountServiceAccountToken should be set to 'false' or a non-default service account should be used.
   Metadata:
      OverrideReason: SomeReason

As per Kubernetes spec, value must be 63 characters or less and must be empty or begin and end with an alphanumeric character ([a-z0-9A-Z]) with dashes (-), underscores (_), dots (.), and alphanumerics between.

Multiple override labels (for multiple auditors) can be added to the same resource.

See the specific auditor docs for the auditor you wish to override for examples.

To learn more about labels, see https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/

Contributing

If you'd like to fix a bug, contribute a feature or just correct a typo, please feel free to do so as long as you follow our Code of Conduct.

  1. Create your own fork!
  2. Get the source: go get github.com/Shopify/kubeaudit
  3. Go to the source: cd $GOPATH/src/github.com/Shopify/kubeaudit
  4. Add your forked repo as a fork: git remote add fork https://github.com/you-are-awesome/kubeaudit
  5. Create your feature branch: git checkout -b awesome-new-feature
  6. Install Kind
  7. Run the tests to see everything is working as expected: make test (to run tests without Kind: USE_KIND=false make test)
  8. Commit your changes: git commit -am 'Adds awesome feature'
  9. Push to the branch: git push fork
  10. Sign the Contributor License Agreement
  11. Submit a PR (All PR must be labeled with ๐Ÿ› (Bug fix), โœจ (New feature), ๐Ÿ“– (Documentation update), or โš ๏ธ (Breaking changes) )
  12. ???
  13. Profit

Note that if you didn't sign the CLA before opening your PR, you can re-run the check by adding a comment to the PR that says "I've signed the CLA!"!

Comments
  • Migrate to Seccomp profile in security Context :warning:

    Migrate to Seccomp profile in security Context :warning:

    Description

    This PR changes seccomp auditor to scan seccompProfile instead of annotations as requested in https://github.com/Shopify/kubeaudit/issues/343 The following changes were done:

    • seccomp auditor changed to scan securityContext in pod and containers to find seccompProfile. :warning:
    • New fix created in seccomp auditor to create seccomp profile in a pod and containers and to remove profile in containers. The auditor updated to use the new fix.
    • SeccompAnnotationMissing rule renamed to SeccompProfileMissing. :warning:
    • SeccompDeprecatedContainer rule dropped. :warning:
    • Tests updated to cover changes in auditor and fix.
    • Documentation updated.

    Fixes #343

    Type of change
    • [X] This change requires a documentation update :book:
    • [X] Breaking changes :warning:
    How Has This Been Tested?
    • Mostly by automated tests.
    • I've also executed kubeaudit for examples from documentation to update them.
    Checklist:
    • [ ] I have :tophat: my changes (A ๐ŸŽฉ specifically includes pulling down changes, setting them up, and manually testing the changed features and potential side effects to make sure nothing is broken)
    • [X] I have performed a self-review of my own code
    • [X] I have made corresponding changes to the documentation
    • [X] I have added tests that prove my fix is effective or that my feature works
    • [X] New and existing unit tests pass locally with my changes
    • [X] The test coverage did not decrease
    • [X] I have signed the appropriate Contributor License Agreement
  • Add a new command to audit runAsUser fields

    Add a new command to audit runAsUser fields

    Description

    Add a new command to audit runAsUser fields. The audit will trigger an alert when the container user ID is not overridden with a non-root user using the runAsUser either in the Pod Security Context or the container Security Context. The check will fail if no runAsUser is specified or if it uses the 0 UID. This is useful to enforce non-root user in container at runtime.

    Here's a sample result:

    kubeaudit runasuser -f "auditors/runasuser/fixtures/run-as-user-0.yml" 
    
    ---------------- Results for ---------------
    
      apiVersion: apps/v1
      kind: Deployment
      metadata:
        name: deployment
        namespace: run-as-user-0
    
    --------------------------------------------
    
    -- [error] RunAsUserCSCRoot
       Message: container user ID not overridden to non-root user using runAsUser SecurityContext. It should be set to > 0.
       Metadata:
          Container: container
    

    I've also modified the nonroot command's description from This command determines which containers are running as root (uid=0) to This command determines which containers are allowed to run as root (uid=0). because even when runAsNonRoot is set to true or is missing, this doesn't mean that the container will effectively run as root, only that it will be permitted to use the root user if it's the one specified in the image.

    Type of change
    • [x] New feature :sparkles:
    • [x] This change requires a documentation update ๐Ÿ“–
    How Has This Been Tested?
    • [x] Automated tests
    • [x] Manual tests (cluster - local mode, manifest files)
    Checklist:
    • [x] I have ๐ŸŽฉ my changes (A ๐ŸŽฉ specifically includes pulling down changes, setting them up, and manually testing the changed features and potential side effects to make sure nothing is broken)
    • [x] I have performed a self-review of my own code
    • [x] I have made corresponding changes to the documentation
    • [x] I have added tests that prove my fix is effective or that my feature works
    • [x] New and existing unit tests pass locally with my changes
    • [] The test coverage did not decrease
    • [x] I have signed the appropriate Contributor License Agreement
  • Quota cmd

    Quota cmd

    Hi,

    Setting CPU and memory limits is a good security practice. (see http://blog.kubernetes.io/2016/08/security-best-practices-kubernetes-deployment.html) Why not test this with a kubeaudit command?

    What do you think of this notion and my implementation? Your feedbacks are very welcome.

    Regards, Jeremie.

  • Bugfixes: Allow any of the deployment types to be used, fix spurious errors on services

    Bugfixes: Allow any of the deployment types to be used, fix spurious errors on services

    This PR fixes two issues I encountered while trying out kubeaudit:

    1. When using another deployment type than the one specified in types.go, checks would silently fail.
    2. When running kubeaudit on a type not known to it (Such as, for example, running kubeaudit -f <service yaml>), you'd get an incorrect error that automountServiceAccountToken: false needed to be set.
  • runAsNonRoot False Positive

    runAsNonRoot False Positive

    ISSUE TYPE
    • [x] Bug Report

    BUG REPORT

    SUMMARY

    Kubeaudit currently returns False positives for "runAsNonRoot". It shows that the Security Context does not have this set ('RunAsNonRoot is not set in ContainerSecurityContext, which results in root user being allowed!'). Is this because it's looking for "RunAsNonRoot" whereas Security Context has "runAsNonRoot" set on it (Caps on 'r')?

    ENVIRONMENT
    • Kubeaudit version: 0.0.0
    • Kubeaudit install method: DIY-BUILD
    STEPS TO REPRODUCE

    General Run of kubeaudit

    EXPECTED RESULTS

    Not see 'RunAsNonRoot is not set in ContainerSecurityContext, which results in root user being allowed!' flagged up as an error

    ACTUAL RESULTS
    'RunAsNonRoot is not set in ContainerSecurityContext, which results in root user being allowed!' as the Error output
    
    ADDITIONAL INFORMATION

    Security Context:

            securityContext:
            fsGroup: 64999
            runAsGroup: 2000
            runAsNonRoot: true
            runAsUser: 2000
    

    Kubeaudit Report:

    {'Container': <Redacted>, 'KubeType': 'daemonSet', 'Name': <Redacted>, 'Namespace': <Redacted>, 'level': 'error', 'msg': 'RunAsNonRoot is not set in ContainerSecurityContext, which results in root user being allowed!', 'time': '2020-04-20T14:30:15-07:00'}
    
  • Initial support for networkPolicy audit

    Initial support for networkPolicy audit

    Signed-off-by: Johannes M. Scheuermann [email protected]

    This PR implements: https://github.com/Shopify/kubeaudit/issues/117

    ToDo

    • [x] Implement check for default-deny
    • [x] Add unit test for NetworkPolicy audit
  • Kubeaudit throws errors instead of warning for unsupported types

    Kubeaudit throws errors instead of warning for unsupported types

    ISSUE TYPE
    • [x] Bug Report
    • [ ] Feature Idea

    BUG REPORT

    SUMMARY

    Kubeaudit returns an error instead of a warnig for k8s Jobs because they're unsupported.

    ENVIRONMENT
    • Kubeaudit version: latest
    • Kubeaudit install method: DIY-BUILD/Github app
    STEPS TO REPRODUCE

    Run kubeaudit all -f validJobTemplate.yml

    EXPECTED RESULTS

    Receive a warning that Jobs are not supported by kubeaudit

    ACTUAL RESULTS

    Kubeaudit threw an error that caused my CI to fail

    ADDITIONAL INFORMATION

    image

  • Support dash as short for stdin

    Support dash as short for stdin

    Description

    Simple addition to support a dash as alias for /dev/stdin.

    I would expect a cli tool to accept a simple - in order to read from the stdin stream. For example currently I have to write:

    kustomize build . | kubeaudit all -f /dev/stdin.

    This pr makes it more straightforward: kustomize build . | kubeaudit all -f -

    Type of change
    • [ ] Bug fix :bug:
    • [x] New feature :sparkles:
    • [ ] This change requires a documentation update :book:
    • [ ] Breaking changes :warning:
    How Has This Been Tested?

    Just manually, did not find any preexisting place where cli args are tested, maybe you can point to that if a test is needed.

    • [ ] Test A
    • [ ] Test B
    Checklist:
    • [x] I have :tophat: my changes (A ๐ŸŽฉ specifically includes pulling down changes, setting them up, and manually testing the changed features and potential side effects to make sure nothing is broken)
    • [x] I have performed a self-review of my own code
    • [ ] I have made corresponding changes to the documentation
    • [ ] I have added tests that prove my fix is effective or that my feature works
    • [ ] New and existing unit tests pass locally with my changes
    • [ ] The test coverage did not decrease
    • [x] I have signed the appropriate Contributor License Agreement
  • ๐Ÿ›  Fix deadlink in seccomp auditor docs

    ๐Ÿ› Fix deadlink in seccomp auditor docs

    Description

    Replace dead link to gardener.cloud seccomp tutorial with official kubernetes seccomp tutorial.

    Type of change
    • [x] Bug fix :bug:
    • [ ] New feature :sparkles:
    • [ ] This change requires a documentation update :book:
    • [ ] Breaking changes :warning:
  • support for CRD's that extend common types

    support for CRD's that extend common types

    ISSUE TYPE
    • [ ] Bug Report
    • [X] Feature Idea
    SUMMARY

    I've noticed that Kubeaudit doesn't catch CRDS that are extending typical k8s resources, like apps/v1. It looks like either with finagling the data out with kubectl and scanning you can still get to the original source of truth.

    STEPS TO REPRODUCE

    create a custom CRD based off apps scan k8s don't find anything wrong with deploy applications

    EXPECTED RESULTS

    It should find them

    other stuff

    if you guys want to point me in the direction of where in the code one can specify a custom CRD, that'll work for me and I'll add a flag to support it.

  • Running Kubeaudit as a Cronjob and Kubeaudit's Contianer image

    Running Kubeaudit as a Cronjob and Kubeaudit's Contianer image

    ISSUE TYPE
    • [x] Bug Report

    BUG REPORT

    SUMMARY

    I don't seem to find a kubernetes manifest file over here. I would like to run Kubeaudit as a Cronjob for example. Is this documented somewhere?

  • โœจ Support jsonpath expressions

    โœจ Support jsonpath expressions

    Description

    Implements https://github.com/Shopify/kubeaudit/issues/509

    This is a draft PR that outlines the basic implementation approach for this feature

    Type of change
    • [x] New feature :sparkles:
    How Has This Been Tested?
    • [ ] Test A
    • [ ] Test B
    Checklist:
    • [ ] I have :tophat: my changes (A ๐ŸŽฉ specifically includes pulling down changes, setting them up, and manually testing the changed features and potential side effects to make sure nothing is broken)
    • [ ] I have performed a self-review of my own code
    • [ ] I have made corresponding changes to the documentation
    • [ ] I have added tests that prove my fix is effective or that my feature works
    • [ ] New and existing unit tests pass locally with my changes
    • [ ] The test coverage did not decrease
    • [ ] I have signed the appropriate Contributor License Agreement
  • CLI flag to add arbitrary metadata fields to audit results

    CLI flag to add arbitrary metadata fields to audit results

    FEATURE IDEA

    ISSUE TYPE
    • [ ] Bug Report

    • [x] Feature Idea

    • [x] If the maintainers agree with the feature as described here, I intend to submit a Pull Request myself.1

    Proposal

    It would be great if we could have kubeaudit return additional metadata about resources as part of its structured response. For example, useful, platform-specific, information is often stored in annotations, but other metadata such as ownerReferences can be useful when trying to understand where a particular resource is coming from.

    For a flexible solution, we could provide a new flag, --metadata=[comma,separated,JSONPath expr]. These JSONPath expressions can then be used to traverse the metadata of each resource and add the results to the audit response.

    From a quick look through the code, it looks like we maintain an in-memory representation of resources, and have some ability to traverse its metadata (though I have to look more closely at the overall implementation). I'm not sure how easy/hard it will be to implement this across all auditors, or if this can be done at a more abstract level. If the former, likely we will need to split this up into several PRs as we build this out for all auditors.

  • add more resources policies to limits auditor

    add more resources policies to limits auditor

    NSA's K8s hardening guidelines mention LimitRanges, ResourceQuotas, and Process ID on page 24 as something that can be set to harden k8s clusters

    Limits restrict resource usage for namespaces, nodes, or Pods. These policies are important to reserve compute and storage space for a resource and avoid resource exhaustion.

    It'd be nice to have the limits auditor also flag when those policies are not set. Alternatively, we can create a new resources policies auditor?

    ISSUE TYPE
    • [ ] Bug Report
    • [x] Feature Idea

    FEATURE IDEA

    • [ ] If the maintainers agree with the feature as described here, I intend to submit a Pull Request myself.1

    Proposal:

    1 This is the quickest way to get a new feature! We reserve the right to close feature requests, even ones we like, if the proposer does not intend to contribute to the feature and it doesn't fit in our current roadmap.

  • Support LoadBalancer and NodePort resources

    Support LoadBalancer and NodePort resources

    Services can be exposed externally using NodePorts or LoadBalancers, and internally. Exposing services might be unintended.

    It could be nice to create auditors to alert users on unintended exposure to the public internet.

    ISSUE TYPE
    • [ ] Bug Report
    • [x] Feature Idea

    FEATURE IDEA

    • [ ] If the maintainers agree with the feature as described here, I intend to submit a Pull Request myself.1

    Proposal:

    1 This is the quickest way to get a new feature! We reserve the right to close feature requests, even ones we like, if the proposer does not intend to contribute to the feature and it doesn't fit in our current roadmap.

  • Sysctls audits

    Sysctls audits

    Going through Kubernetes pod security standards, it seems it'd be desirable to audit sysctls.

    Sysctls can disable security mechanisms or affect all containers on a host, and should be disallowed except for an allowed "safe" subset. A sysctl is considered safe if it is namespaced in the container or the Pod, and it is isolated from other Pods or processes on the same Node.
    
    Restricted Fields
    - spec.securityContext.sysctls[*].name
    
    AllowedValues
    
    - Undefined/nil
    - kernel.shm_rmid_forced
    - net.ipv4.ip_local_port_range
    - net.ipv4.ip_unprivileged_port_start
    - net.ipv4.tcp_syncookies
    - net.ipv4.ping_group_range
    
    ISSUE TYPE
    • [ ] Bug Report
    • [x] Feature Idea

    FEATURE IDEA

    • [ ] If the maintainers agree with the feature as described here, I intend to submit a Pull Request myself.1

    Proposal:

    1 This is the quickest way to get a new feature! We reserve the right to close feature requests, even ones we like, if the proposer does not intend to contribute to the feature and it doesn't fit in our current roadmap.

  • SELinux audits

    SELinux audits

    Going through Kubernetes pod security standards, it seem it'd be desirable to audit custom SELinux user or role.

    Setting the SELinux type is restricted, and setting a custom SELinux user or role option is forbidden.
    
    Restricted Fields
    
    - spec.securityContext.seLinuxOptions.type
    - spec.containers[*].securityContext.seLinuxOptions.type
    - spec.initContainers[*].securityContext.seLinuxOptions.type
    - spec.ephemeralContainers[*].securityContext.seLinuxOptions.type
    
    Allowed Values
    
    - Undefined/""
    - container_t
    - container_init_t
    - container_kvm_t
    
    Restricted Fields
    
    - spec.securityContext.seLinuxOptions.user
    - spec.containers[*].securityContext.seLinuxOptions.user
    - spec.initContainers[*].securityContext.seLinuxOptions.user
    - spec.ephemeralContainers[*].securityContext.seLinuxOptions.user
    - spec.securityContext.seLinuxOptions.role
    - spec.containers[*].securityContext.seLinuxOptions.role
    - spec.initContainers[*].securityContext.seLinuxOptions.role
    - spec.ephemeralContainers[*].securityContext.seLinuxOptions.role
    
    Allowed Values
    
    - Undefined/""
    
    ISSUE TYPE
    • [ ] Bug Report
    • [x] Feature Idea

    BUG REPORT

    SUMMARY

    Follow best practices and latest security recommendations

    FEATURE IDEA

    • [ ] If the maintainers agree with the feature as described here, I intend to submit a Pull Request myself.1

    Proposal:

    1 This is the quickest way to get a new feature! We reserve the right to close feature requests, even ones we like, if the proposer does not intend to contribute to the feature and it doesn't fit in our current roadmap.

A fork of k3sup that lets you quickly deploy RKE2 clusters via the CLI.

k2sup This is an awful hack of a fork of Alex Ellis' k3sup - a light-weight utility to get from zero to KUBECONFIG, originally with K3s but now with R

Dec 12, 2022
CLI to run your dataframes against SLU service and generated labeled dataframe.

trail CLI to run your dataframes against different services (currently, SLU service). Setup Get the latest binaries from the releases here. Choose the

Nov 12, 2021
Issue-mafia - An out-of-the-box CLI that helps you to easily synchronize Git hooks with a remote repository

issue-mafia is an out-of-the-box CLI that helps you to easily synchronize Git hooks with a remote repository.

Feb 14, 2022
Are you programming and suddenly your stomach is rumbling? No problem, order your Ifood without leaving your favorite text editor โค๏ธ

vim-ifood Vocรช ta programando e de repente bateu aquela fome? Sem problemas, peรงa seu Ifood sem sair do seu editor de texto favorito โค๏ธ Are you progra

Jun 2, 2022
Commando - run commands against networking devices in batch mode
Commando - run commands against networking devices in batch mode

Commando is a tiny tool that enables users to collect command outputs from a single or a multiple networking devices defined in an inventory file.

Oct 30, 2022
ntest is a cross-platform cli app that runs multiple tests against any address.
ntest is a cross-platform cli app that runs multiple tests against any address.

ntest ntest is a cross-platform cli app that runs multiple tests against any address. About ntest Having the ability to run common tests against any d

Jan 3, 2022
This plugin will analyse the JFrog Platform instance and provide the non conformance against the best practices based on the predefines rules.

hello-frog About this plugin This plugin is a template and a functioning example for a basic JFrog CLI plugin. This README shows the expected structur

Nov 30, 2021
This utility verifies all commands used by a shell script against an allow list

Find external commands required by shell scripts When writing shell scripts that need to run portably across multiple hosts and platforms, it's useful

Aug 15, 2022
The Keel CLI allows you to setup Keel on your local dev machine or on a Kubernetes cluster
The Keel CLI allows you to setup Keel on your local dev machine or on a Kubernetes cluster

keel-cli What is keel-cli The Keel CLI allows you to setup Keel on your local dev machine or on a Kubernetes cluster, launches and manages Keel instan

Oct 7, 2021
The Dapr CLI allows you to setup Dapr on your local dev machine or on a Kubernetes cluster

Dapr CLI The Dapr CLI allows you to setup Dapr on your local dev machine or on a

Dec 23, 2021
Allows you to use the magic remote on your webOS LG TV as a keyboard/mouse for your Linux machine

magic4linux Allows you to use the magic remote on your webOS LG TV as a keyboard/mouse for your PC Linux machine. This is a Linux implementation of th

Nov 25, 2022
A Go library and a command-line tool to manage Docker Swarm clusters

go-swarm go-swarm is a Go library and command-line tool for managing the creation and maintenance of Docker Swarm cluster. Features: Creates new Swarm

Jul 26, 2022
eksctl is a simple CLI tool for creating clusters on EKS
eksctl is a simple CLI tool for creating clusters on EKS

eksctl is a simple CLI tool for creating clusters on EKS - Amazon's new managed Kubernetes service for EC2. It is written in Go, and uses CloudFormation.

Jan 7, 2023
e2d is a command-line tool for deploying and managing etcd clusters, both in the cloud or on bare-metal

e2d is a command-line tool for deploying and managing etcd clusters, both in the cloud or on bare-metal. It also includes e2db, an ORM-like abstraction for working with etcd.

Aug 23, 2022
CraftTalk Command Line Tool helps with managing CraftTalk releases on baremetal instances

ctcli - CraftTalk Command Line Tool Commands help Shows help version Shows version init Initializes specified root directory as a ctcli dir. ctcli --r

Jan 20, 2022
CLI for SendGrid, which helps in managing SSO users, can install and update users from yaml config

Sendgrid API This script is needed to add new users to SendGrid as SSO teammates. Previously, all users were manually added and manually migrating the

Jul 20, 2022
The Discord terminal client you never knew you wanted.
The Discord terminal client you never knew you wanted.

I AM CLOSING DOWN THE CORDLESS PROJECT Hey, so I know this is somewhat of a bummer, but I got banned because of ToS violation today. This seemed to be

Jan 7, 2023
yq lets you read YAML files easily on the terminal. You can find key/values easily
yq lets you read YAML files easily on the terminal. You can find key/values easily

yq yq lets you read YAML files easily on the terminal. You can find key/values easily. Motivation Reading yaml configurations for k8s file becomes ard

Nov 2, 2021
Golisp-wtf - A lisp interpreter (still just a parser) implementation in golang. You may yell "What the fuck!?.." when you see the shitty code.

R6RS Scheme Lisp dialect interpreter This is an implementation of a subset of R6RS Scheme Lisp dialect in golang. The work is still in progress. At th

Jan 7, 2022