New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Initial bug-bounty scope #2620

Open
wants to merge 3 commits into
base: master
from

Conversation

@tallclair
Member

tallclair commented Aug 31, 2018

First attempt at the scope for Kubernetes bug bounty program.

I wasn't sure here to put the file. LMK if you have a better idea.

/assign @cjcullen @liggitt @philips @jessfraz
/cc @destijl @mayakacz

@k8s-ci-robot

This comment has been minimized.

Show comment
Hide comment
@k8s-ci-robot

k8s-ci-robot Aug 31, 2018

Contributor

@tallclair: GitHub didn't allow me to request PR reviews from the following users: mayakacz.

Note that only kubernetes members and repo collaborators can review this PR, and authors cannot review their own PRs.

In response to this:

First attempt at the scope for Kubernetes bug bounty program.

I wasn't sure here to put the file. LMK if you have a better idea.

/assign @cjcullen @liggitt @philips @jessfraz
/cc @destijl @mayakacz

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

Contributor

k8s-ci-robot commented Aug 31, 2018

@tallclair: GitHub didn't allow me to request PR reviews from the following users: mayakacz.

Note that only kubernetes members and repo collaborators can review this PR, and authors cannot review their own PRs.

In response to this:

First attempt at the scope for Kubernetes bug bounty program.

I wasn't sure here to put the file. LMK if you have a better idea.

/assign @cjcullen @liggitt @philips @jessfraz
/cc @destijl @mayakacz

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

Show outdated Hide outdated contributors/guide/bug-bounty.md
Show outdated Hide outdated contributors/guide/bug-bounty.md
Show outdated Hide outdated contributors/guide/bug-bounty.md
Show outdated Hide outdated contributors/guide/bug-bounty.md
The following items are explicitly out-of scope for the bug bounty program. While we still welcome
vulnerability reports in these areas, they are not (currently) eligible to receive a bounty.
- Alpha features & APIs

This comment has been minimized.

@mayakacz

mayakacz Sep 4, 2018

and Beta? if not, explicitly state above

@mayakacz

mayakacz Sep 4, 2018

and Beta? if not, explicitly state above

This comment has been minimized.

@tallclair

tallclair Sep 4, 2018

Member

done. We decided to include beta features, since they are enabled by default.

@tallclair

tallclair Sep 4, 2018

Member

done. We decided to include beta features, since they are enabled by default.

_Please report these through security@kernel.org_
- Attacks against containers from the host they are running on
- Attacks relying on insecure configurations, such as clusters not utilizing mutual authentication
or encryption between Kubernetes components.

This comment has been minimized.

@mayakacz

mayakacz Sep 4, 2018

this is going to be the hardest to define. Is there a specific hardening or config guide we want to suggest?
else, would make more specific/ remove. This can be too broad

@mayakacz

mayakacz Sep 4, 2018

this is going to be the hardest to define. Is there a specific hardening or config guide we want to suggest?
else, would make more specific/ remove. This can be too broad

This comment has been minimized.

@tallclair

tallclair Sep 4, 2018

Member

Yeah, this ate up a big portion of our meeting, but I don't think we landed on anything.

Anyone have suggestions? Or should we just remove it?

@tallclair

tallclair Sep 4, 2018

Member

Yeah, this ate up a big portion of our meeting, but I don't think we landed on anything.

Anyone have suggestions? Or should we just remove it?

This comment has been minimized.

@liggitt

liggitt Sep 4, 2018

Member

https://kubernetes.io/docs/tasks/administer-cluster/securing-a-cluster/ hits most of the highlights, but doesn't mention PodSecurityPolicy

@liggitt

liggitt Sep 4, 2018

Member

https://kubernetes.io/docs/tasks/administer-cluster/securing-a-cluster/ hits most of the highlights, but doesn't mention PodSecurityPolicy

This comment has been minimized.

@raesene

raesene Sep 11, 2018

FWIW I think you'd definitely want to exclude any bounty reports that could be mitigated by secure configuration of the cluster (i.e. if it's possible to use existing k8s configuration options to mitigate an issue, it doesn't count). Otherwise you'll get a load of reports around things like SSL configuration which are easy to test for but can be mitigated with start-up flags.

If you do want to refer to a guide in terms of "if it's in here as suggest don't report it" you could go for the CIS guide which probably covers most of the areas in question (or if it's missing them, they could easily be added to a future version).

@raesene

raesene Sep 11, 2018

FWIW I think you'd definitely want to exclude any bounty reports that could be mitigated by secure configuration of the cluster (i.e. if it's possible to use existing k8s configuration options to mitigate an issue, it doesn't count). Otherwise you'll get a load of reports around things like SSL configuration which are easy to test for but can be mitigated with start-up flags.

If you do want to refer to a guide in terms of "if it's in here as suggest don't report it" you could go for the CIS guide which probably covers most of the areas in question (or if it's missing them, they could easily be added to a future version).

This comment has been minimized.

@philips

philips Sep 17, 2018

Contributor

@raesene That is a reasonable suggestion and referring to the CIS guide seems like the most expedient option.

It is important that we don't accidentally remove the ability to have people report issues with defaults in RBAC or service accounts, for example, which might be insecure.

@philips

philips Sep 17, 2018

Contributor

@raesene That is a reasonable suggestion and referring to the CIS guide seems like the most expedient option.

It is important that we don't accidentally remove the ability to have people report issues with defaults in RBAC or service accounts, for example, which might be insecure.

This comment has been minimized.

@liggitt

liggitt Sep 17, 2018

Member

referring to the CIS guide seems like the most expedient option

there are recommendations in the CIS guide I do not consider necessary ("disable anonymous auth on the apiserver") and some which make most production clusters non-functional ("disable the ability of kubelets to run privileged pods"). I'm not sure I'd endorse that as a foundational config guide

@liggitt

liggitt Sep 17, 2018

Member

referring to the CIS guide seems like the most expedient option

there are recommendations in the CIS guide I do not consider necessary ("disable anonymous auth on the apiserver") and some which make most production clusters non-functional ("disable the ability of kubelets to run privileged pods"). I'm not sure I'd endorse that as a foundational config guide

This comment has been minimized.

@raesene

raesene Sep 17, 2018

If the goal of this is to allow for findings that could relate to default configuration of a cluster (e.g. RBAC, Service accounts), then to be effective, it's got to provide a target. If that's not the CIS guide, then it needs to be some other concrete entity (e.g. Kubeadm), otherwise you're very likely to get people installing "kubernetes distro x" which has a poor security default and then it'll get reported to this bug bounty as a vuln. Also if there's non-ideal security settings that are considered necessary for a functional cluster (e.g use of privileged pods instead of specifying required capabilities etc), again that's going to be worth getting into the initial scope definition to avoid lots of "this cluster runs insecure pods because they use the root user and are privileged" style reports.

@raesene

raesene Sep 17, 2018

If the goal of this is to allow for findings that could relate to default configuration of a cluster (e.g. RBAC, Service accounts), then to be effective, it's got to provide a target. If that's not the CIS guide, then it needs to be some other concrete entity (e.g. Kubeadm), otherwise you're very likely to get people installing "kubernetes distro x" which has a poor security default and then it'll get reported to this bug bounty as a vuln. Also if there's non-ideal security settings that are considered necessary for a functional cluster (e.g use of privileged pods instead of specifying required capabilities etc), again that's going to be worth getting into the initial scope definition to avoid lots of "this cluster runs insecure pods because they use the root user and are privileged" style reports.

This comment has been minimized.

@liggitt

liggitt Sep 17, 2018

Member

I'm referring to specific infrastructure-level pods like kube-proxy that make use of privileged containers, like
https://github.com/kubernetes/kubernetes/blob/master/cluster/gce/manifests/kube-proxy.manifest (also set up by kubeadm this way, see
https://github.com/kubernetes/kubernetes/blob/master/cmd/kubeadm/app/phases/addons/proxy/manifests.go)

@liggitt

liggitt Sep 17, 2018

Member

I'm referring to specific infrastructure-level pods like kube-proxy that make use of privileged containers, like
https://github.com/kubernetes/kubernetes/blob/master/cluster/gce/manifests/kube-proxy.manifest (also set up by kubeadm this way, see
https://github.com/kubernetes/kubernetes/blob/master/cmd/kubeadm/app/phases/addons/proxy/manifests.go)

This comment has been minimized.

@raesene

raesene Sep 17, 2018

Sure I wasn't disagreeing that all clusters tend to do that, just suggesting that for bug bounty purposes, I'd generally recommend explicitly ruling out things which might seem like a dangerous thing to do (like running privileged containers), to avoid getting a load of bogus reports from security people who have "discovered" this flaw.

So for example if we use Kubeadm as the target for "Kubernetes Default configuration" in the bug bounty, I'd explicitly exclude the use of privileged containers in infrastructure level pods as a target for bounties. The clearer it can be the fewer bad reports you're likely to get.

@raesene

raesene Sep 17, 2018

Sure I wasn't disagreeing that all clusters tend to do that, just suggesting that for bug bounty purposes, I'd generally recommend explicitly ruling out things which might seem like a dangerous thing to do (like running privileged containers), to avoid getting a load of bogus reports from security people who have "discovered" this flaw.

So for example if we use Kubeadm as the target for "Kubernetes Default configuration" in the bug bounty, I'd explicitly exclude the use of privileged containers in infrastructure level pods as a target for bounties. The clearer it can be the fewer bad reports you're likely to get.

@k8s-ci-robot

This comment has been minimized.

Show comment
Hide comment
@k8s-ci-robot

k8s-ci-robot Sep 4, 2018

Contributor

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by:
To fully approve this pull request, please assign additional approvers.
We suggest the following additional approver: philips

If they are not already assigned, you can assign the PR to them by writing /assign @philips in a comment when ready.

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

Contributor

k8s-ci-robot commented Sep 4, 2018

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by:
To fully approve this pull request, please assign additional approvers.
We suggest the following additional approver: philips

If they are not already assigned, you can assign the PR to them by writing /assign @philips in a comment when ready.

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

Show outdated Hide outdated contributors/guide/bug-bounty.md
Show outdated Hide outdated contributors/guide/bug-bounty.md
Show outdated Hide outdated contributors/guide/bug-bounty.md
Show outdated Hide outdated contributors/guide/bug-bounty.md
The following items are explicitly out-of scope for the bug bounty program. While we still welcome
vulnerability reports in these areas, they are not (currently) eligible to receive a bounty.
- Alpha features & APIs

This comment has been minimized.

@tallclair

tallclair Sep 4, 2018

Member

done. We decided to include beta features, since they are enabled by default.

@tallclair

tallclair Sep 4, 2018

Member

done. We decided to include beta features, since they are enabled by default.

_Please report these through security@kernel.org_
- Attacks against containers from the host they are running on
- Attacks relying on insecure configurations, such as clusters not utilizing mutual authentication
or encryption between Kubernetes components.

This comment has been minimized.

@tallclair

tallclair Sep 4, 2018

Member

Yeah, this ate up a big portion of our meeting, but I don't think we landed on anything.

Anyone have suggestions? Or should we just remove it?

@tallclair

tallclair Sep 4, 2018

Member

Yeah, this ate up a big portion of our meeting, but I don't think we landed on anything.

Anyone have suggestions? Or should we just remove it?

@philips

This comment has been minimized.

Show comment
Hide comment
@philips

philips Sep 6, 2018

Contributor

/lgtm

Contributor

philips commented Sep 6, 2018

/lgtm

@k8s-ci-robot k8s-ci-robot added the lgtm label Sep 6, 2018

@jessfraz

This comment has been minimized.

Show comment
Hide comment
@jessfraz

jessfraz Sep 6, 2018

Contributor

/lgtm

Contributor

jessfraz commented Sep 6, 2018

/lgtm

vulnerability reports in these areas, they are not (currently) eligible to receive a bounty.
- Alpha features & APIs
- Kubernetes running on Windows or other non-linux operating systems

This comment has been minimized.

@mattfarina

mattfarina Sep 7, 2018

Member

Windows server containers are a beta feature IIRC. How does this relate to the earlier beta comment?

@mattfarina

mattfarina Sep 7, 2018

Member

Windows server containers are a beta feature IIRC. How does this relate to the earlier beta comment?

This comment has been minimized.

@philips

philips Sep 7, 2018

Contributor

@mattfarina it explicitly makes Windows server containers out of scope despite the beta status.

@philips

philips Sep 7, 2018

Contributor

@mattfarina it explicitly makes Windows server containers out of scope despite the beta status.

The following items are explicitly in-scope for the bug bounty program:
**Cluster Attacks:**

This comment has been minimized.

@dims

dims Sep 7, 2018

Member

@tallclair which category would CVE-2017–1002101 and CVE-2017–1002102 fall under in this list?

@dims

dims Sep 7, 2018

Member

@tallclair which category would CVE-2017–1002101 and CVE-2017–1002102 fall under in this list?

This comment has been minimized.

@philips

philips Sep 7, 2018

Contributor

Those CVEs are attacks on the filesystem. I agree we need to add something. How about:

  • Unexpected editing, removal, or permission changes of files on the host filesystems from Kubernetes components (e.g. kubelet)

https://nvd.nist.gov/vuln/detail/CVE-2017-1002101
https://nvd.nist.gov/vuln/detail/CVE-2017-1002102

@philips

philips Sep 7, 2018

Contributor

Those CVEs are attacks on the filesystem. I agree we need to add something. How about:

  • Unexpected editing, removal, or permission changes of files on the host filesystems from Kubernetes components (e.g. kubelet)

https://nvd.nist.gov/vuln/detail/CVE-2017-1002101
https://nvd.nist.gov/vuln/detail/CVE-2017-1002102

This comment has been minimized.

@dims

dims Sep 7, 2018

Member

+1 for that verbiage @philips we should probably check what other CVE(s) we had and cross check with the list here

@dims

dims Sep 7, 2018

Member

+1 for that verbiage @philips we should probably check what other CVE(s) we had and cross check with the list here

- Path traversal attacks in API, namespaces, etcd
- Info leak (e.g. workload names) from publicly accessible unauthenticated endpoints<br>
_Excluding intentionally disclosed info, such as Kubernetes version & enabled APIs_
- Reliable suppression of audit logs for privileged actions

This comment has been minimized.

@thockin

thockin Sep 10, 2018

Member

DoS attack from within a cluster (e.g. shared-infra overloads like DNS, endpoints)?

@thockin

thockin Sep 10, 2018

Member

DoS attack from within a cluster (e.g. shared-infra overloads like DNS, endpoints)?

- Alpha features & APIs
- Kubernetes running on Windows or other non-linux operating systems
- Non-Kubernetes binaries distributed as cluster addons<br>

This comment has been minimized.

@thockin

thockin Sep 10, 2018

Member

CoreDNS is now a default but is not a Kubernetes binary...

@thockin

thockin Sep 10, 2018

Member

CoreDNS is now a default but is not a Kubernetes binary...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment