From f3ce92be7b9e5504ee786cf94c3403dacc15149f Mon Sep 17 00:00:00 2001 From: John Hillegass Date: Mon, 14 Jun 2021 15:16:27 +0000 Subject: [PATCH] docs(cleanup): rename SIG to TAG --- .github/ISSUE_TEMPLATE/joint-review.md | 6 +- .github/ISSUE_TEMPLATE/presentation.md | 4 +- .github/ISSUE_TEMPLATE/proposal.md | 6 +- .github/workflows/sig-sec-check.yml | 2 +- CONTRIBUTING.md | 6 +- README.md | 24 +- assessments/README.md | 30 +- assessments/guide/README.md | 36 +- assessments/guide/joint-review.md | 90 ++--- assessments/guide/security-reviewer.md | 48 +-- assessments/guide/self-assessment.md | 14 +- assessments/intake-process.md | 24 +- .../projects/harbor/self-assessment.md | 30 +- assessments/projects/in-toto/README.md | 16 +- .../projects/keycloak/self-assessment.md | 232 ++++++------ assessments/projects/opa/self-assessment.md | 20 +- .../projects/spiffe-spire/self-assessment.md | 8 +- design/README.md | 18 +- governance/charter.md | 2 +- governance/cncf-projects.md | 2 +- governance/github.md | 16 +- governance/paper-process.md | 14 +- governance/presentations.md | 10 +- governance/process.md | 4 +- governance/roles.md | 28 +- landscape/README.md | 2 +- past-events.md | 62 ++-- policy/overview-policy-formal-verification.md | 346 +++++++++--------- roadmap.md | 56 +-- security-whitepaper/README.md | 34 +- ...-security-whitepaper-simplified-chinese.md | 6 +- .../cloud-native-security-whitepaper.md | 26 +- slack.md | 16 +- supply-chain-security/compromises/README.md | 16 +- 34 files changed, 627 insertions(+), 627 deletions(-) diff --git a/.github/ISSUE_TEMPLATE/joint-review.md b/.github/ISSUE_TEMPLATE/joint-review.md index 77d8458ec..adadda166 100644 --- a/.github/ISSUE_TEMPLATE/joint-review.md +++ b/.github/ISSUE_TEMPLATE/joint-review.md @@ -7,11 +7,11 @@ assignees: '' --- -Project Name: +Project Name: Github URL: - @@ -27,7 +27,7 @@ Security Provider: yes/no (e.g. Is the primary function of the project to suppor - [ ] Sign off by 2 chairs on reviewer conflicts - [ ] Create slack channel (e.g. #sec-assess-projectname) - [ ] Project lead provides draft document - see [outline](https://github.com/cncf/tag-security/blob/main/assessments/guide/joint-review.md) -- [ ] "Naive question phase" Lead Security Reviewer asks clarifying questions +- [ ] "Naive question phase" Lead Security Reviewer asks clarifying questions - [ ] Assign issue to security reviewers - [ ] Initial review - [ ] Presentation & discussion diff --git a/.github/ISSUE_TEMPLATE/presentation.md b/.github/ISSUE_TEMPLATE/presentation.md index 07a76f6a9..640792a0a 100644 --- a/.github/ISSUE_TEMPLATE/presentation.md +++ b/.github/ISSUE_TEMPLATE/presentation.md @@ -1,6 +1,6 @@ --- name: Presentation -about: Have something you want to share with the group? Or someone you would like to invite to speak? Propose a presentation for the SIG-Security weekly meetings. +about: Have something you want to share with the group? Or someone you would like to invite to speak? Propose a presentation for the TAG-Security weekly meetings. title: "[Presentation] Presentation Title" labels: "usecase-presentation, triage-required" assignees: '' @@ -14,7 +14,7 @@ Description: Describe in a short paragraph what the presentation is about. Time: How long will the presentation take? (estimate) -Availability: What is the availability times of the speakers to present the topic? Meeting times are listed on the landing page. +Availability: What is the availability times of the speakers to present the topic? Meeting times are listed on the landing page. TO DO - [ ] TAG Representative diff --git a/.github/ISSUE_TEMPLATE/proposal.md b/.github/ISSUE_TEMPLATE/proposal.md index 8303e238e..e3d63b379 100644 --- a/.github/ISSUE_TEMPLATE/proposal.md +++ b/.github/ISSUE_TEMPLATE/proposal.md @@ -7,13 +7,13 @@ assignees: '' --- -Description: what's your idea? +Description: what's your idea? Impact: Describe the customer impact of the problem. Who will this help? How will it help them? -Scope: How much effort will this take? ok to provide a range of options if or "not yet determined" for initial proposals. Feel free to include proposed tasks below or link a Google doc +Scope: How much effort will this take? ok to provide a range of options if or "not yet determined" for initial proposals. Feel free to include proposed tasks below or link a Google doc TO DO -- [ ] SIG Representative +- [ ] TAG Representative - [ ] Project leader(s) - [ ] TBD diff --git a/.github/workflows/sig-sec-check.yml b/.github/workflows/sig-sec-check.yml index abcb40766..3b7ef8e62 100644 --- a/.github/workflows/sig-sec-check.yml +++ b/.github/workflows/sig-sec-check.yml @@ -1,5 +1,5 @@ --- -name: SIG-Security-Linter +name: TAG-Security-Linter # Run this workflow on every PR to master on: diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 0c3145f8c..7a52580ea 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -35,9 +35,9 @@ review/comment. A favorable review is determined by the contents of the PR complying with the contributing guide, the writing style, and agreement the contents align with the -SIG's goals, objectives, and scope. It is anticipated that PRs submitted, with +TAG's goals, objectives, and scope. It is anticipated that PRs submitted, with the exception of spelling and grammar changes, have been discussed with members -of the SIG via slack or issues. +of the TAG via slack or issues. ##### Nits @@ -99,7 +99,7 @@ merging party. ### Merging pull requiests -PRs may be merged after at least one review as occurred, dependent on the type of changes reflected in the PR. The merging party needs to verify a review has occurred, the PR is in alignment with this guide, and is in scope of the SIG. +PRs may be merged after at least one review as occurred, dependent on the type of changes reflected in the PR. The merging party needs to verify a review has occurred, the PR is in alignment with this guide, and is in scope of the TAG. ### Writing style diff --git a/README.md b/README.md index 9bd24c761..25465adc5 100644 --- a/README.md +++ b/README.md @@ -13,8 +13,8 @@ ## Objective -STAG facilitates collaboration to discover and produce resources that enable -secure access, policy control, and safety for operators, administrators, +STAG facilitates collaboration to discover and produce resources that enable +secure access, policy control, and safety for operators, administrators, developers, and end-users across the cloud native ecosystem. @@ -46,14 +46,14 @@ security of the system, such as auditing and explainability features. # Governance -[STAG charter](governance/charter.md) outlines the scope of our group activities, +[STAG charter](governance/charter.md) outlines the scope of our group activities, as part of our [governance process](governance) which details how we work. ## Communications -Anyone is welcome to join our open discussions of STAG projects and share news -related to the group's mission and charter. Much of the work of the group happens -outside of Security TAG meetings and we encourage project teams to share progress +Anyone is welcome to join our open discussions of STAG projects and share news +related to the group's mission and charter. Much of the work of the group happens +outside of Security TAG meetings and we encourage project teams to share progress updates or post questions in these channels: Group communication: @@ -101,8 +101,8 @@ Meeting ID: 737 567 7271 ## Gatherings -Please let us know if you are going and if you are interested in attending (or -helping to organize!) a gathering. Create a [github issue](https://github.com/cncf/tag-security/issues/new) for an event +Please let us know if you are going and if you are interested in attending (or +helping to organize!) a gathering. Create a [github issue](https://github.com/cncf/tag-security/issues/new) for an event and add to list below: @@ -117,13 +117,13 @@ If you are new to the group, check out our [New Members Page](NEWMEMBERS.md) and ## Related groups * [Kubernetes Policy Working Group](https://github.com/kubernetes/community/tree/master/wg-policy) -* [Kubernetes SIG-Auth](https://github.com/kubernetes/community/tree/master/sig-auth) +* [Kubernetes TAG-Auth](https://github.com/kubernetes/community/tree/master/tag-auth) * [NIST Big Data WG](https://bigdatawg.nist.gov/) ## History -* SIG-Security - renamed STAG ([TOC Issue #549](https://github.com/cncf/toc/issues/549)) -* SAFE WG - renamed to CNCF Security SIG +* TAG-Security - renamed STAG ([TOC Issue #549](https://github.com/cncf/toc/issues/549)) +* SAFE WG - renamed to CNCF Security TAG * [(Proposed) CNCF Policy Working Group](/policy-wg-merging.md) - Merged into SAFE WG ## Members @@ -230,7 +230,7 @@ Membership governance can be viewed [here](https://github.com/cncf/tag-security/ * Ricardo Aravena ([@raravena80](https://github.com/raravena80)), Rakuten * Lakshmi Manohar Velicheti ([@manohar9999](https://github.com/manohar9999)), Shape Security * Andres Vega ([@anvega](https://github.com/anvega)), Scytale.io -* Cameron Seader ([@cseader](https://github.com/cseader)), SUSE +* Cameron Seader ([@cseader](https://github.com/cseader)), SUSE * Robert Ficcaglia ([@rficcaglia](https://github.com/rficcaglia)), Policy WG * Matthew Giassa ([@iaxes](https://github.com/IAXES)) * Tabitha Sable ([@tabbysable](https://github.com/tabbysable)) diff --git a/assessments/README.md b/assessments/README.md index c78b818fd..33188d57f 100644 --- a/assessments/README.md +++ b/assessments/README.md @@ -55,7 +55,7 @@ subsume the need for a professional security audit of the code*. Audits of implementation-specific vulnerabilities, improper deployment configurations, etc. are not in scope of a security review. A security review is intended to uncover design flaws, enhance the security mindset of the project, and to obtain -a clear, comprehensive articulation of the project's design goals and +a clear, comprehensive articulation of the project's design goals and aspirations while documenting the intended security properties enforced, fulfilled, or executed by said project. @@ -76,7 +76,7 @@ Security reviews have many benefits, creating: A complete security review package primarily consists of the following items: * [Self-assessment](guide/self-assessment.md). A written assessment by the project -of the project's current security statue. +of the project's current security statue. * [Joint-review](guide/joint-review.md). A joint review by both the [security reviewers](guide/security-reviewer.md) and the project team that includes parts of the self-assessment and expands to include a more comprehensive consideration @@ -98,29 +98,29 @@ security of the project, not a security audit of the project, and do not relieve an individual or organization from performing their own due diligence and complying with laws, regulations, and policies. -Draft assessments contain *unconfirmed* content and are not endorsed as factual -until committed to this repository, which requires detailed peer review. Draft -reviews may also contain *speculative* content as the project lead or security -reviewer is performing a review. Draft reviews are *only* for the purpose -of preparing final artifact and are **not** to be used in any other capacity by +Draft assessments contain *unconfirmed* content and are not endorsed as factual +until committed to this repository, which requires detailed peer review. Draft +reviews may also contain *speculative* content as the project lead or security +reviewer is performing a review. Draft reviews are *only* for the purpose +of preparing final artifact and are **not** to be used in any other capacity by the community. -Final slides resulting from the presentation and the project's joint review -will be stored in the individual project's review folder with supporting +Final slides resulting from the presentation and the project's joint review +will be stored in the individual project's review folder with supporting documentation and artifacts from the review. These folders can be found under [assessments/projects](projects/) and clicking on the project name. ## Process -Creating the security review package is a collaborative process for the -benefit of the project and the community, where the primary content is generated -by the [project lead](guide/project-lead.md) and revised based on feedback from [security reviewers](guide/security-reviewer.md) -and other members of the SIG. +Creating the security review package is a collaborative process for the +benefit of the project and the community, where the primary content is generated +by the [project lead](guide/project-lead.md) and revised based on feedback from [security reviewers](guide/security-reviewer.md) +and other members of the TAG. * If you are interested in a security review for your project and you are willing to volunteer as [project lead](guide/project-lead.md) or you are a - SIG-Security member and want to recommend a project to review, please [file an - issue](https://github.com/cncf/sig-security/issues/new?template=joint-review.md) + TAG-Security member and want to recommend a project to review, please [file an + issue](https://github.com/cncf/tag-security/issues/new?template=joint-review.md) See [security review guide](guide) for more details. To understand how we prioritize reviews, see [intake process](./intake-process.md). diff --git a/assessments/guide/README.md b/assessments/guide/README.md index 29a79baec..becbd5040 100644 --- a/assessments/guide/README.md +++ b/assessments/guide/README.md @@ -46,9 +46,9 @@ The self-assessment provides projects with the opportunity to examine the existing security provisions of the project. It can serve as their initial security documentation for users. -#### Create a [presentation issue](https://github.com/cncf/sig-security/issues/new?assignees=&labels=usecase-presentation&template=presentation.md&title=%5BPresentation%5D+Presentation+Title) +#### Create a [presentation issue](https://github.com/cncf/tag-security/issues/new?assignees=&labels=usecase-presentation&template=presentation.md&title=%5BPresentation%5D+Presentation+Title) -This presentation should go over the self-assessment and provide SIG-Security +This presentation should go over the self-assessment and provide TAG-Security with an initial understanding of the project. It is recommended the **project lead** submit the issue as the primary point of contact (POC). @@ -62,8 +62,8 @@ updated self-assessment based on feedback and discussion. #### Submit a PR to include the self-assessment in the repo -After the presentation, the **project lead** or their designee should submit a PR, -citing the presentation issue number to add the self-assessment to [assessments/projects](https://github.com/cncf/tag-security/tree/main/assessments/projects) under its +After the presentation, the **project lead** or their designee should submit a PR, +citing the presentation issue number to add the self-assessment to [assessments/projects](https://github.com/cncf/tag-security/tree/main/assessments/projects) under its own folder. The ticket may then be closed after merged in. ### Growing projects @@ -77,10 +77,10 @@ to start with the self-assessment before pursing joint review. #### [Create tracking issue](https://github.com/cncf/tag-security/issues/new?assignees=&labels=assessment&template=security-assessment.md&title=%5BAssessment%5D+Project+Name) The tracking issue serves to initiate the joint-reviews. It provides - an initial set of information to assist SIG-Security in prioritizing the + an initial set of information to assist TAG-Security in prioritizing the joint review as well as provide potential reviewers with a central location to manage the effort. - * Issue may be a request from **TOC liason** or **project** itself + * Issue may be a request from **TOC liason** or **project** itself * [**Security review facilitator**](https://github.com/cncf/tag-security/blob/main/governance/roles.md#facilitation-roles) with help from the **technical leads** and **co-chairs** if appropriate, will determine if the project is ready for joint-review. If ready, a channel will be created to coordinate the @@ -93,18 +93,18 @@ joint review. The joint review expands upon content of the self-assessment and provides the **reviewers** with a central starting point in reviewing the current security stature of the project. -#### Project provides the joint review and reviewers are assigned +#### Project provides the joint review and reviewers are assigned The project provides the reviewers with security relevant information about their project. The joint review can include links to external documents and sources - within the project's repository or website to provide additional details or + within the project's repository or website to provide additional details or reference where a process is kept. * **[Project lead](project-lead.md)** responds to the issue with draft document (see [joint review](joint-review.md)) * Issue assigned to **lead [security reviewer](security-reviewer.md)** who will recruit at least one additional reviewer, if one is not already assigned, and facilitate the process. - + #### Conflict of interest statement and review In order to remediate unfair advantage or ethical issues all reviewers are @@ -148,7 +148,7 @@ prior to the *3 week* timeframe for reviews. * Ask for clarifications * Ensure terms are defined * Ensure concepts introduced are explained with context - * Provide quick feedback + * Provide quick feedback #### Security review with optional hands-on review @@ -167,20 +167,20 @@ review, the hands-on review is included in this step. with the project's repo and docs if available * **Security reviewers and project lead/pocs** ensure all reviewer questions, comments, and feedback are addressed and finalize the joint review - * **Lead security reviewer or their designee,** with the assistance of the -**security reviewers** create a [draft summary document](joint-readme-template.md) to capture existing + * **Lead security reviewer or their designee,** with the assistance of the +**security reviewers** create a [draft summary document](joint-readme-template.md) to capture existing comments, feedback, and recommendations prior to the presentation. #### Presentation -The presentation is designed to inform members of SIG Security of the project, +The presentation is designed to inform members of TAG Security of the project, its intent, what it accomplishes, and provides the opportunity for additional questions and feedback to the reviewers and project. - * Project lead presents to SIG during SIG meeting - * Presentation is recorded as part of standard SIG process + * Project lead presents to TAG during TAG meeting + * Presentation is recorded as part of standard TAG process * Presentation slides are linked in the /assessments/projects/project-name/ -#### Final summary +#### Final summary The final summary provides a cursory review of the project, background, summary of the joint review, and recommendations to the CNCF, the project, @@ -196,7 +196,7 @@ of the review. * **Project lead** prepares a PR to /assessments/projects/project-name/ when all comments, feedback, and recommendations are incorporated for the joint review and presentation slides. - * PR approval of at least 1 **co-chair**, alongside other **reviewers'** + * PR approval of at least 1 **co-chair**, alongside other **reviewers'** approvals, is required before merging any artifacts. #### [Post-review survey](review-survey.md) @@ -217,4 +217,4 @@ reviewers: feedback from security reviewers * Project lead or lead security reviewer may pause the process where a delay of over a week cannot be accommodated by the review team. Simply close the github -issue with a note to SIG co-chairs. +issue with a note to TAG co-chairs. diff --git a/assessments/guide/joint-review.md b/assessments/guide/joint-review.md index e6ce48cd2..6eb7f3555 100644 --- a/assessments/guide/joint-review.md +++ b/assessments/guide/joint-review.md @@ -1,7 +1,7 @@ # Joint-review Outline The joint-review is built on top of the [self-assessment](self-assessment.md) to -collaboratively review the current security state of a project. +collaboratively review the current security state of a project. The burden is primarily on the proposing project to demonstrate it is secure in a manner that is understandable to the broader community. The @@ -10,7 +10,7 @@ a manner that is understandable to the broader community. The The proposing project must provide a written document that describes the project and its security. The document must contain the following information, at a minimum. Where security considerations do not fit into the outline below, if -possible, add a sub-section such that the additional content conforms to the general +possible, add a sub-section such that the additional content conforms to the general flow of the review. Projects are encouraged to cross link additional supporting documents or details @@ -48,7 +48,7 @@ A table at the top for quick reference information, later used for indexing. | | | | -- | -- | | Software | A link to the software’s repository. | -| Security Provider | Yes or No. Is the primary function of the project to support the +| Security Provider | Yes or No. Is the primary function of the project to support the security of an integrating system? | | Languages | languages the project is written in | | SBOM | Software bill of materials. Link to the libraries, packages, versions used by @@ -68,39 +68,39 @@ use the table below as an example: ## Overview This section can be pulled from the [self-assessment](self-assessment.md) and updated. - + One or two sentences describing the project -- something memorable and accurate that distinguishes your project to quickly orient readers who may be reviewing multiple projects. -### Background +### Background -Provide information for reviewers who may not be familiar with your project's +Provide information for reviewers who may not be familiar with your project's domain or problem area. -### Goal +### Goal -The intended goal of the project, it should also include the security guarantees the project -is meant to provide (e.g., Flibble only allows parties with an authorization key +The intended goal of the project, it should also include the security guarantees the project +is meant to provide (e.g., Flibble only allows parties with an authorization key to change data it stores). -### Non-goals -Non-goals that a reasonable reader of the project’s literature could believe may -be in scope (e.g., Flibble does not intend to stop a party with a key from storing -an arbitrarily large amount of data, possibly incurring financial cost or +### Non-goals +Non-goals that a reasonable reader of the project’s literature could believe may +be in scope (e.g., Flibble does not intend to stop a party with a key from storing +an arbitrarily large amount of data, possibly incurring financial cost or overwhelming the servers) ## Joint-review use The joint-review is initially created by the project team and then collaboratively developed with the [security reviewers](security-reviewer.md) as part of the project's -SIG-Security Review (formerly called security assessment). Information about the -SIG-Security Review can be found in the [CNCF SIG-Security Review Process Guide](./README.md). +TAG-Security Review (formerly called security assessment). Information about the +TAG-Security Review can be found in the [CNCF TAG-Security Review Process Guide](./README.md). This document does not intend to provide a security audit of [project] and is not intended to be used in lieu of a security audit. This document provides users of [project] with a security focused understanding of [project] and when taken with the -[self-assessment](self-assessment.md) provide the community with the SIG-Security +[self-assessment](self-assessment.md) provide the community with the TAG-Security Review of the project. Both of these documents may be used and references as part of a security audit. @@ -171,61 +171,61 @@ If any audits already exist, link them here with the appropriate dates. ## Security Analysis -### Attacker Motivations +### Attacker Motivations A discussion about the likely goals of an attacker as well as the kind of attacker - (do not forget to include discussion of insider threat with trusted access to the -project). This likely relates closely to the impact of different attacks in the -scenarios. (e.g., In the password hash case, the attacker wants to expose those -hashes on the Flibble server. However, a Flibble cloudlet attacker may find it more + (do not forget to include discussion of insider threat with trusted access to the +project). This likely relates closely to the impact of different attacks in the +scenarios. (e.g., In the password hash case, the attacker wants to expose those +hashes on the Flibble server. However, a Flibble cloudlet attacker may find it more interesting to bring down the service.) ### Predisposing Conditions -A list of potential vulnerabilities and configurations of the project that could -potentially be exploited or used correctly to result in an increased likelihood of -attack success. Include any trust relationships with other projects that pose a risk +A list of potential vulnerabilities and configurations of the project that could +potentially be exploited or used correctly to result in an increased likelihood of +attack success. Include any trust relationships with other projects that pose a risk of compromise for this project (i.e. compromise of the LDAP results in loss of access control integrity for the project) ### Expected Attacker Capabilities -A description of likely capabilities that the attacker has in these scenarios +A description of likely capabilities that the attacker has in these scenarios should be described. Both assumptions about the strength and limitations of attackers - should be described (e.g., We assume that an attacker may be able to exploit -implementation errors in some set of the servers to take control of them. However, + should be described (e.g., We assume that an attacker may be able to exploit +implementation errors in some set of the servers to take control of them. However, we assume the attacker cannot break AES or SHA256.) ### Attack Risks and Effects -A rough estimation of the risk posed by different attacks, and potential negative +A rough estimation of the risk posed by different attacks, and potential negative consequences (e.g., The master Flibble server only communicates with Flibble servers using a minimalistic API that is formally verified and written in Rust.) ### Security Degradation -A discussion about the resulting security when various attacks are launched. Note, +A discussion about the resulting security when various attacks are launched. Note, that no system is secure in all scenarios, hence it is expected that this will include areas where attacks compromise all meaningful security. (e.g., If an attacker is - able to compromise the “main” Flibble server, they may read, write, or delete any -content stored on any system). This should be stated in terms that are accessible to + able to compromise the “main” Flibble server, they may read, write, or delete any +content stored on any system). This should be stated in terms that are accessible to a reader that does not fully understand the system. Hence, "a compromised main Flibble - key lets and attacker push and pull widgets" is less useful than saying " compromised + key lets and attacker push and pull widgets" is less useful than saying " compromised main Flibble key lets an attacker execute arbitrary code on client machines using the Flibble server". ### Compensating Mechanisms -Additional architectural decisions, configuration settings, options, etc. designed to -reduce overall attack vector and success (minimize impact). Particular detail should -be paid to mechanisms that contain an attack (separation of privilege) and the -techniques used to recover from a successful attack. It is important to have clear +Additional architectural decisions, configuration settings, options, etc. designed to +reduce overall attack vector and success (minimize impact). Particular detail should +be paid to mechanisms that contain an attack (separation of privilege) and the +techniques used to recover from a successful attack. It is important to have clear documentation that explains what types of security incidents are likely to occur and what means should be undertaken to securely recover. I.e., in the case of a Flibble server compromise, a threshold of the offline Flibble keys must be used in order to sign new - Flibble metadata to revoke the older server key. This new metadata should be + Flibble metadata to revoke the older server key. This new metadata should be distributed to clients using the Flibble widget create operation as soon as is feasible - as in the interim clients will tryst the compromised server, enabling an attacker to + as in the interim clients will tryst the compromised server, enabling an attacker to serve them outdated widgets that are known to be defective. ## Threat Model @@ -261,7 +261,7 @@ This should be pulled in from the self-assessment. ### Closed security issues and vulnerabilities This should provide links and very brief summary of any closed security issues - or fixed vulnerabilities for the project (with or without CVE). If the + or fixed vulnerabilities for the project (with or without CVE). If the project does not have any closed or fixed vulnerabilities use the below text: > At the time of the joint review, [project] did not have known security issues with a closed state or any known vulnerabilities that were fixed. @@ -270,13 +270,13 @@ project does not have any closed or fixed vulnerabilities use the below text: The hands-review is a lightweight review of the project's internal security as well as the current recommendation configuration, deployment, and interaction -with regard to security. Hands-on reviews are subject to security reviewer -availability and expertise. They are not intended to serve as an audit or +with regard to security. Hands-on reviews are subject to security reviewer +availability and expertise. They are not intended to serve as an audit or formal assessment and are no gurantee of the actual security of the project. -**[Project] did/did not receive a hands-review from SIG-Security.** +**[Project] did/did not receive a hands-review from TAG-Security.** -*If a hands-on review was performed, the below format should be used for +*If a hands-on review was performed, the below format should be used for reporting details* | | | @@ -285,7 +285,7 @@ reporting details* | Hands-on reviewers | name, github handle | | Finding Number | Finding name | Finding Notes | Reviewer | -| -- | -- | -- | -- | +| -- | -- | -- | -- | | | | | ### Hands-on review result @@ -293,7 +293,7 @@ reporting details* General comments and summary of the hands-on review with any recommendations worth noting. If nothing found use the below example: -> SIG-Security's hands-on review did not reveal any significant or notable security findings for [project]. This outcome does not indicate that none exist, rather that none were discovered. +> TAG-Security's hands-on review did not reveal any significant or notable security findings for [project]. This outcome does not indicate that none exist, rather that none were discovered. ## Roadmap diff --git a/assessments/guide/security-reviewer.md b/assessments/guide/security-reviewer.md index 1fe52972f..0e28ef8f3 100644 --- a/assessments/guide/security-reviewer.md +++ b/assessments/guide/security-reviewer.md @@ -34,7 +34,7 @@ the security of the project. A reviewer may be delegated to perform specific tasks by the lead security reviewer in order to ensure the appropriate experience is leveraged in conducting -the activity. This may include but is not limited to the clarifying +the activity. This may include but is not limited to the clarifying questions phase. Reviewers are encouraged to reach out to community members to resolve @@ -43,31 +43,31 @@ of attacks. ### Hands-on reviews -If the reviewers have the skills and interest, they may perform a -lightweight hands-on review of the project. Reviewers wishing to do this in +If the reviewers have the skills and interest, they may perform a +lightweight hands-on review of the project. Reviewers wishing to do this in addition to their normal reviewing requirements should locally poke and explore -the project to understand its inner workings. +the project to understand its inner workings. If a reviewer performing a hands-on review discovers a weakness or vulnerability -they are required to adhere to the project's responsible disclosure process. +they are required to adhere to the project's responsible disclosure process. If no process is documented, they must contact the [project lead](project-lead.md) directly regarding the issue, they may notify the lead security reviewer that they have -notified the project of an issue as it may impact the content of the joint +notified the project of an issue as it may impact the content of the joint review or the timeframe for completing the review. -Engaging in a hands-on review is not an authorization to attack an operational -system. All hands-on testing must be performed locally/within the control +Engaging in a hands-on review is not an authorization to attack an operational +system. All hands-on testing must be performed locally/within the control of the reviewer and with authorization. ## Qualifications -### Required +### Required -Unless approved by SIG-Security chairs, the lead reviewer will have previously -performed a CNCF security review. Exemptions to this are reviewed case by -case upon established need by the CNCF SIG-Security chairs in order to bootstrap -the process as appropriate. If a lead reviewer has not previously performed a -security review, and the chairs concur with them fulfilling the role, it is +Unless approved by TAG-Security chairs, the lead reviewer will have previously +performed a CNCF security review. Exemptions to this are reviewed case by +case upon established need by the CNCF TAG-Security chairs in order to bootstrap +the process as appropriate. If a lead reviewer has not previously performed a +security review, and the chairs concur with them fulfilling the role, it is encouraged that at least 1 additional reviewer have experience and be leveraged as the delegate or designee by the lead. @@ -79,7 +79,7 @@ ideal reviewer should also have been the recipient of CNCF project security reviews for a software project they manage. Reviewers interested in performing hands-on review should have experience in this -area. +area. Note: Participation through shadowing is encouraged from members who are not qualified for security reviews, to facilitate their development of the necessary @@ -114,13 +114,13 @@ of the community. Having clear guidelines for conflict of interest situations are important to prevent: - Individuals from intentionally or unintentionally promoting their own company's project -- SIG-Security chairs and review leads intentionally or +- TAG-Security chairs and review leads intentionally or unintentionally limiting the participation of an individual unfairly by asserting conflict of interest - Security reviews being stalled while groups belabor on who should be allowed to participate -The conflicts of interest lie on a spectrum, and are classified into hard and +The conflicts of interest lie on a spectrum, and are classified into hard and soft conflicts: * A hard conflict makes a reviewer ineligible to review a project. * A soft conflict allows a reviewer to review a project, but not as a @@ -130,9 +130,9 @@ reviewers that are familiar with a project can provide a deeper insight together with a fresh set of eyes and is beneficial to the success of a security review. -All reviewers must provide a conflict declaration on the tracking issue to +All reviewers must provide a conflict declaration on the tracking issue to indicate which hard or soft conflicts do, or do not exist when they volunteer -to be a reviewer. This is done by placing a comment on the issue associated +to be a reviewer. This is done by placing a comment on the issue associated with the joint review using the table provided below. #### Conflict of interest statement template: @@ -154,7 +154,7 @@ with the joint review using the table provided below. ### Managing conflicts Should a conflict arise during the time of the assessment, reviewers should notify -the lead security reviewer when they become aware of the potential conflict, +the lead security reviewer when they become aware of the potential conflict, so the new conflict may be consulted with the facilitator and/or chairs. ## Asserting team readiness to conduct a balanced review @@ -174,17 +174,17 @@ and as part of that before kicking off the review must: Update the above assertion if a new conflict-of-interest becomes known during the course of the review. -The Security Review Facilitator or a SIG-Security chair must review the +The Security Review Facilitator or a TAG-Security chair must review the Lead Security Reviewer conflict-of-interest assertion. If any hard conflicts, or multiple significant soft conflicts, are presented, -then a SIG-Security chair must approve the security review team. Reasons for +then a TAG-Security chair must approve the security review team. Reasons for accepting and rejecting conflicts should be documented. -In most cases, the existence of a hard conflict will prevent a SIG member from +In most cases, the existence of a hard conflict will prevent a TAG member from participating in the review for which their hard conflict exists. Depending on the circumstances of the particular conflict, the joint review, and the project, - two chairs and the review facilitator may determine if the hard conflict + two chairs and the review facilitator may determine if the hard conflict may be waived. Should this occur, the decision's justification will be documented to ensure it clearly depicts the circumstances for granting the waiver. diff --git a/assessments/guide/self-assessment.md b/assessments/guide/self-assessment.md index 7b241e890..164991405 100644 --- a/assessments/guide/self-assessment.md +++ b/assessments/guide/self-assessment.md @@ -51,17 +51,17 @@ multiple projects. ### Background -Provide information for reviewers who may not be familiar with your project's +Provide information for reviewers who may not be familiar with your project's domain or problem area. ### Goal The intended goal of the projects including the security guarantees the project - is meant to provide (e.g., Flibble only allows parties with an authorization + is meant to provide (e.g., Flibble only allows parties with an authorization key to change data it stores). ### Non-goals -Non-goals that a reasonable reader of the project’s literature could believe may -be in scope (e.g., Flibble does not intend to stop a party with a key from storing +Non-goals that a reasonable reader of the project’s literature could believe may +be in scope (e.g., Flibble does not intend to stop a party with a key from storing an arbitrarily large amount of data, possibly incurring financial cost or overwhelming the servers) @@ -76,15 +76,15 @@ This document serves to provide [project] users with an initial understanding of security, and general overview of [project] security practices, both for development of [project] as well as security of [project]. -This document provides the CNCF SIG-Security with an initial understanding of [project] +This document provides the CNCF TAG-Security with an initial understanding of [project] to assist in a joint-review, necessary for projects under incubation. Taken together, this document and the joint-review serve as a cornerstone for if and when [project] seeks graduation and is preparing for a security audit. ## Security functions and features -* Critical. A listing critical security components of the project with a brief -description of their importance. It is recommended these be used for threat modeling. +* Critical. A listing critical security components of the project with a brief +description of their importance. It is recommended these be used for threat modeling. These are considered critical design elements that make the product itself secure and are not configurable. Projects are encouraged to track these as primary impact items for changes to the project. diff --git a/assessments/intake-process.md b/assessments/intake-process.md index 3c521debd..1b933b9d9 100644 --- a/assessments/intake-process.md +++ b/assessments/intake-process.md @@ -1,7 +1,7 @@ # Security Assessment Priorities & Pipeline Intake Process -SIG-Security has a volunteer team of subject matter experts and industry -professionals dedicated to helping SIG-Security members, the TOC, and the larger +TAG-Security has a volunteer team of subject matter experts and industry +professionals dedicated to helping TAG-Security members, the TOC, and the larger CNCF community maintain an understanding of the current state of security in the cloud native ecosystem and helping cloud native projects succeed. @@ -24,7 +24,7 @@ coordinate the decision-making process. responsible for liaising with the TOC: aligning prioritization with TOC needs and goals by finding opportunities to highlight work of Security Assessment team, resolving questions/concerns about prioritization, and serving as an - escalation point for projects or SIG members, if needed. + escalation point for projects or TAG members, if needed. # Pre-conditions @@ -45,25 +45,25 @@ assessment, exceeding the bandwidth of the group: 2. Projects that have received a CNCF Security Audit will be reviewed within a year of audit. (For future audits, the security assessment will be a pre-condition to the audit.) -3. CNCF Projects that request a review (or invited by SIG members), prioritized +3. CNCF Projects that request a review (or invited by TAG members), prioritized by project maturity (e.g. graduated projects will be highest priority, then incubated projects, then sandbox). -4. Non-CNCF Projects that request a review (or invited by SIG members). +4. Non-CNCF Projects that request a review (or invited by TAG members). The Security Assessment Facilitator, in collaboration with the named chair, has the discretion to adjust priority in order to streamline the process, or per -their own judgement for other reasons consistent with SIG-Security mission and +their own judgement for other reasons consistent with TAG-Security mission and charter. In all cases, the priority queue will be maintained transparently as described below, along with communication via regular chair-liaison meetings and -SIG-Security reports at TOC meetings. +TAG-Security reports at TOC meetings. -A project may be accepted into the assessment queue, either by the Security Assessment -Facilitator with concurrence from one (1) co-chair, or by two (2) co-chairs. This concurrence +A project may be accepted into the assessment queue, either by the Security Assessment +Facilitator with concurrence from one (1) co-chair, or by two (2) co-chairs. This concurrence is given by commenting on an issue proposing that the project be added to the assessment queue. If at any time, the project requesting review ceases communicating, the Security Assessment Facilitator may remove the project from the queue with notification to the co-chairs. The Security Assessment Facilitator will update -the corresponding issue, prior to closing the project's request. +the corresponding issue, prior to closing the project's request. # Updates and renewal @@ -84,9 +84,9 @@ relevant github issue). Each assessment is represented as a github issue, where the description field follows a [template](/.github/ISSUE_TEMPLATE/joint-review.md) -The queue is visible through [github project](https://github.com/cncf/sig-security/projects/2) +The queue is visible through [github project](https://github.com/cncf/tag-security/projects/2) -* Anyone may propose a project for assessment, by opening an [issue](https://github.com/cncf/sig-security/issues/new?assignees=&labels=assessment&template=security-assessment.md&title=%5BAssessment%5D+Project+Name) +* Anyone may propose a project for assessment, by opening an [issue](https://github.com/cncf/tag-security/issues/new?assignees=&labels=assessment&template=security-assessment.md&title=%5BAssessment%5D+Project+Name) * Security Assessment Facilitator or their delegate may: * move the order of an assessment in the backlog * close an issue (with an explanation) to remove a project from the queue. diff --git a/assessments/projects/harbor/self-assessment.md b/assessments/projects/harbor/self-assessment.md index 2eb214377..332388807 100644 --- a/assessments/projects/harbor/self-assessment.md +++ b/assessments/projects/harbor/self-assessment.md @@ -1,12 +1,12 @@ -# CNCF SIG-Security Harbor Project Self Assessment -*March 2020* -*Primary Author: Michael Michael, Harbor Maintainer ([@michmike](https://github.com/michmike), [@michmike77](https://twitter.com/michmike77))* +# CNCF TAG-Security Harbor Project Self Assessment +*March 2020* +*Primary Author: Michael Michael, Harbor Maintainer ([@michmike](https://github.com/michmike), [@michmike77](https://twitter.com/michmike77))* *Security Reviewers: Andres Vega, Justin Cappos, Chase Pettet, Vinay Venkataraghavan, Robert Ficaglia, Martin Vrachev, Payam Tarverdyan Chychi, Cameron Seader.* -This document details the design goals and security implications of Harbor to aid in the security assessment by CNCF SIG-Security. +This document details the design goals and security implications of Harbor to aid in the security assessment by CNCF TAG-Security. -- [CNCF SIG-Security Harbor Project Self Assessment](#cncf-sig-securityharbor-project-self-assessment) +- [CNCF TAG-Security Harbor Project Self Assessment](#cncf-tag-securityharbor-project-self-assessment) - [Metadata](#metadata) - [Overview](#overview) - [Background](#background) @@ -80,15 +80,15 @@ This document details the design goals and security implications of Harbor to ai @@ -582,7 +582,7 @@ Type? x.509 TLS certificate - This cert (used by notary-signer) is generated by Harbor itself each time the user installs/upgrades Harbor. + This cert (used by notary-signer) is generated by Harbor itself each time the user installs/upgrades Harbor. In the event an administrator would like to replenish the notary-signer certificate the easiest way is to do it is by upgrading or re-installing Harbor @@ -753,7 +753,7 @@ Use forensics to identify what bad actors have modified and restore images as ne Compromised infrastructure node or operating system where Harbor is deployed (e.g. compromised Kubernetes worker node) - Has access to the database and can modify or remove the data. The attacker for example can delete login accounts (users can’t login), projects (images can’t be pulled), artifacts (images can’t be pulled), robot accounts (CI/CD can’t login to Harbor), change configuration and policy (if you change policy, desired config, and certain security restrictions like the enforcement of not allowing images to be pulled unless they are free from vulnerabilities may not apply), and more. All the Harbor configuration data is stored in the database and can be deleted or altered by the attacker. + Has access to the database and can modify or remove the data. The attacker for example can delete login accounts (users can’t login), projects (images can’t be pulled), artifacts (images can’t be pulled), robot accounts (CI/CD can’t login to Harbor), change configuration and policy (if you change policy, desired config, and certain security restrictions like the enforcement of not allowing images to be pulled unless they are free from vulnerabilities may not apply), and more. All the Harbor configuration data is stored in the database and can be deleted or altered by the attacker.

He can also shut down Harbor to make it inaccessible (DOS) to the end-user. Harbor cannot operate without a database.

@@ -1091,16 +1091,16 @@ on the project amounted to eighteen person-days split across 7 security research -* [-ve] Cure53 managed to spot six security-relevant findings. Four were classified as security vulnerabilities and two should be seen as general weaknesses +* [-ve] Cure53 managed to spot six security-relevant findings. Four were classified as security vulnerabilities and two should be seen as general weaknesses * [-ve] While the Harbor software made a well-rounded impression, the results in terms of security posture are not yet optimal, calling for more hardening work across various areas * [Commentary by Harbor Security Team] We are addressing all high and critical vulnerabilities found in Harbor v1.10 * [-ve] Cure53 demonstrated that Harbor suffers from a number of security issues that are usually found in completely untested applications * [Commentary by Harbor Security Team] We are addressing all high and critical vulnerabilities found in Harbor v1.10 -* [+ve] Can certainly call Harbor a modern web application that follows various up-to-date and modern security practices -* [+ve] While the words above may sound harsh and the found vulnerabilities are in fact severe, they do not signify that the Harbor complex is in a particularly bad shape. For example, the number of findings is very low and the overall pentest results and general impressions about the codebase are rather positive. Lack of further “Critical” input sanitization issues is definitely a good indicator as well. -* [+ve] Furthermore, Cure53 feels obliged to state that the Harbor code is clean, easy to follow and yields itself well to auditing. Similarly, the platform is built upon containerized microservices that raise the security level in a non-negligible way. It is worth pointing out that even if one part of the application is compromised, it does not necessarily mean that the server is also directly prone to successful attacks. The separation of duty principle is implemented in a praiseworthy manner. It is also important to note that Cure53 did not find flaws in the areas that the Harbor was most worried about as a result of previous vulnerabilities residing there. In fact, these were almost completely issue-free. Access control via RBAC with its different user models and groups is tightly implemented, uploaded files are handled safely and dangerous features such as webhooks are secure and robust +* [+ve] Can certainly call Harbor a modern web application that follows various up-to-date and modern security practices +* [+ve] While the words above may sound harsh and the found vulnerabilities are in fact severe, they do not signify that the Harbor complex is in a particularly bad shape. For example, the number of findings is very low and the overall pentest results and general impressions about the codebase are rather positive. Lack of further “Critical” input sanitization issues is definitely a good indicator as well. +* [+ve] Furthermore, Cure53 feels obliged to state that the Harbor code is clean, easy to follow and yields itself well to auditing. Similarly, the platform is built upon containerized microservices that raise the security level in a non-negligible way. It is worth pointing out that even if one part of the application is compromised, it does not necessarily mean that the server is also directly prone to successful attacks. The separation of duty principle is implemented in a praiseworthy manner. It is also important to note that Cure53 did not find flaws in the areas that the Harbor was most worried about as a result of previous vulnerabilities residing there. In fact, these were almost completely issue-free. Access control via RBAC with its different user models and groups is tightly implemented, uploaded files are handled safely and dangerous features such as webhooks are secure and robust * The Areas that the Harbor team was most worried were: web UI, injection attacks, code execution attacks, RBAC & multitenancy & privilege escalation, integrity tests, programmatic DoS, service robustness, DB hardening, security of k8s deployment -* [+ve] To conclude, Cure53 feels that Harbor is fully legitimized in calling its software compound secure and trustworthy. The examined scope items exhibit strong security posture, even though this CNFC-funded project revealed that some problems exist +* [+ve] To conclude, Cure53 feels that Harbor is fully legitimized in calling its software compound secure and trustworthy. The examined scope items exhibit strong security posture, even though this CNFC-funded project revealed that some problems exist Overall, the security pentest report indicates that with a few fixes (which were already addressed in v1.10) Harbor will achieve limiting the attack surface, taking appropriate care of user-supplied input with security-driven best practices, as well as - to a certain extent - the usage of the Go language ecosystem. diff --git a/assessments/projects/in-toto/README.md b/assessments/projects/in-toto/README.md index 64af87f61..571d7adcf 100644 --- a/assessments/projects/in-toto/README.md +++ b/assessments/projects/in-toto/README.md @@ -41,24 +41,24 @@ higher-level tooling. **Analysis**: focused approach to mitigating risks in supply chain which are underserved by other tech. Threats are well-understood and mitigated, including a reasonable degradation approach. Solid code processes; resiliency would -benefit from additional participants. +benefit from additional participants. All questions from reviewers were addressed in [self-assessment](self-assessment.md) with non-critical issues captured as -issues and noted below. +issues and noted below. ## Recommendations To address supply chain vulnerabilities, companies need more than technology, -they will need to adopt or formalize effective policies and procedures. +they will need to adopt or formalize effective policies and procedures. ### CNCF recommendations * Identify UX Researcher to engage 2-3 companies or projects to evaluate the time and effort required to integrate in-toto and recommend improvements -* SIG-Security collaboration to document common supply chain threats and +* TAG-Security collaboration to document common supply chain threats and complementary solutions that would cover security of all inputs - (see [issues#224](https://github.com/cncf/sig-security/issues/224)) + (see [issues#224](https://github.com/cncf/tag-security/issues/224)) ### Project recommendations @@ -73,11 +73,11 @@ they will need to adopt or formalize effective policies and procedures. [issue#287](https://github.com/in-toto/in-toto/issues/287)) * Proceed with [CII silver badge](https://bestpractices.coreinfrastructure.org/en/projects/1523?criteria_level=1) - & [roadmap](https://github.com/in-toto/in-toto/blob/develop/ROADMAP.md). + & [roadmap](https://github.com/in-toto/in-toto/blob/develop/ROADMAP.md). Just a few open items, listed below: * Projects MUST monitor or periodically check their external dependencies (including convenience copies) to detect known vulnerabilities, and fix - exploitable vulnerabilities or verify them as unexploitable. + exploitable vulnerabilities or verify them as unexploitable. * The project MUST implement secure design principles, where applicable. * The project MUST provide an assurance case that @@ -96,4 +96,4 @@ they will need to adopt or formalize effective policies and procedures. * Consider integrations with other CI/CD projects -Tracking issue: https://github.com/cncf/sig-security/issues/166 \ No newline at end of file +Tracking issue: https://github.com/cncf/tag-security/issues/166 diff --git a/assessments/projects/keycloak/self-assessment.md b/assessments/projects/keycloak/self-assessment.md index 998cf1f59..54db90ef8 100644 --- a/assessments/projects/keycloak/self-assessment.md +++ b/assessments/projects/keycloak/self-assessment.md @@ -10,11 +10,11 @@ Keycloak (version 8) received an external Penetration Test from Cure53 during fa “In Cure53’s expert opinion, the results documented in this November 2019 report affirm that Keycloak is a mature and solid project. Even though it cannot be ruled out that some components of the application are suffering from issues similar to the ones described in the tickets - mostly because of the size and complexity of this project, Cure53 is confident about Keycloak moving forward securely. The outcomes show that the developer team at the Keycloak entities designs and proposes features with high awareness about the field of security. Summing up, with absence of serious problems and a generally limited presence of risks, the application makes a stable impression in relation to the core security aspects.” -## +## -## +## **Metadata** @@ -42,7 +42,7 @@ Keycloak (version 8) received an external Penetration Test from Cure53 during fa - Community + Community https://www.keycloak.org - website

@@ -70,22 +70,22 @@ Keycloak Introduction [32min 11s] Security Provider - Yes. IAM, Authorization Server (OAuth 2.0, UMA 2.0), Identity Provider (OpenID Connect, SAML 2.0), + Yes. IAM, Authorization Server (OAuth 2.0, UMA 2.0), Identity Provider (OpenID Connect, SAML 2.0), -## +## **Overview** ### Background -Keycloak is an OpenSource Identity and Access Management Solution for Modern Applications, API and Services. It primarily aims to make security easy for developers and covers modern security needs of applications with minimal effort. It also empowers developers, administrators and users by allowing them to leverage modern authentication and authorization standards (ex. OAuth2, OpenID Connect, WebAuthn). Existing security infrastructure like SAML2 based IdPs, LDAP servers, Kerberos/SPNEGO, custom user storage solutions are easy to integrate while making their presence transparent to applications and end users. Keycloak is highly customizable, provides a set of out of the box User Interfaces and integrations and can be made to look like an integral part of a given application. Since its origin, it has aimed to be a self-contained, easy to run and lightweight solution. +Keycloak is an OpenSource Identity and Access Management Solution for Modern Applications, API and Services. It primarily aims to make security easy for developers and covers modern security needs of applications with minimal effort. It also empowers developers, administrators and users by allowing them to leverage modern authentication and authorization standards (ex. OAuth2, OpenID Connect, WebAuthn). Existing security infrastructure like SAML2 based IdPs, LDAP servers, Kerberos/SPNEGO, custom user storage solutions are easy to integrate while making their presence transparent to applications and end users. Keycloak is highly customizable, provides a set of out of the box User Interfaces and integrations and can be made to look like an integral part of a given application. Since its origin, it has aimed to be a self-contained, easy to run and lightweight solution. -The quickest way to understand the Keycloak project's capabilities is by viewing the below videos: +The quickest way to understand the Keycloak project's capabilities is by viewing the below videos: Keycloak Pitch [1m 42s] @@ -98,34 +98,34 @@ Keycloak Introduction [32min 11s] ### Goals The goals of Keycloak are: -* To provide an implementation for modern security standards; specifically OAuth2, OIDC and related specifications. Keycloak implements User Managed Access (UMA2) for authorization purposes which also builds on top of the same standard family. -* To be a SAML 2.0 compatible Identity Provider as this is still the most dominant and established standard in the end user authentication space. +* To provide an implementation for modern security standards; specifically OAuth2, OIDC and related specifications. Keycloak implements User Managed Access (UMA2) for authorization purposes which also builds on top of the same standard family. +* To be a SAML 2.0 compatible Identity Provider as this is still the most dominant and established standard in the end user authentication space. * To provide all required authentication, authorization and identity management capabilities for applications out-of-the-box without requiring additional coding. This includes typical security features like login screens, registration, user management, user account self management, password policies, etc. -* To focus on Cloud Native and modern use cases and related modern application types. +* To focus on Cloud Native and modern use cases and related modern application types. * To remain a language agnostic solution. By providing implementation of key standards like OpenID Connect or OAuth2, Keycloak can be integrated into any technology stack with the necessary integration libraries. As such it can serve as an IAM solution for any language. Keycloak is a Java based solution and its development language is an implementation detail. -* To be highly extendable and customizable. Keycloak [maintains a set of SPIs](https://www.keycloak.org/docs/latest/server_development/index.html#preface) and endorses community developed [extensions and plugins](https://www.keycloak.org/extensions.html). [*Currently this makes some extensions require Java knowledge although long term the project will be moving to Webhooks/REST/gRPC APIs extension model] -* To provide high availability and scalable solutions. Keycloak aims to allow handling authentication for millions of users deployed across a multi-cluster environment. +* To be highly extendable and customizable. Keycloak [maintains a set of SPIs](https://www.keycloak.org/docs/latest/server_development/index.html#preface) and endorses community developed [extensions and plugins](https://www.keycloak.org/extensions.html). [*Currently this makes some extensions require Java knowledge although long term the project will be moving to Webhooks/REST/gRPC APIs extension model] +* To provide high availability and scalable solutions. Keycloak aims to allow handling authentication for millions of users deployed across a multi-cluster environment. * To be provide a solution with a high level of security addressing administrator requirements for an IdP. Such as key rotation, Vault support, etc. ### Non-goals -Keycloak is an opinionated solution that seeks to avoid code and function creep. Keycloak aims to remain fairly lightweight, easy to use and quick to adopt, delivering on the 80/20 principle. +Keycloak is an opinionated solution that seeks to avoid code and function creep. Keycloak aims to remain fairly lightweight, easy to use and quick to adopt, delivering on the 80/20 principle. -Keycloak is not intended to be an “all capable” IDM solution supporting every protocol and use case. The Keycloak project purposefully prevents feature creep and keeps other technologies (CAS, WS-Fed, etc.) outside of the core codebase, while maintaining an ecosystem of additional [extensions](https://www.keycloak.org/extensions). +Keycloak is not intended to be an “all capable” IDM solution supporting every protocol and use case. The Keycloak project purposefully prevents feature creep and keeps other technologies (CAS, WS-Fed, etc.) outside of the core codebase, while maintaining an ecosystem of additional [extensions](https://www.keycloak.org/extensions). -* Keycloak doesn’t aim to cover every single authentication or authorization standard. Only most relevant, widely adopted and future facing ones. -* Keycloak doesn’t aim to provide SDKs and integration libraries for all languages. Wherever a given language, framework or technology stack provides decent OpenID Connect integration with proper usability, Keycloak will rather leverage it instead of providing a custom one. +* Keycloak doesn’t aim to cover every single authentication or authorization standard. Only most relevant, widely adopted and future facing ones. +* Keycloak doesn’t aim to provide SDKs and integration libraries for all languages. Wherever a given language, framework or technology stack provides decent OpenID Connect integration with proper usability, Keycloak will rather leverage it instead of providing a custom one. * Keycloak doesn’t provide its own implementation of cryptographic libraries. Relies on proven and pluggable ones from JVM and it’s runtime layers * Keycloak doesn’t aim to be Kerberos server, LDAP or etc. * Keycloak doesn't aim to be an Web Application Firewall, even though it offers some protection mechanisms. -* Keycloak doesn’t aim to be a certificate authority, ACME implementation or etc. -* Keycloak doesn’t intend to solve all integrations or problems like high availability on it’s own. Wherever possible, it leverages already available, proven and trusted OpenSource solutions. +* Keycloak doesn’t aim to be a certificate authority, ACME implementation or etc. +* Keycloak doesn’t intend to solve all integrations or problems like high availability on it’s own. Wherever possible, it leverages already available, proven and trusted OpenSource solutions. ### Authentication and OpenID Connect -A review of the [documentation around OpenID Connect](https://www.keycloak.org/docs/latest/server_admin/#_oidc) can be helpful to best understand how Keycloak approaches authentication: +A review of the [documentation around OpenID Connect](https://www.keycloak.org/docs/latest/server_admin/#_oidc) can be helpful to best understand how Keycloak approaches authentication: _“[OpenID Connect](https://openid.net/connect/) (OIDC) is an authentication protocol that is an extension of [OAuth 2.0](https://tools.ietf.org/html/rfc6749). While OAuth 2.0 is only a framework for building authorization protocols and is mainly incomplete, OIDC is a full-fledged authentication and authorization protocol. OIDC also makes heavy use of the [Json Web Token](https://jwt.io/) (JWT) set of standards. These standards define an identity token JSON format and ways to digitally sign and encrypt that data in a compact and web-friendly way._ @@ -133,16 +133,16 @@ _There are really two types of use cases when using OIDC. The first is an applic _The second type of use cases is that of a client that wants to gain access to remote services. In this case, the client asks Keycloak to obtain an access token it can use to invoke on other remote services on behalf of the user. Keycloak authenticates the user then asks the user for consent to grant access to the client requesting it. The client then receives the access token. This access token is digitally signed by the realm. The client can make REST invocations on remote services using this access token. The REST service extracts the access token, verifies the signature of the token, then decides based on access information within the token whether or not to process the request.“_ -The lifespan of different tokens being used in related OAuth2 flows (access token, refresh token and id token) can be configured. They can also be manually invalidated by the end user or administrator. This allows developers or administrators to adapt authentication schemes to different use cases or needs. Either allowing users to very rarely be required to authenticate again or being able to cut off their access to applications very quickly. In the case of backend services, long lived tokens with months or a year-long lifespan can be used - usually referred to as “offline tokens” or “service tokens”. +The lifespan of different tokens being used in related OAuth2 flows (access token, refresh token and id token) can be configured. They can also be manually invalidated by the end user or administrator. This allows developers or administrators to adapt authentication schemes to different use cases or needs. Either allowing users to very rarely be required to authenticate again or being able to cut off their access to applications very quickly. In the case of backend services, long lived tokens with months or a year-long lifespan can be used - usually referred to as “offline tokens” or “service tokens”. More information can be found in the [OpenID Connect flows](https://www.keycloak.org/docs/latest/server_admin/#_oidc-auth-flows) documentation. ### Authorization -While RBAC (Role Based Access Control), and to a certain extent ABAC, can be achieved using OAuth2/OIDC/SAML by including relevant role or attribute information in OAuth2 claims or SAML assertion, Keycloak does provide centralized authorization capabilities. +While RBAC (Role Based Access Control), and to a certain extent ABAC, can be achieved using OAuth2/OIDC/SAML by including relevant role or attribute information in OAuth2 claims or SAML assertion, Keycloak does provide centralized authorization capabilities. -This includes +This includes * Attribute-based access control (ABAC) * Role-based access control (RBAC) * User-based access control (UBAC) @@ -155,11 +155,11 @@ This includes A comprehensive description is available separately within the [“Authorization Services Guide”](https://www.keycloak.org/docs/latest/authorization_services/). Centralized Authorization capabilities are provided in separate layer to Authentication. There is certain level of pluggability by implementing [Custom Policies in JavaScript](https://www.keycloak.org/docs/latest/authorization_services/#_policy_js), [deploying them on the server ](https://www.keycloak.org/docs/latest/server_development/#_script_providers)or providing a custom [Policy Evaluation scheme](https://www.keycloak.org/docs/latest/authorization_services/#_policy_evaluation_api) -## +## **Intended Use** -Keycloak is an OpenSource Identity and Access Management Solution for Modern Applications, API and Services. It focuses on ease of deployment, providing a complete set of modern lightweight Identity Provider capabilities and allowing Developers to incorporate all relevant security capabilities into their applications with minimal effort. +Keycloak is an OpenSource Identity and Access Management Solution for Modern Applications, API and Services. It focuses on ease of deployment, providing a complete set of modern lightweight Identity Provider capabilities and allowing Developers to incorporate all relevant security capabilities into their applications with minimal effort. ### Target Users @@ -171,11 +171,11 @@ Keycloak is an OpenSource Identity and Access Management Solution for Modern App ### Use Cases * Standalone Identity Provider (OpenID Connect, SAML 2.0) * Standalone Authorization Server (OAuth 2.0) -* Central Authorization solution (User Managed Access - UMA 2.0). +* Central Authorization solution (User Managed Access - UMA 2.0). * Policy Evaluation Point, custom, chained policies (ABAC, Rules, Custom, etc.) * Offloading application from implementing typical capabilities by providing integrations and set of hosted screens and services which can be themed/skinned to look like an integral part of application * Security (authn/authz) - * Identity and Access Management capabilities (User/Role/Attribute management, password policies, etc.) + * Identity and Access Management capabilities (User/Role/Attribute management, password policies, etc.) * Authentication / Registration capabilities * Modern authentication capabilities (W3C WebAuthN, MFA) * User Self Service (changing profile, password, registering authentication tokens, sessions and consent management) @@ -197,9 +197,9 @@ Keycloak is an OpenSource Identity and Access Management Solution for Modern App #### Installation -Keycloak is provided as a Container deployed separately via Docker/Podman or on Kubernetes. As this is a Java based solution there is also a ZIP based distribution which can be unpacked and run with a single command if JVM is present. +Keycloak is provided as a Container deployed separately via Docker/Podman or on Kubernetes. As this is a Java based solution there is also a ZIP based distribution which can be unpacked and run with a single command if JVM is present. -The getting started section of website gives the shortest path to try out the project via different means: +The getting started section of website gives the shortest path to try out the project via different means: [https://www.keycloak.org/getting-started](https://www.keycloak.org/getting-started) @@ -213,10 +213,10 @@ It is worth noting that for security reasons, Keycloak is required to explicitly Additional information is covered in the [Server Installation Guide](https://www.keycloak.org/docs/latest/server_installation/) although it currently mostly focuses on ZIP distribution. Additional documentation related to container image is available [here](https://hub.docker.com/r/jboss/keycloak/). Keycloak also provides a [Kubernetes Operator.](https://operatorhub.io/operator/keycloak-operator) -Keycloak is a highly configurable and customizable solution. The documentation goes into great detail on how to manage server configuration. Key aspects of dealing with the server are highlighted below: +Keycloak is a highly configurable and customizable solution. The documentation goes into great detail on how to manage server configuration. Key aspects of dealing with the server are highlighted below: -#### Interacting with Keycloak +#### Interacting with Keycloak All operations performed with Keycloak by an administrator or developer are exposed via REST API, Web UIs or CLI (both consuming mentioned REST APIs). All REST APIs are [documented here](https://www.keycloak.org/docs-api/9.0/rest-api/index.html) @@ -247,23 +247,23 @@ For example, a new set of planned screens related to managing clients: #### Customizations and extensions -Keycloak is built in a highly modular manner leveraging SPI for most of the internal components (more about it later in Design section). +Keycloak is built in a highly modular manner leveraging SPI for most of the internal components (more about it later in Design section). -In addition, because it provides a set of OOTB screens (login, registration, user self management, administration) it is meant to be customized to look like an integral part of a given application or system. Therefore, administrators can customize every aspect of Keycloak UI via templates and themes. +In addition, because it provides a set of OOTB screens (login, registration, user self management, administration) it is meant to be customized to look like an integral part of a given application or system. Therefore, administrators can customize every aspect of Keycloak UI via templates and themes. -As a highly customizable solution Keycloak, provides a separate Guide on [Server Development](https://www.keycloak.org/docs/latest/server_development/), focusing on explaining mentioned themes, templates and SPIs and the means to leverage or alter them. +As a highly customizable solution Keycloak, provides a separate Guide on [Server Development](https://www.keycloak.org/docs/latest/server_development/), focusing on explaining mentioned themes, templates and SPIs and the means to leverage or alter them. A few key SPIs and extension mechanisms worth mentioning cover: * Authentication - allowing to highly alter authentication flow - * IdentityBrokering (federation of identities from external authentication sources - eg. SAML/OIDC IdPs) + * IdentityBrokering (federation of identities from external authentication sources - eg. SAML/OIDC IdPs) * Required Actions - defining different actions users are meant to perform during authentication * Modifying / Extending Registration flow * Modifying Forgot Password / Credential flow * Authentication of clients * Action Token SPI - An action token is a special instance of JSON Web Token (JWT) that permits its bearer to perform some actions, e. g. to reset a password or validate email address. They are usually sent to users in the form of a link that points to an endpoint processing action tokens for a particular realm. * Event Listener SPI - allowing handling of different user, client or admin initiated operations -* Mappers - implementing own mappers to bridge information from external stores (eg. LDAP attributes) or tokens (external SAML IdP) and mapping it to attributes or claims in Keycloak. -* User Storage SPI - can be used to write extensions to Keycloak to connect to external user databases and credential stores. +* Mappers - implementing own mappers to bridge information from external stores (eg. LDAP attributes) or tokens (external SAML IdP) and mapping it to attributes or claims in Keycloak. +* User Storage SPI - can be used to write extensions to Keycloak to connect to external user databases and credential stores. * Vault SPI - to write custom extensions for Keycloak to connect to arbitrary vault implementation. There is a list of community implemented and maintained custom extensions which are not provided OOTB within server distribution on project website: @@ -318,7 +318,7 @@ For all events there is a corresponding error event. #### Delegated Administration -Administrative users of Keycloak can be defined with a subset of management permissions. For example, allowing users to only manage application clients. A comprehensive overview is provided in in the [server admin docs permission section](https://www.keycloak.org/docs/latest/server_admin/index.html#_admin_permissions). This capability is also provided based on the [Authorization Services](https://www.keycloak.org/docs/latest/authorization_services/) part of Keycloak implemented with UMA (User Managed Access). +Administrative users of Keycloak can be defined with a subset of management permissions. For example, allowing users to only manage application clients. A comprehensive overview is provided in in the [server admin docs permission section](https://www.keycloak.org/docs/latest/server_admin/index.html#_admin_permissions). This capability is also provided based on the [Authorization Services](https://www.keycloak.org/docs/latest/authorization_services/) part of Keycloak implemented with UMA (User Managed Access). Available global roles: * admin - top level realm role @@ -371,7 +371,7 @@ Keycloak can be configured to provide High Availability in a local cluster or in In order to prioritize significant performance gain OOTB in Keycloak, clustering is configured in a way to not propagate user sessions between nodes by default. In the event of node failure, such that the authentication session is lost, the user is required to re-authenticate and establish a new session. This is configurable and sessions can be replicated between cluster nodes making node failure transparent and not impacting users. -Keycloak provides Multi-Cluster configuration which relies on separate Database synchronization and Cache synchronization solutions to solve the split-brain problem between clusters. +Keycloak provides Multi-Cluster configuration which relies on separate Database synchronization and Cache synchronization solutions to solve the split-brain problem between clusters. @@ -379,32 +379,32 @@ Keycloak provides Multi-Cluster configuration which relies on separate Database ![alt_text](docs/image7.png "image_tooltip") -The current architecture is based on requirements of the Database and relies on invalidation of caches (more in Design section). Part of Keycloak.X's effort plan for 2020/21 is to implement a completely new storage layer, aiming to leverage etcd as OOTB storage when deployed on Kubernetes and not requiring RDBMS at all in such deployments. +The current architecture is based on requirements of the Database and relies on invalidation of caches (more in Design section). Part of Keycloak.X's effort plan for 2020/21 is to implement a completely new storage layer, aiming to leverage etcd as OOTB storage when deployed on Kubernetes and not requiring RDBMS at all in such deployments. -## +## **Project Design** ## High level architecture: -Keycloak follows a modular and layered approach. For security and scalability reasons it chose not to reimplement but reuse existing trusted runtime components. Keycloak also defaults to reuse default libraries and solutions if present in layers below. +Keycloak follows a modular and layered approach. For security and scalability reasons it chose not to reimplement but reuse existing trusted runtime components. Keycloak also defaults to reuse default libraries and solutions if present in layers below. ![alt_text](docs/image8.png "image_tooltip") -Keycloak is built on top of Java Virtual Machine as a trusted runtime environment. It is maintained by several key industry players and receives timely security fixes. As a very widely adopted solution, it is also highly scrutinized and investigated from a security perspective. +Keycloak is built on top of Java Virtual Machine as a trusted runtime environment. It is maintained by several key industry players and receives timely security fixes. As a very widely adopted solution, it is also highly scrutinized and investigated from a security perspective. -Keycloak is essentially a Java Application running within Application Server ([WildFly](https://wildfly.org/)) which is an upstream version of widely adopted Red Hat Enterprise Application Platform (former JBoss AS). Keycloak leverages key features around clustering, REST API implementation, SSL, Data Sources, Transaction handling, etc. from Wildfly. This gives several advantages related to using proven technologies. As Keycloak relies on Crypto libraries provided by JVM and WildFly it can be made FIPS compliant by adopting relevant configuration profiles in those. +Keycloak is essentially a Java Application running within Application Server ([WildFly](https://wildfly.org/)) which is an upstream version of widely adopted Red Hat Enterprise Application Platform (former JBoss AS). Keycloak leverages key features around clustering, REST API implementation, SSL, Data Sources, Transaction handling, etc. from Wildfly. This gives several advantages related to using proven technologies. As Keycloak relies on Crypto libraries provided by JVM and WildFly it can be made FIPS compliant by adopting relevant configuration profiles in those. -The Keycloak project is currently undergoing a complete re-architecture designed to migrate to [Quarkus.io](https://quarkus.io) as a runtime. This will allow for natively compiled binaries (natively compiled Java) and a very small memory footprint or startup time comparable with GoLang. [This is captured](https://github.com/keycloak/keycloak-community/tree/master/design/keycloak.x) by the [Keycloak.X](https://www.keycloak.org/2019/10/keycloak-x.html) effort. With prototype server distribution being developed [here](https://github.com/keycloak/keycloak/tree/master/distribution/server-x). In the transition period, a mixed and highly optimized mode still running within VM will be possible. +The Keycloak project is currently undergoing a complete re-architecture designed to migrate to [Quarkus.io](https://quarkus.io) as a runtime. This will allow for natively compiled binaries (natively compiled Java) and a very small memory footprint or startup time comparable with GoLang. [This is captured](https://github.com/keycloak/keycloak-community/tree/master/design/keycloak.x) by the [Keycloak.X](https://www.keycloak.org/2019/10/keycloak-x.html) effort. With prototype server distribution being developed [here](https://github.com/keycloak/keycloak/tree/master/distribution/server-x). In the transition period, a mixed and highly optimized mode still running within VM will be possible. All major design proposals are tracked for review and discussion in this [dedicated Github repository](https://github.com/keycloak/keycloak-community/tree/master/design). Keycloak architecture is highly modular and pluggable. All Core parts are implemented using Service Provider Interface architecture (SPIs) having a total of 86 of them. This makes it easy to extend the server with custom plugins, and replace default implementations of core components. All key SPIs are documented in the [Server Development Guide](https://www.keycloak.org/docs/latest/server_development/index.html#_providers). -Keycloak is highly customizable. It provides several SPIs enabling the extension or alteration of server behavior according to individual needs. Any UI exposed by Keycloak can be customized with custom stylesheets, but also with custom HTML templates. This has already been described in +Keycloak is highly customizable. It provides several SPIs enabling the extension or alteration of server behavior according to individual needs. Any UI exposed by Keycloak can be customized with custom stylesheets, but also with custom HTML templates. This has already been described in [Operational Aspects section](#heading=h.fvxvw696zrq8) of this document @@ -417,28 +417,28 @@ Keycloak is highly customizable. It provides several SPIs enabling the extension ![alt_text](docs/image10.png "image_tooltip") -Keycloak currently requires a Relational Database to work. It comes with a simple embedded H2 Database for quick prototyping or with easy OOTB PostgreSQL integration when provisioned via container based environments. RDBMS is used to persist realm configurations and information about users, roles, clients, consents or mappings of attributes in the token. For future releases, a major redesign is planned to drop this requirement and allow greater pluggability of storage layers. By default when deployed on Kubernetes, Keycloak will attach itself to etcd as primary storage solution. Requiring additional, more scalable solutions for production deployments when storing millions of users is necessary. +Keycloak currently requires a Relational Database to work. It comes with a simple embedded H2 Database for quick prototyping or with easy OOTB PostgreSQL integration when provisioned via container based environments. RDBMS is used to persist realm configurations and information about users, roles, clients, consents or mappings of attributes in the token. For future releases, a major redesign is planned to drop this requirement and allow greater pluggability of storage layers. By default when deployed on Kubernetes, Keycloak will attach itself to etcd as primary storage solution. Requiring additional, more scalable solutions for production deployments when storing millions of users is necessary. -The data storage layer is designed to rely heavily on invalidation of caches to minimize Database queries. This also allows for HA deployments with [clustering](https://www.keycloak.org/docs/latest/server_installation/index.html#_clustering) and [Cross Data Center](https://www.keycloak.org/docs/latest/server_installation/index.html#crossdc-mode) replication mode. All ways to interact with the server are integrated via [REST APIs documented here](https://www.keycloak.org/docs-api/7.0/rest-api/index.html). Keycloak relies on OpenID Connect to secure access to those APIs. +The data storage layer is designed to rely heavily on invalidation of caches to minimize Database queries. This also allows for HA deployments with [clustering](https://www.keycloak.org/docs/latest/server_installation/index.html#_clustering) and [Cross Data Center](https://www.keycloak.org/docs/latest/server_installation/index.html#crossdc-mode) replication mode. All ways to interact with the server are integrated via [REST APIs documented here](https://www.keycloak.org/docs-api/7.0/rest-api/index.html). Keycloak relies on OpenID Connect to secure access to those APIs. -Keycloak supports OpenID Connect and SAML2 out of the box. There number of additional extensions kept outside of the core codebase - like [WS-Federation or CAS](html). +Keycloak supports OpenID Connect and SAML2 out of the box. There number of additional extensions kept outside of the core codebase - like [WS-Federation or CAS](html). ![alt_text](docs/image11.png "image_tooltip") -## +## **Configuration and Set-Up** * Default/GettingStarted - * Aggregated information for getting started in different environments: [https://www.keycloak.org/getting-started](https://www.keycloak.org/getting-started) + * Aggregated information for getting started in different environments: [https://www.keycloak.org/getting-started](https://www.keycloak.org/getting-started) * Keycloak Operator for Kubernetes [docs in progress]: [https://github.com/keycloak/keycloak-operator](https://github.com/keycloak/keycloak-operator) * Helm Chart: [https://github.com/codecentric/helm-charts/tree/master/charts/keycloak](https://github.com/codecentric/helm-charts/tree/master/charts/keycloak) * Set of Quickstart applications: [https://github.com/keycloak/keycloak-quickstarts](https://github.com/keycloak/keycloak-quickstarts) * Highlights: * Follows a number of OOTB security best practices listed below: * There is no default account/password - * Creating initial account is protected by being exposed only via localhost access (for UI) and via direct access to host (command line script) + * Creating initial account is protected by being exposed only via localhost access (for UI) and via direct access to host (command line script) * Security of OAuth 2.0 based protocol relies heavily on TLS and this is called out in documentation: * [https://www.keycloak.org/docs/latest/server_installation/index.html#setting-up-https-ssl](https://www.keycloak.org/docs/latest/server_installation/index.html#setting-up-https-ssl) * Advanced/Secure setup @@ -447,69 +447,69 @@ Keycloak supports OpenID Connect and SAML2 out of the box. There number of addit * Server comes with simple [Brute Force detection and mitigation mechanism](https://www.keycloak.org/docs/latest/server_admin/index.html#password-guess-brute-force-attacks) * More Advanced Configuration: [https://www.keycloak.org/docs/latest/server_installation/index.html](https://www.keycloak.org/docs/latest/server_installation/index.html) * Reference Server Administration Guide: [https://www.keycloak.org/docs/latest/server_admin/index.html](https://www.keycloak.org/docs/latest/server_admin/index.html) - * The below documentation covers hardening and addressing Threat Model of OAuth2 itself: [https://www.keycloak.org/docs/latest/server_admin/index.html#threat-model-mitigation](https://www.keycloak.org/docs/latest/server_admin/index.html#threat-model-mitigation) + * The below documentation covers hardening and addressing Threat Model of OAuth2 itself: [https://www.keycloak.org/docs/latest/server_admin/index.html#threat-model-mitigation](https://www.keycloak.org/docs/latest/server_admin/index.html#threat-model-mitigation) -## +## **Project Compliance** * There was no specific audit for a given compliance standard -* Keycloak is GDPR compatible as user information can be removed on request and purged from the database however it depends on the particular deployment and processes around it. -* Keycloak provides audit capabilities by event logging, allowing to aggregate and record into system logger all typical admin and user level operations. -* Keycloak doesn’t provide any additional custom crypto libraries or crypto implementations. It relies on WildFly Application Server and Java Virtual Machine which can be configured to be made FIPS compliant. All crypto providers in Keycloak are also pluggable so FIPS compliance could be achieved by using certified libraries. +* Keycloak is GDPR compatible as user information can be removed on request and purged from the database however it depends on the particular deployment and processes around it. +* Keycloak provides audit capabilities by event logging, allowing to aggregate and record into system logger all typical admin and user level operations. +* Keycloak doesn’t provide any additional custom crypto libraries or crypto implementations. It relies on WildFly Application Server and Java Virtual Machine which can be configured to be made FIPS compliant. All crypto providers in Keycloak are also pluggable so FIPS compliance could be achieved by using certified libraries. * Keycloak aims to certify against OpenID Financial API Specification Profiles. This is still a Work in Progress. - * [https://github.com/jsoss-sig/keycloak-fapi](https://github.com/jsoss-sig/keycloak-fapi) + * [https://github.com/jsoss-tag/keycloak-fapi](https://github.com/jsoss-tag/keycloak-fapi) * [https://github.com/keycloak/keycloak-community/pull/105](https://github.com/keycloak/keycloak-community/pull/105) * [https://github.com/keycloak/keycloak-community/blob/master/design/client-policies.md](https://github.com/keycloak/keycloak-community/blob/master/design/client-policies.md) -## +## **Security Analysis** * Keycloak (version 8) received an external Penetration Test during the fall of 2019 performed by Cure53 and funded by REWE Digital GmbH. [https://cure53.de/pentest-report_keycloak.pdf](https://cure53.de/pentest-report_keycloak.pdf) * “In Cure53’s expert opinion, the results documented in this November 2019 report affirm that Keycloak is a mature and solid project. Even though it cannot be ruled out that some components of the application are suffering from issues similar to the ones described in the tickets - mostly because of the size and complexity of this project, Cure53 is confident about Keycloak moving forward securely. The outcomes show that the developer team at the Keycloak entities designs and proposes features with high awareness about the field of security. Summing up, with absence of serious problems and a generally limited presence of risks, the application makes a stable impression in relation to the core security aspects.” - * Keycloak follows a fast paced release cycle of major versions, progression between major versions (7->8->9) doesn’t typically introduce major redesigns or breaking changes. Therefore, overall and high level findings can be generalized also for Keycloak 9. + * Keycloak follows a fast paced release cycle of major versions, progression between major versions (7->8->9) doesn’t typically introduce major redesigns or breaking changes. Therefore, overall and high level findings can be generalized also for Keycloak 9. * Keycloak has a dedicated section in Documentation for addressing the OAuth 2.0 Threat Model from IETF: * [https://www.keycloak.org/docs/latest/server_admin/index.html#threat-model-mitigation](https://www.keycloak.org/docs/latest/server_admin/index.html#threat-model-mitigation) * [https://tools.ietf.org/html/rfc6819](https://tools.ietf.org/html/rfc6819) * Attacker Motivations - Keycloak as Identity Provider / Authorization Server and Identity and Access Management solution is a critical piece of infrastructure. Compromising the Keycloak deployment would likely compromise the whole deployment by permitting a malicious actor to take over users identities, application sessions or stealing password hashes (if the backend DB is compromised as well). * Predisposing Conditions * Existing CVEs in selected areas of JVM, WildFly Application Server or any library included in those layers or introduced by Keycloak itself, especially around networking, HTTP(s), object serialization and REST APIs (JOSE specs) - * Lack of SSL/HTTPS. OAuth 2.0 based flows heavily rely on exchanging tokens and information via already secured communication channels. Developers often make shortcuts during development that are deployed to production while quickly prototyping. It is essential that all related configurations is carefully verified before being introduced in production. - * Not following best practices around OAuth 2.0 - like not properly defined redirect URIs for registered clients or redirection URIs which exposes application to token or session hijacking attacks. + * Lack of SSL/HTTPS. OAuth 2.0 based flows heavily rely on exchanging tokens and information via already secured communication channels. Developers often make shortcuts during development that are deployed to production while quickly prototyping. It is essential that all related configurations is carefully verified before being introduced in production. + * Not following best practices around OAuth 2.0 - like not properly defined redirect URIs for registered clients or redirection URIs which exposes application to token or session hijacking attacks. * Not securing the backend properly. Outside access to DB or host or etc. - * Not keeping configuration up to date - * For example keeping up with the latest guidelines around strength of hashing algorithms or number of hashing iterations - * Not keeping up with updates. + * Not keeping configuration up to date + * For example keeping up with the latest guidelines around strength of hashing algorithms or number of hashing iterations + * Not keeping up with updates. * The Keycloak container image relies on several layers of the software stack which must be kept up-to-date: OS, JVM, WildFly Application Server, Keycloak itself. * At each layer there are new weaknesses regularly identified. Most of those have no direct impact on Keycloak although they need to be assessed and fixes incorporated - * Ex. XML/JSON parsing libs has remote code execution weaknesses identified. With proper validation they are rarely exploitable in Keycloak although such CVEs happened. + * Ex. XML/JSON parsing libs has remote code execution weaknesses identified. With proper validation they are rarely exploitable in Keycloak although such CVEs happened. * Specifications are evolving. Certain aspects of the initial OAuth2 specification are now considered insecure (to be addressed and incorporated in 2.1 version). Although certain best practices, like replacing Implicit Flow with Hybrid Flow or using PKCE, are included in Keycloak. Other examples would be updates to recommendations around hashing algorithms. Most key aspects of these changes will become the default option in Keycloak and are to be selected as part of any software update. * Expected Attacker Capabilities * Very good understanding of OAuth 2.0 protocol family flows and capabilities - * Very good understanding of all typical Web Application attack vectors (CSRF, XSS, etc.) - * For example, the most common attack vector would be exploiting any weaknesses in input validation of Keycloak APIs if they could lead into remote code execution on the server side. - * Similarly, in this area there were several CVEs identified in jackson-bind components related to XML parsing. This can potentially open up the attack surface by altering SAML tokens and exploiting such CVEs. + * Very good understanding of all typical Web Application attack vectors (CSRF, XSS, etc.) + * For example, the most common attack vector would be exploiting any weaknesses in input validation of Keycloak APIs if they could lead into remote code execution on the server side. + * Similarly, in this area there were several CVEs identified in jackson-bind components related to XML parsing. This can potentially open up the attack surface by altering SAML tokens and exploiting such CVEs. * Some examples of CVEs identified in Keycloak are available in NVD * [https://nvd.nist.gov/vuln/search/results?form_type=Advanced&cves=on&cpe_version=cpe%3A%2Fa%3Aredhat%3Akeycloak%3A4.3.0](https://nvd.nist.gov/vuln/search/results?form_type=Advanced&cves=on&cpe_version=cpe%3A%2Fa%3Aredhat%3Akeycloak%3A4.3.0) * [https://www.cvedetails.com/product/46161/Redhat-Keycloak.html?vendor_id=25](https://www.cvedetails.com/product/46161/Redhat-Keycloak.html?vendor_id=25) * Attack Risks and Effects - * As this is an Identity Provider for Web Applications, all typical attack vectors, risk and effects would apply: + * As this is an Identity Provider for Web Applications, all typical attack vectors, risk and effects would apply: * [OWASP Top 10 Web Application Security Risks](https://owasp.org/www-project-top-ten/) * [OWASP Top 10 API Security Risks](https://owasp.org/www-project-api-security/) * Any other Web Application or API Security related best practices or key standards. * Security Degradation - * It is worth distinguishing the compromise of Keycloak itself from the compromise of applications secured with Keycloak (for example by hijacking session token). The latter doesn’t need to lead to the former while being the core goal of the attacker, the resulting compromise affects only one client or particular users while not compromising the IdP itself. + * It is worth distinguishing the compromise of Keycloak itself from the compromise of applications secured with Keycloak (for example by hijacking session token). The latter doesn’t need to lead to the former while being the core goal of the attacker, the resulting compromise affects only one client or particular users while not compromising the IdP itself. * Rendering server unavailable - * Potentially easiest attack on the server is DDOS impacting its availability. + * Potentially easiest attack on the server is DDOS impacting its availability. * Impact * End users not able to authenticate to applications - * Applications not being able to reach out to server for additional validation calls. At a minimum they should still be able to verify already issued tokens using the cached public key from the server and make authorization decisions based on existing included claims. Issuing new, refreshed access tokens for applications and end users won’t be possible due to the availability impact. + * Applications not being able to reach out to server for additional validation calls. At a minimum they should still be able to verify already issued tokens using the cached public key from the server and make authorization decisions based on existing included claims. Issuing new, refreshed access tokens for applications and end users won’t be possible due to the availability impact. * Prevention and mitigation mechanisms * Implementing proper HA deployment with Clustering or even Datacenter duplication or distribution * Fronting Keycloak with proper rate limiting solutions at the Load Balancer or Firewall level * Impacting server integrity and sensitive data Exposure - * Keycloak as an Identity Provider contains user sensitive data. + * Keycloak as an Identity Provider contains user sensitive data. * Impact - * At different levels of granularity, gaining access to data in the server can be very impactful + * At different levels of granularity, gaining access to data in the server can be very impactful * User access - leaking profile information and allowing to reset password and take over given user accounts. Although for user triggered password reset email validation can provide necessary mitigation * Session takeover - getting access to user session can allow attacker to take over access to given application and related resources * Gaining administrator access to the master realm is a potentially catastrophic event as it gives countless attack venues to exploit. @@ -518,14 +518,14 @@ Keycloak supports OpenID Connect and SAML2 out of the box. There number of addit * Server [Key rotation](https://www.keycloak.org/docs/latest/server_admin/#rotating-keys). Ability to introduce new server keys and invalidate old ones in case leak has been detected * User session invalidation and [refresh token revocation policy ](https://www.keycloak.org/docs/latest/server_admin/#_revocation-policy)allowing to not trust refresh tokens issued earlier then given timestamp * TLS preventing Man-in-the-Middle attacks - * MFA and W3C WebAuthentication - providing Strong Customer Authentication mechanisms for end users and Keycloak administrators. + * MFA and W3C WebAuthentication - providing Strong Customer Authentication mechanisms for end users and Keycloak administrators. * [Password Credentials hashing](https://www.keycloak.org/docs/latest/server_admin/#password-database-compromised) with pluggable SPIs to integrate third party vaults * [Limiting token audience](https://www.keycloak.org/docs/latest/server_admin/#limit-token-audience) to allow potential reuse prevention of leaked application sessions. * Possibility to introduce database encryption at RDBMs level - * [Brute force detection](https://www.keycloak.org/docs/latest/server_admin/#password-guess-brute-force-attacks) - basic mechanism preventing password guessing techniques. - * Keycloak follows best practices to try to not leak any indicator about which software version the given running instance is using. + * [Brute force detection](https://www.keycloak.org/docs/latest/server_admin/#password-guess-brute-force-attacks) - basic mechanism preventing password guessing techniques. + * Keycloak follows best practices to try to not leak any indicator about which software version the given running instance is using. * Compensating Mechanisms - * This highly depends on the feature and capability. Each time a new one is designed there is a fairly long discussion with many community members to ensure particular architecture will not lead to compromising security. + * This highly depends on the feature and capability. Each time a new one is designed there is a fairly long discussion with many community members to ensure particular architecture will not lead to compromising security. * See number of comments in the discussion on MutiFactor and Setup Authentication design proposal: [https://github.com/keycloak/keycloak-community/pull/5](https://github.com/keycloak/keycloak-community/pull/5) * There are several key risks and related mitigations listed in “[Threat Model Mitigation](https://www.keycloak.org/docs/latest/server_admin/#threat-model-mitigation)” section of the documentation. Few examples in bullets below * Eg. [Password database compromised](https://www.keycloak.org/docs/latest/server_admin/#password-database-compromised) @@ -545,72 +545,72 @@ Keycloak supports OpenID Connect and SAML2 out of the box. There number of addit * _You can also mitigate against leaked authorization codes by applying PKCE to clients. See [Proof Key for Code Exchange (PKCE)](https://www.keycloak.org/docs/latest/server_admin/#_proof-key-for-code-exchange) to learn how.”_ * _Eg. _Authorization Services and [handling custom polices implemented in JavaScript](https://www.keycloak.org/docs/latest/authorization_services/index.html#_policy_js) * _“By default, JavaScript Policies can not be uploaded to the server. You should prefer deploying your JS Policies directly to the server as described in [JavaScript Providers](https://www.keycloak.org/docs/latest/server_development/#_script_providers). If you still want to use the Keycloak Administration Console to manage your JS policies you should enable the ‘Upload Scripts’ feature.”_ - * This is done to mitigate any issues around handling (escaping/sandboxing) custom JavaScript code for those policies within the browser (within Admin UI). + * This is done to mitigate any issues around handling (escaping/sandboxing) custom JavaScript code for those policies within the browser (within Admin UI). * User impersonation * Server provides ability for the administrator with a given set of permissions to [impersonate a particular user](https://www.keycloak.org/docs/latest/server_admin/#impersonation) and act on their behalf. Security of aspects of this can be configured on few different levels - * Impersonation can be [disabled at the server instance level](https://www.keycloak.org/docs/latest/server_installation/#profiles) as part of startup configuration with: “-Dkeycloak.profile.feature.impersonation=disabled” option. This has been introduced deliberately at this level understanding some organizations would prefer not having such powerful capability enabled at all. + * Impersonation can be [disabled at the server instance level](https://www.keycloak.org/docs/latest/server_installation/#profiles) as part of startup configuration with: “-Dkeycloak.profile.feature.impersonation=disabled” option. This has been introduced deliberately at this level understanding some organizations would prefer not having such powerful capability enabled at all. * Impersonation can be [disabled at the realm level ](https://www.keycloak.org/docs/latest/server_admin/#_per_realm_admin_permissions)by removing the “Impersonation” role for given admin account * At the auditing level there are dedicated “Impersonate” and “Impersonate_Error” events to capture such activity for audit purposes * Impersonated user session[ provide details](https://www.keycloak.org/docs/latest/server_admin/#_protocol-mappers_oidc-user-session-note-mappers) on “Impersonator” - keeping track of who initiated impersonated session on behalf of given user * Typical configuration mistakes to avoid - * Man-In-the Middle - caution during server provisioning. There are means introduced to ensure that the initial administrator password is not leaked (no defaults, required to be set via localhost, leveraging scripts provided in the server to do so). - * Lack of TLS - which can lead to a Man-in-the-Middle attack. TLS is required by the OAuth2 specification. Establishing TLS for the server during provisioning is a must for production deployments. + * Man-In-the Middle - caution during server provisioning. There are means introduced to ensure that the initial administrator password is not leaked (no defaults, required to be set via localhost, leveraging scripts provided in the server to do so). + * Lack of TLS - which can lead to a Man-in-the-Middle attack. TLS is required by the OAuth2 specification. Establishing TLS for the server during provisioning is a must for production deployments. * Setting a weak password for admin - there is a very flexible and powerful password strength policy validation although it is not enabled by default to enforce initial one for admin account - * Using master realm for applications and administrator user within master realm for all provisioning and configuration purposes. This is equivalent to using or running under a “root” account in linux. - * Setting very long token lifespans for “convenience”. Although this reduces back and forth communication between the application and the server, it increases the risk of session takeover. + * Using master realm for applications and administrator user within master realm for all provisioning and configuration purposes. This is equivalent to using or running under a “root” account in linux. + * Setting very long token lifespans for “convenience”. Although this reduces back and forth communication between the application and the server, it increases the risk of session takeover. * Convenience. There are a number of shortcuts typically used during trials, debugging or development which if not disabled for production purposes will be a major attack vector. For example - * Using public clients for everything - as they don’t require client credentials. + * Using public clients for everything - as they don’t require client credentials. * Using confidential clients for everything - as they do require credentials they shouldn’t be used with purely client side apps (like JS based UIs) - * Using wildcards (*) for redirect URL validation. As OAuth2 is based on HTTP redirects it is a critical part of the core security model to very strictly validate allowed URIs. - * Disabling or not enabling certain features like password validation, brute force attacks, event logging etc. - * Not updating the server and not keeping track or keeping up with CVEs. - * Taking password hashing iterations to extreme - either reducing or increasing too much. Making a bad tradeoff between performance and security impact. - * Not maintaining proper size of information in the token - possibly adding huge performance impact on memory consumption leading to the server being less prone on the availability front. - * Not being aware or following general security best practices like enforcing Multi Factor Authentication or certain password entropy. + * Using wildcards (*) for redirect URL validation. As OAuth2 is based on HTTP redirects it is a critical part of the core security model to very strictly validate allowed URIs. + * Disabling or not enabling certain features like password validation, brute force attacks, event logging etc. + * Not updating the server and not keeping track or keeping up with CVEs. + * Taking password hashing iterations to extreme - either reducing or increasing too much. Making a bad tradeoff between performance and security impact. + * Not maintaining proper size of information in the token - possibly adding huge performance impact on memory consumption leading to the server being less prone on the availability front. + * Not being aware or following general security best practices like enforcing Multi Factor Authentication or certain password entropy. * Not limiting the token audience and the scope of applications to prevent API misuse. -* OAuth 2.0 and OpenID Connect area is moving ahead. +* OAuth 2.0 and OpenID Connect area is moving ahead. * [https://aaronparecki.com/2019/12/12/21/its-time-for-oauth-2-dot-1](https://aaronparecki.com/2019/12/12/21/its-time-for-oauth-2-dot-1) * [https://aaronparecki.com/2020/03/11/14/oauth-2-1](https://aaronparecki.com/2020/03/11/14/oauth-2-1) - * Both applications and Keycloak need to be monitored and updated on an ongoing basis to follow current best practices and new additions or recommendations. + * Both applications and Keycloak need to be monitored and updated on an ongoing basis to follow current best practices and new additions or recommendations. -## +## **Secure Development Practices** * Without tests and documentation, any code does not get merged. -* PR reviews by senior maintainers and successful CI runs are required for merging. This at times leads to longer [PR merging times and a longer review queue](https://github.com/keycloak/keycloak/pulls). With current project size and adoption in the industry it is a balancing act. -* All key features are required to first get discussed and reviewed in community channels prior to implementation work otherwise PRs won’t get accepted. +* PR reviews by senior maintainers and successful CI runs are required for merging. This at times leads to longer [PR merging times and a longer review queue](https://github.com/keycloak/keycloak/pulls). With current project size and adoption in the industry it is a balancing act. +* All key features are required to first get discussed and reviewed in community channels prior to implementation work otherwise PRs won’t get accepted. * Example of public design proposal for step up and multifactor authentication improvements: \ [https://github.com/keycloak/keycloak-community/blob/master/design/multi-factor-admin-and-step-up.md](https://github.com/keycloak/keycloak-community/blob/master/design/multi-factor-admin-and-step-up.md) * Design specifications: [https://github.com/keycloak/keycloak-community/tree/master/specifications](https://github.com/keycloak/keycloak-community/tree/master/specifications) * Design proposals: \ [https://github.com/keycloak/keycloak-community/tree/master/design](https://github.com/keycloak/keycloak-community/tree/master/design) * Project goes against NIH mindset and leverages trusted software components and libraries - * It leverages WildFly Application Server as a runtime and closely following latest releases to consume all new patches: [https://wildfly.org](https://wildfly.org/) - * This is upstream technology behind Red Hat Enterprise Application Server with high profile and high scale deployments. - * Whenever possible leverages community collaboration with wider scrutiny. + * It leverages WildFly Application Server as a runtime and closely following latest releases to consume all new patches: [https://wildfly.org](https://wildfly.org/) + * This is upstream technology behind Red Hat Enterprise Application Server with high profile and high scale deployments. + * Whenever possible leverages community collaboration with wider scrutiny. * Latest example is W3C WebAuthn work where Keycloak project teamed up with community behind WebAuthn4J project: - * [https://github.com/webauthn4j/webauthn4j](https://github.com/webauthn4j/webauthn4j) + * [https://github.com/webauthn4j/webauthn4j](https://github.com/webauthn4j/webauthn4j) * Community communication channels * [https://www.keycloak.org/community](https://www.keycloak.org/community) * Dedicated security issue reporting process [https://www.keycloak.org/security.html](https://www.keycloak.org/security.html) * Cloud Native ecosystem standardized on OAuth 2.0/OpenID Connect and JWT tokens. There is no other standard currently being utilized for those use cases. OpenID Connect Authorization Service is a critical component of any deployment in the Cloud Native space. - * Kubernetes embraces Keycloak for API Server security and calls out Keycloak (among other options) in it's documentation. - * Istio Service Mesh embraces OpenID Connect for end user authentication. In Keycloak's community survey, over 60% of claimed deployments were done in Cloud related environments (Kubernetes, OpenShift, Public Cloud, Containers) vs only around 30% were traditional ZIP distribution with JVM. + * Kubernetes embraces Keycloak for API Server security and calls out Keycloak (among other options) in it's documentation. + * Istio Service Mesh embraces OpenID Connect for end user authentication. In Keycloak's community survey, over 60% of claimed deployments were done in Cloud related environments (Kubernetes, OpenShift, Public Cloud, Containers) vs only around 30% were traditional ZIP distribution with JVM. * Existing contributions to the project indicate this - * Keycloak GateKeeper which is a proxy generic OpenID Connect adapter implemented in GoLang has been created mainly to be deployed in a sidecar on Kubernetes. + * Keycloak GateKeeper which is a proxy generic OpenID Connect adapter implemented in GoLang has been created mainly to be deployed in a sidecar on Kubernetes. -## +## **Security Issue Resolution** * Project has a publicly defined process described here: \ [https://www.keycloak.org/security.html](https://www.keycloak.org/security.html) - * Project lead and key maintainers subscribed. + * Project lead and key maintainers subscribed. * Issues are being raised via dedicated mailing list with limited access by key maintainers and triaged -* All lower severity issues are being fixed upstream and rolled into the next release. If applicable fix is being processed under embargo and issue published when release is being made. +* All lower severity issues are being fixed upstream and rolled into the next release. If applicable fix is being processed under embargo and issue published when release is being made. * For most critical issues an exception is being made with a micro release containing necessary patches. * In this case patches are not visible in the public repository until after the release -## +## **Roadmap** * Blog post with project roadmap from September 2019: [https://www.keycloak.org/2019/09/2019-roadmap.html](https://www.keycloak.org/2019/09/2019-roadmap.html) @@ -619,10 +619,10 @@ Keycloak supports OpenID Connect and SAML2 out of the box. There number of addit * Access or funding for CI environment (currently mix of Travis for community and internal RH CI as part of RH-SSO development) * By endorsing Keycloak as a CNCF project we hope to boost integrations with other Cloud Native technologies and enhance collaboration within this ecosystem. -## +## **Appendix** -* CNCF submission: +* CNCF submission: * [https://github.com/cncf/toc/pull/405](https://github.com/cncf/toc/pull/405) * [https://github.com/cncf/toc/issues/406](https://github.com/cncf/toc/issues/406) * Endorsements made as part of [CNCF submission PR](https://github.com/cncf/toc/pull/405): @@ -635,7 +635,7 @@ Keycloak supports OpenID Connect and SAML2 out of the box. There number of addit * "We have been using Keycloak (RedHat SSO) for at least a couple of years if not longer, at **Fresenius Medical Care North America IT Group**. It's been very helpful for us to offer OAuth JWT based authentication to our applications as a facade to our legacy Access Management and Identify Management systems in the back end. I would like to see Keycload pick up more support, so that it can keep up or exceed industry leading solution." * "In **Cloudtrust** ([https://github.com/cloudtrust](https://github.com/cloudtrust)), we are intensively using Keycloak as the core component of our IdP. Our identity provider is offered in SaaS mode, and hosted on a multi-site OKD / OpenShift platform, with high availability as one of the main constraints. Deploying and managing Keycloak in this context is pretty easy, and extending the features in order to cover our specific business needs is really neat. We also had to extend core features (multi-token support, SAML artifact-binding support), and the community is efficient and responsive for discussing the design, and reviewing the PR before merging it into the product. We do continue extending features, and pushing additional core features. We strongly believe that choosing Keycloak is one of the key success factors of our cloud-hosted platform." * "+1 for **U.S Air Force**." - * **Hitachi** : "＋１We are using Keycloak in production for the financial and public sectors to secure API/microservice." "+1 Keycloak is essential to secure API/microserivce by OAuth/OIDC on cloud. Keycloak also has wide range of features to secure API, and keycloak community is very active and friendly, the community accepts proposal other than original members. FYI: Presentations about why keycloak is good to secure APIs, and community is active. + * **Hitachi** : "＋１We are using Keycloak in production for the financial and public sectors to secure API/microservice." "+1 Keycloak is essential to secure API/microserivce by OAuth/OIDC on cloud. Keycloak also has wide range of features to secure API, and keycloak community is very active and friendly, the community accepts proposal other than original members. FYI: Presentations about why keycloak is good to secure APIs, and community is active. * [https://www.slideshare.net/ssuserbeb7c0/apidays-paris-2019-financialgrade-api-securityprofile](https://www.slideshare.net/ssuserbeb7c0/apidays-paris-2019-financialgrade-api-securityprofile) * [https://www.slideshare.net/YuichiNakamura10/implementing-security-requirements-for-banking-api-system-using-open-source-software-oss](https://www.slideshare.net/YuichiNakamura10/implementing-security-requirements-for-banking-api-system-using-open-source-software-oss)" * **NTT Communications** : "+1 Yes, Keycloak is very promising and deserves it. It is easy to use, well-documented, and has enough features to be used in cloud native environment." @@ -654,16 +654,16 @@ Keycloak supports OpenID Connect and SAML2 out of the box. There number of addit * Personal Genome: [https://personalgenomes.ca/auth/realms/PGPCanada/](https://personalgenomes.ca/auth/realms/PGPCanada/) * Red Hat: [https://sso.redhat.com/auth/realms/redhat-external](https://sso.redhat.com/auth/realms/redhat-external) * Usage of Keycloak (as RH-SSO) at Red Hat: [https://developers.redhat.com/blog/2019/02/14/red-hat-sso-high-availability-hybrid-cloud/](https://developers.redhat.com/blog/2019/02/14/red-hat-sso-high-availability-hybrid-cloud/) -* Presentation made to CNCF TOC: [https://docs.google.com/presentation/d/1bijEpuwaaa6jR1D5PAjyW731-j6Xc1TFHJuUh_FwwK8/edit#slide=id.g4215684a04_0_0](https://docs.google.com/presentation/d/1bijEpuwaaa6jR1D5PAjyW731-j6Xc1TFHJuUh_FwwK8/edit#slide=id.g4215684a04_0_0) +* Presentation made to CNCF TOC: [https://docs.google.com/presentation/d/1bijEpuwaaa6jR1D5PAjyW731-j6Xc1TFHJuUh_FwwK8/edit#slide=id.g4215684a04_0_0](https://docs.google.com/presentation/d/1bijEpuwaaa6jR1D5PAjyW731-j6Xc1TFHJuUh_FwwK8/edit#slide=id.g4215684a04_0_0) * Governance: [https://github.com/keycloak/keycloak/blob/master/GOVERNANCE.md](https://github.com/keycloak/keycloak/blob/master/GOVERNANCE.md) * Maintainers: [https://github.com/keycloak/keycloak/blob/master/MAINTAINERS.md](https://github.com/keycloak/keycloak/blob/master/MAINTAINERS.md) -* List of known Adopters: [https://github.com/keycloak/keycloak/blob/master/ADOPTERS.md](https://github.com/keycloak/keycloak/blob/master/ADOPTERS.md) -* Project is aiming to migrate off current architecture based on top of WildFly Application Server. Using Quarkus.io ([https://quarkus.io](https://quarkus.io)) project which would allow compilation of java code into native binaries. When running on JVM bringing in significant footprint and starting time reduction. -* Project is leveraging free [Travis CI](https://github.com/keycloak/keycloak/blob/master/.travis.yml) which has several limitations in the free tier. It leverages the fact that Red Hat when productizing community sources is running a fully fledged CI and testing matrix. This is something aimed to be addressed within CNCF by getting access and funding to a proper CI environment. +* List of known Adopters: [https://github.com/keycloak/keycloak/blob/master/ADOPTERS.md](https://github.com/keycloak/keycloak/blob/master/ADOPTERS.md) +* Project is aiming to migrate off current architecture based on top of WildFly Application Server. Using Quarkus.io ([https://quarkus.io](https://quarkus.io)) project which would allow compilation of java code into native binaries. When running on JVM bringing in significant footprint and starting time reduction. +* Project is leveraging free [Travis CI](https://github.com/keycloak/keycloak/blob/master/.travis.yml) which has several limitations in the free tier. It leverages the fact that Red Hat when productizing community sources is running a fully fledged CI and testing matrix. This is something aimed to be addressed within CNCF by getting access and funding to a proper CI environment. * It is productized by Red Hat into Red Hat Single Sign-On product \ [https://access.redhat.com/products/red-hat-single-sign-on](https://access.redhat.com/products/red-hat-single-sign-on) * Key difference to number of other OpenSource OAuth2/OIDC providers * Lightweight and self contained. Thanks to being JVM based it can run on all platforms. While many competing OpenSource solutions are tight to particular components requiring either particular distribution of Linux or at best Docker to run. * Comes with UI (Admin UI, User Self Service, Authentication/Login/Registration/Consent screens). All those UIs are thin clients to REST APIs. Therefore for any operation either UI or REST API call or CLI can be used. UIs are thin clients in Angular (slowly being rewritten in ReactJS). Many competing solutions require application developers to implement those UIs. - * Little to no code integration. In the majority of other OpenSource solutions you need to implement your own Login/Authentication screens. In Keycloak once you register new OAuth2/OIDC/SAML2 client application you can copy paste piece of JSON and if using one of OOTB adapters (NodeJS, SpringBoot, WildFly) you are done and can enable many features by simply switching configuration in the UI. Essentially if you run it with docker you can provide a high number of typical Access Management features for your application or secure your service in a few minutes. - * Developer and modern token based security for microservices focused. While covering well legacy integrations (custom user store, LDAP, identity brokering from external IdPs) core focus is on easily security Applications, APIs and Services. + * Little to no code integration. In the majority of other OpenSource solutions you need to implement your own Login/Authentication screens. In Keycloak once you register new OAuth2/OIDC/SAML2 client application you can copy paste piece of JSON and if using one of OOTB adapters (NodeJS, SpringBoot, WildFly) you are done and can enable many features by simply switching configuration in the UI. Essentially if you run it with docker you can provide a high number of typical Access Management features for your application or secure your service in a few minutes. + * Developer and modern token based security for microservices focused. While covering well legacy integrations (custom user store, LDAP, identity brokering from external IdPs) core focus is on easily security Applications, APIs and Services. diff --git a/assessments/projects/opa/self-assessment.md b/assessments/projects/opa/self-assessment.md index 954ca9010..c8d66df61 100644 --- a/assessments/projects/opa/self-assessment.md +++ b/assessments/projects/opa/self-assessment.md @@ -8,7 +8,7 @@ April 24th 2019 Robert Ficcaglia (@rficcaglia), Sarah Allen (@ultrasaurus) This document elaborates and explores the design goals for the Open Policy Agent (OPA) -as well as its security analysis to aid in the security assessment by CNCF SIG-Security. +as well as its security analysis to aid in the security assessment by CNCF TAG-Security. ## Overview @@ -32,7 +32,7 @@ required business logic in the underlying software. This practice: * complicates the release process -* makes software policy compliance difficult to audit +* makes software policy compliance difficult to audit * makes it difficult to modify policies @@ -116,7 +116,7 @@ Examples of common use cases for OPA: about to make before it makes them * Access control for data in Ceph, Kafka, Minio, SQL, Elasticsearch - + * OPA provides fine-grained access control over Kafka topics * OPA enables authoring of custom security policies to protect data stored in @@ -496,15 +496,15 @@ API that serves salary data. In English, the policy says that *employees can see their own salary and the salary of any of their reports*. ```ruby -allow { -input.method = "GET" -input.path = ["salary", employee_id] -input.user = employee_id +allow { +input.method = "GET" +input.path = ["salary", employee_id] +input.user = employee_id } - + allow { -input.method = "GET" -input.path = ["salary", employee_id] +input.method = "GET" +input.path = ["salary", employee_id] input.user = data.management_chain[employee_id][_] } ``` diff --git a/assessments/projects/spiffe-spire/self-assessment.md b/assessments/projects/spiffe-spire/self-assessment.md index c7e5e1984..9ce110ae0 100644 --- a/assessments/projects/spiffe-spire/self-assessment.md +++ b/assessments/projects/spiffe-spire/self-assessment.md @@ -8,7 +8,7 @@ Contributors: Evan Gilman (@evan2645), Andrew Jessup, Tyler Julian (@apty), Andr Security Reviewers: Brandon Lum (@lumjjb), Emily Fox (@TheFoxAtWork), Justin Cappos (@JustinCappos) -This document details the design goals and security implications of SPIFFE and SPIRE to aid in the security assessment by CNCF SIG-Security. +This document details the design goals and security implications of SPIFFE and SPIRE to aid in the security assessment by CNCF TAG-Security. ## Metadata @@ -231,7 +231,7 @@ Unlike these other APIs however, the Workload API is platform agnostic, and can To minimize exposure from a key being leaked or compromised, all private keys (and corresponding certificates) are short-lived, rotated frequently and automatically. Private keys are never sent "over the wire", instead, keys are generated on-host by the SPIRE Agent and sent to the workload over a unix domain socket. Workloads are provided with new keys and trust bundles from the Workload API before the corresponding key(s) expire. -### SPIRE Architecture +### SPIRE Architecture ![](docs/image0.png) @@ -465,7 +465,7 @@ Both new and experienced SPIRE users have multiple options to interact with the - Meetings: - - The SPIFFE Spec SIG meets every Thursday. [[Meetings Notes]](https://docs.google.com/document/d/1p2BbRWN_7z6nkBMj-h1mAJAJxxKqNeFiV4IplZ_wU4c) + - The SPIFFE Spec TAG meets every Thursday. [[Meetings Notes]](https://docs.google.com/document/d/1p2BbRWN_7z6nkBMj-h1mAJAJxxKqNeFiV4IplZ_wU4c) - The SPIFFE Technical Steering Committee (TSC) meets the first Wednesday of each month. [[Meeting Notes]](https://docs.google.com/document/d/14Kttz1g-S-DdK0i_0JTjr8LDEImlSvCPT2qRSf6zGSY/edit) @@ -515,7 +515,7 @@ The SPIFFE and SPIRE roadmap are published and maintained at [[https://github.co ## Prior Security Assessment -A security assessment was performed by SIG Security at the request of the CNCF TOC. The information presented in the Security Analysis section of this document is almost in its entirety based on the prior assessment. +A security assessment was performed by TAG Security at the request of the CNCF TOC. The information presented in the Security Analysis section of this document is almost in its entirety based on the prior assessment. ## Case Studies/User Stories diff --git a/design/README.md b/design/README.md index e9a0f4a47..c921878a8 100644 --- a/design/README.md +++ b/design/README.md @@ -1,4 +1,4 @@ -## SIG Security Logos +## TAG Security Logos *Note: GitHub Flavored Markdown used in the Readme doesn't support background colors. The white logos below are displayed on the light grey of tables.* @@ -6,7 +6,7 @@ - + PNG SVG @@ -51,8 +51,8 @@
- -## SIG Security Color Scheme + +## TAG Security Color Scheme
@@ -61,14 +61,14 @@ - + - + @@ -76,7 +76,7 @@ - +
#6F6F7F #474756 #141419#4A6CA4 #389BB2 #85C2D2

@@ -94,13 +94,13 @@ #D81637 #F98903 #F7C906 - +
-## SIG Security Fonts +## TAG Security Fonts ### Gotham Regular (for body text) ### Gotham Bold (for header text) diff --git a/governance/charter.md b/governance/charter.md index 132c72100..99c30334b 100644 --- a/governance/charter.md +++ b/governance/charter.md @@ -116,7 +116,7 @@ focus on a particular technology (such as Kubernetes SIGs) or have a broader mandate (such as government organizations). As a guide to visitors, we maintain the list of groups in the TAG -[README](https://github.com/cncf/sig-security#related-groups). +[README](https://github.com/cncf/tag-security#related-groups). Co-chairs are responsible to ensure periodic cross-group knowledge sharing, which is accomplished by cross-group membership, invitation to present at diff --git a/governance/cncf-projects.md b/governance/cncf-projects.md index 80c5c40a7..e1a4a0d56 100644 --- a/governance/cncf-projects.md +++ b/governance/cncf-projects.md @@ -4,7 +4,7 @@ The CNCF TOC identifies specific project that provide capabilities related to security, including policy, identity, authentication, authorization, auditing, compliance, cost management, etc. -These are known as "Security Providers" and the SIG will prioritize review of +These are known as "Security Providers" and the TAG will prioritize review of each project's annual [security assessment](/assessments). Current list of projects: diff --git a/governance/github.md b/governance/github.md index 318af3806..86bce2c33 100644 --- a/governance/github.md +++ b/governance/github.md @@ -1,24 +1,24 @@ # Github access permissions and administration -Facilitation roles are identified in [github settings](/.github/settings.yml) -which we use for Github admin permissions and managing issues. Write +Facilitation roles are identified in [github settings](/.github/settings.yml) +which we use for Github admin permissions and managing issues. Write permissions are enabled by the [CODEOWNERS](/CODEOWNERS) file. There is typically more process for review and collaboration than is controlled -by access permissions. We expect members to review [governance](/governance) +by access permissions. We expect members to review [governance](/governance) and ask questions by filing a Github issue and/or submit suggested changes via Pull Request if anything is not clear. Chairs have admin privileges and have access to change settings in the Github UI. Except where noted below, changes should be made in the repo files to control access privileges, not in the Github UI (so they are visible to -everyone.) +everyone.) Note: Members of the CNCF TOC and some CNCF staff also have admin access; -however, SIG Roles will be defined transparently using files described below, -and will follow SIG processes in making any changes. +however, TAG Roles will be defined transparently using files described below, +and will follow TAG processes in making any changes. -## Settings file +## Settings file Pull Requests to appoint members to new Roles in [github settings](/.github/settings.yml) must be approved by at least one Chair, along with whatever additional required process is defined in @@ -27,7 +27,7 @@ in the file (that does not require additional access) is noted in a comment. PRs to remove someone from a role must be approved by the person themselves or a majority of Chairs. -## Writing to the main branch +## Writing to the main branch The following settings are controlled in the Github UI by those with admin access. The "master" branch is "protected" (even for admins), with these requirements: diff --git a/governance/paper-process.md b/governance/paper-process.md index 1de7719bf..55a89e062 100644 --- a/governance/paper-process.md +++ b/governance/paper-process.md @@ -12,14 +12,14 @@ If a proposal is made that includes a paper as a deliverable, the proposal needs to ensure that there is a clearly idenitified lead and a well defined paper scope. -The paper scope and topic should be raised in at least one SIG meeting to +The paper scope and topic should be raised in at least one TAG meeting to solicit more volunteers (ideally 4). Interested parties should meet at least once to describe the intent of the paper, & propose a very rough outline to -present to SIG leadership for planning and scheduling as a project. +present to TAG leadership for planning and scheduling as a project. ## Project -Once a SIG Leadership sponsor is assigned to the project, the group should meet +Once a TAG Leadership sponsor is assigned to the project, the group should meet to and agree on a tentative schedule. ### Tentative schedule milestones @@ -123,7 +123,7 @@ the Adjudicators (see below). It should be made public with the permission settings such that suggestions and comments are permitted. The lead will then provide a brief write up of a call to action with a link to the document and the due by date for comments. This write up and corresponding links and details -will be emailed to the CNCF SIG-Security mailing list, at which point we +will be emailed to the CNCF TAG-Security mailing list, at which point we actively solicit public comment. ### Public comment adjudication @@ -144,10 +144,10 @@ the enemy of complete). ### CNCF publishing engagement Once the comments on the paper are adjudicated the paper is ready for -publishing. The SIG Leadership sponsor will work with the CNCF gather resources +publishing. The TAG Leadership sponsor will work with the CNCF gather resources to assist in final edits and conversion to PDF and graphics inclusion (if needed). They can also assist with the conversion to markdown. The paper lead -will work with the SIG Leadership sponsor to review publishing drafts prior to +will work with the TAG Leadership sponsor to review publishing drafts prior to final versioned copy and inclusion in the repo. ### Addition to the repo @@ -169,7 +169,7 @@ in alignment with the original intent: ### Blog publishing and coordination In an effort to increase visibility and awareness of the final product, it is -strongly recommended the paper lead coordinate with SIG leadership to engage the +strongly recommended the paper lead coordinate with TAG leadership to engage the CNCF team for posting a blog to summarize and link to the paper. As community events occur, it is also recommended that the TAG coordinate a submission to community events (presentation) on the paper. diff --git a/governance/presentations.md b/governance/presentations.md index 8abe4921a..467b5559c 100644 --- a/governance/presentations.md +++ b/governance/presentations.md @@ -1,15 +1,15 @@ # Security TAG presentations -Part of the STAG activities include having guest presentations by members of the community. -We welcome any topic related to our mission and charter. Typical topics include projects, -real-world use-cases, challenges or success stories. However, presentations must follow the +Part of the STAG activities include having guest presentations by members of the community. +We welcome any topic related to our mission and charter. Typical topics include projects, +real-world use-cases, challenges or success stories. However, presentations must follow the following guidelines. ## Guidelines -- Presentations are encouraged to expose the SIG to cloud native open source projects, cloud native security concepts, and other cloud native or security groups. +- Presentations are encouraged to expose the TAG to cloud native open source projects, cloud native security concepts, and other cloud native or security groups. - Presentations should fit with [our charter](https://github.com/cncf/tag-security/blob/main/governance/charter.md) -- Presentations should not be scheduled on the Agenda until the issue is filled in and the SIG representative has performed due diligence on the issue +- Presentations should not be scheduled on the Agenda until the issue is filled in and the TAG representative has performed due diligence on the issue - Presentations should abide by the CNCF code of conduct Examples of topics that are within scope: diff --git a/governance/process.md b/governance/process.md index 437fb7130..36d2a8bd5 100644 --- a/governance/process.md +++ b/governance/process.md @@ -8,7 +8,7 @@ line with the [mission and charter](charter.md). ### Proposal process 1. **Raise an Issue:** -[Create an issue](https://github.com/cncf/sig-security/issues/new) +[Create an issue](https://github.com/cncf/tag-security/issues/new) that outlines the problem to be solved. Use the proposal template if you are interested in leading the work, or suggestion template if you would like someone else to lead the effort. If possible, include: @@ -70,7 +70,7 @@ members to vote and indicating the time the vote will close. Only one member from each company should vote. Members will vote by leaving a comment in the Pull Request to indicate their vote for or against. Members will have a week after the vote begins to leave their vote. Quorum is taken to be 2/3 the number -of companies who have been active in the past month (via issue comment or +of companies who have been active in the past month (via issue comment or meeting attendace as recorded in the public minutes). diff --git a/governance/roles.md b/governance/roles.md index 094be2f9a..9e500f648 100644 --- a/governance/roles.md +++ b/governance/roles.md @@ -16,7 +16,7 @@ The following is the current listing of member roles: * [Facilitation Roles](#facilitation-roles) All members are identified in the TAG [README](/readme.md), with annotations -where they hold an additional role. +where they hold an additional role. Members fulfilling any Roles in Security TAG are responsible for understanding and abiding the by the [governance](./) and policies defined in this group. @@ -27,7 +27,7 @@ the repo, but also to any approvals or direction required by their Role. specific areas of the repo or actions on issues where changes require write access. In any case, governance is not enforced by [access permissions](github.md), but rather by members who are expected to thoughtfully consider their actions to -support the group. +support the group. ## Role of members * The primary role of a member is to contribute expertise to the group. @@ -78,7 +78,7 @@ members who cannot attend a specific meeting time. ## Role of technical leads Technical Leads (TLs) expand the bandwidth of the leadership team. Proposals -must have a TL or Chair working as an active sponsor (as detailed in +must have a TL or Chair working as an active sponsor (as detailed in [TAG process](process.md)). The general list of activities for TL are: @@ -93,12 +93,12 @@ TLs are assigned by CNCF Technical Oversight Committee ## Role of chair emeriti -After a [Chair](#role-of-chairs) finishes their term, they transition into a role -of Chair Emeritus. This allows previous Chairs to continue to chime in and provide -valuable context and contributions to the TAG. A Chair Emeritus can assume a role -of a [technical lead](#roles-of-technical-leads), but in doing so, must be active -in communicating with the co-chairs and technical leads (i.e. participating in the -chair/TL slack and meetings). A Chair Emeritus has the same permissions/access as +After a [Chair](#role-of-chairs) finishes their term, they transition into a role +of Chair Emeritus. This allows previous Chairs to continue to chime in and provide +valuable context and contributions to the TAG. A Chair Emeritus can assume a role +of a [technical lead](#roles-of-technical-leads), but in doing so, must be active +in communicating with the co-chairs and technical leads (i.e. participating in the +chair/TL slack and meetings). A Chair Emeritus has the same permissions/access as technical leads. ## Role of project leads @@ -110,8 +110,8 @@ Project Leads are nominated and approved by the following process: 1. Project Lead actively participates in the group, making a proposal or volunteering to take on a project that has been prioritized by the group 1. A Chair or TL nominates a candidate. - 1. The nomination is communicated via a pull request annotating the list of members in the - [TAG README](/README.md) with a link to the issue tracking the project. + 1. The nomination is communicated via a pull request annotating the list of members in the + [TAG README](/README.md) with a link to the issue tracking the project. The nomination is typically open for a week (but may be shorter with LGTM of at least two Chairs). 1. Members are encouraged to review the tracking issue and work together to ensure that the Project Lead is set up for success or suggest alternatives. @@ -165,7 +165,7 @@ and led by a Security Assessment Facilitator, who will: ### Meeting facilitator -The group meetings are an important part of community building and the +The group meetings are an important part of community building and the facilitator ensures a welcoming and inclusive atmosphere. In keeping with these goals, the meeting facilitator has the following responsibilities: * prepares the meeting notes with template and agenda @@ -206,7 +206,7 @@ provide meaningful feedback or helpful references. Members who have contributed regularly, including discussion on multiple PRs and submitting PRs themselves, can volunteer to participate as a member -of the Triage Team. Interested members should first join ` #sig-security-triage` +of the Triage Team. Interested members should first join ` #tag-security-triage` on Slack and flag issues that need attention, ask questions and volunteer to take on process improvement PRs that may arise. @@ -218,7 +218,7 @@ Each member of the Triage Team will: * assign labels to issues. * comment where issues need more detail. * recommend proposals or suggestions for discussion at working session meetings. -* participate on #sig-security-triage slack channel. +* participate on #tag-security-triage slack channel. ### Project teams diff --git a/landscape/README.md b/landscape/README.md index ca4a84ca9..642f9b9fb 100644 --- a/landscape/README.md +++ b/landscape/README.md @@ -13,7 +13,7 @@ good security practices, as well as drawing on the experience of the SAFE WG. ## Landscape Process - [X] Draft [categories](categories.md) -- [ ] Review / Revise categories after whitepaper draft - [issue#138](https://github.com/cncf/sig-security/issues/138) +- [ ] Review / Revise categories after whitepaper draft - [issue#138](https://github.com/cncf/tag-security/issues/138) - [ ] Determine [approach to category mapping](approach.md#mapping) - [ ] Map cloud-native tools into categories (adjusting categories as needed) - [ ] Validate categories and landscape with review by makers and users of diff --git a/past-events.md b/past-events.md index 46abbab70..c6512027b 100644 --- a/past-events.md +++ b/past-events.md @@ -1,22 +1,22 @@ -# Past Events +# Past Events -## KubeCon + CloudNativeCon, Barcelona, Spain, May 20 – 23, 2019 +## KubeCon + CloudNativeCon, Barcelona, Spain, May 20 – 23, 2019 -[issue#127](https://github.com/cncf/sig-security/issues/127) +[issue#127](https://github.com/cncf/tag-security/issues/127) ## KubeCon + CloudNativeCon + Open Source Summit, Shanghai, Jun 24-26, 2019 -[issue#200](https://github.com/cncf/sig-security/issues/200) +[issue#200](https://github.com/cncf/tag-security/issues/200) ## DockerCon, San Francisco, CA, Apr 30 - May 2, 2019 -[issue#151](https://github.com/cncf/sig-security/issues/151) +[issue#151](https://github.com/cncf/tag-security/issues/151) ## KubeCon + CloudNativeCon, North America, Dec 11-13, 2018 -[issue#29](https://github.com/cncf/sig-security/issues/29) +[issue#29](https://github.com/cncf/tag-security/issues/29) ## KubeCon + CloudNativeCon, Shanghai, Nov 14-15, 2018 - [issue#28](https://github.com/cncf/sig-security/issues/28) + [issue#28](https://github.com/cncf/tag-security/issues/28) ## KubeConEU May 2-4, 2018 in Copenhagen, Denmark @@ -25,8 +25,8 @@ https://events.linuxfoundation.org/events/kubecon-cloudnativecon-europe-2018/ [notes](safe_kubecon.md) ### TAG talks -- [CNCF SIG-Security Intro](https://kccnceu19.sched.com/event/OB0K/intro-cncf-security-sig-sarah-allen-jeyappragash-jeyakeerthi-tetrateio) - [slides](https://docs.google.com/presentation/d/1KE2tDDOeEOXQLF6hSrAuQLn4z25O_jeHIeAVE4CB-VI/edit#slide=id.gc6fa3c898_0_70) | [video](https://www.youtube.com/watch?v=XD89-v3oWPE) -- [CNCF SIG-Security Deep Dive](https://kccnceu19.sched.com/event/Oscd/deep-dive-cncf-security-sig-justin-cappos-new-york-university-zhipeng-huang-huawei) - [slides](https://docs.google.com/presentation/d/18nzXspPuRDRKfGUSI1ogFHmUOP_XHS78nz-0uTG9Ogs/edit?usp=sharing) | [video](https://www.youtube.com/watch?v=EF3nl80kpm4) +- [CNCF TAG-Security Intro](https://kccnceu19.sched.com/event/OB0K/intro-cncf-security-tag-sarah-allen-jeyappragash-jeyakeerthi-tetrateio) - [slides](https://docs.google.com/presentation/d/1KE2tDDOeEOXQLF6hSrAuQLn4z25O_jeHIeAVE4CB-VI/edit#slide=id.gc6fa3c898_0_70) | [video](https://www.youtube.com/watch?v=XD89-v3oWPE) +- [CNCF TAG-Security Deep Dive](https://kccnceu19.sched.com/event/Oscd/deep-dive-cncf-security-tag-justin-cappos-new-york-university-zhipeng-huang-huawei) - [slides](https://docs.google.com/presentation/d/18nzXspPuRDRKfGUSI1ogFHmUOP_XHS78nz-0uTG9Ogs/edit?usp=sharing) | [video](https://www.youtube.com/watch?v=EF3nl80kpm4) - [Inside CNCF Project Security Reviews](https://kccnceu19.sched.com/event/MPdf/inside-the-cncf-project-security-reviews-justin-cormack-docker) - [video](https://www.youtube.com/watch?v=0BkKpsrUo5k) ### Misc security-related talks @@ -45,32 +45,32 @@ https://events.linuxfoundation.org/events/kubecon-cloudnativecon-europe-2018/

Click to view list -* [2019-09-25 CNCF SIG-Security Meeting](https://docs.google.com/document/d/170y5biX9k95hYRwprITprG6Mc9xD5glVn-4mB2Jmi2g/edit) -* [2019-09-18 CNCF SIG-Security Meeting](https://docs.google.com/document/d/170y5biX9k95hYRwprITprG6Mc9xD5glVn-4mB2Jmi2g/edit) -* [2019-09-11 CNCF SIG-Security Meeting](https://docs.google.com/document/d/170y5biX9k95hYRwprITprG6Mc9xD5glVn-4mB2Jmi2g/edit) -* [2019-09-04 CNCF SIG-Security Meeting](https://docs.google.com/document/d/170y5biX9k95hYRwprITprG6Mc9xD5glVn-4mB2Jmi2g/edit) -* [2019-08-28 CNCF SIG-Security Meeting](https://docs.google.com/document/d/170y5biX9k95hYRwprITprG6Mc9xD5glVn-4mB2Jmi2g/edit) -* [2019-08-21 CNCF SIG-Security Meeting](https://docs.google.com/document/d/170y5biX9k95hYRwprITprG6Mc9xD5glVn-4mB2Jmi2g/edit) -* [2019-08-14 CNCF SIG-Security Meeting](https://docs.google.com/document/d/170y5biX9k95hYRwprITprG6Mc9xD5glVn-4mB2Jmi2g/edit) -* [2019-08-07 CNCF SIG-Security Meeting](https://docs.google.com/document/d/170y5biX9k95hYRwprITprG6Mc9xD5glVn-4mB2Jmi2g/edit) -* [2019-07-31 CNCF SIG-Security Meeting](https://docs.google.com/document/d/170y5biX9k95hYRwprITprG6Mc9xD5glVn-4mB2Jmi2g/edit) -* [2019-07-24 CNCF SIG-Security Meeting](https://docs.google.com/document/d/170y5biX9k95hYRwprITprG6Mc9xD5glVn-4mB2Jmi2g/edit) -* [2019-07-17 CNCF SIG-Security Meeting](https://docs.google.com/document/d/170y5biX9k95hYRwprITprG6Mc9xD5glVn-4mB2Jmi2g/edit) -* [2019-07-10 CNCF SIG-Security Meeting](https://docs.google.com/document/d/170y5biX9k95hYRwprITprG6Mc9xD5glVn-4mB2Jmi2g/edit) -* [2019-07-03 CNCF SIG-Security Meeting](https://docs.google.com/document/d/170y5biX9k95hYRwprITprG6Mc9xD5glVn-4mB2Jmi2g/edit) -* [2019-06-26 CNCF SIG-Security Meeting](https://docs.google.com/document/d/170y5biX9k95hYRwprITprG6Mc9xD5glVn-4mB2Jmi2g/edit) -* [2019-06-19 CNCF SIG-Security Meeting](https://docs.google.com/document/d/170y5biX9k95hYRwprITprG6Mc9xD5glVn-4mB2Jmi2g/edit) -* [2019-06-12 CNCF SIG-Security Meeting](https://docs.google.com/document/d/170y5biX9k95hYRwprITprG6Mc9xD5glVn-4mB2Jmi2g/edit) -* [2019-06-05 CNCF SIG-Security Meeting](https://docs.google.com/document/d/170y5biX9k95hYRwprITprG6Mc9xD5glVn-4mB2Jmi2g/edit) -* [2019-05-29 CNCF SIG-Security Meeting](https://docs.google.com/document/d/170y5biX9k95hYRwprITprG6Mc9xD5glVn-4mB2Jmi2g/edit) -* 2019-05-22 CNCF SIG-Security Meeting - No Meeting due to KubeCon Europe -* [2019-05-15 CNCF SIG-Security Meeting](https://docs.google.com/document/d/170y5biX9k95hYRwprITprG6Mc9xD5glVn-4mB2Jmi2g/edit) - OPA with SAFE Presentation Framework -* [2019-05-08 CNCF SIG-Security Meeting](https://docs.google.com/document/d/170y5biX9k95hYRwprITprG6Mc9xD5glVn-4mB2Jmi2g/edit) +* [2019-09-25 CNCF TAG-Security Meeting](https://docs.google.com/document/d/170y5biX9k95hYRwprITprG6Mc9xD5glVn-4mB2Jmi2g/edit) +* [2019-09-18 CNCF TAG-Security Meeting](https://docs.google.com/document/d/170y5biX9k95hYRwprITprG6Mc9xD5glVn-4mB2Jmi2g/edit) +* [2019-09-11 CNCF TAG-Security Meeting](https://docs.google.com/document/d/170y5biX9k95hYRwprITprG6Mc9xD5glVn-4mB2Jmi2g/edit) +* [2019-09-04 CNCF TAG-Security Meeting](https://docs.google.com/document/d/170y5biX9k95hYRwprITprG6Mc9xD5glVn-4mB2Jmi2g/edit) +* [2019-08-28 CNCF TAG-Security Meeting](https://docs.google.com/document/d/170y5biX9k95hYRwprITprG6Mc9xD5glVn-4mB2Jmi2g/edit) +* [2019-08-21 CNCF TAG-Security Meeting](https://docs.google.com/document/d/170y5biX9k95hYRwprITprG6Mc9xD5glVn-4mB2Jmi2g/edit) +* [2019-08-14 CNCF TAG-Security Meeting](https://docs.google.com/document/d/170y5biX9k95hYRwprITprG6Mc9xD5glVn-4mB2Jmi2g/edit) +* [2019-08-07 CNCF TAG-Security Meeting](https://docs.google.com/document/d/170y5biX9k95hYRwprITprG6Mc9xD5glVn-4mB2Jmi2g/edit) +* [2019-07-31 CNCF TAG-Security Meeting](https://docs.google.com/document/d/170y5biX9k95hYRwprITprG6Mc9xD5glVn-4mB2Jmi2g/edit) +* [2019-07-24 CNCF TAG-Security Meeting](https://docs.google.com/document/d/170y5biX9k95hYRwprITprG6Mc9xD5glVn-4mB2Jmi2g/edit) +* [2019-07-17 CNCF TAG-Security Meeting](https://docs.google.com/document/d/170y5biX9k95hYRwprITprG6Mc9xD5glVn-4mB2Jmi2g/edit) +* [2019-07-10 CNCF TAG-Security Meeting](https://docs.google.com/document/d/170y5biX9k95hYRwprITprG6Mc9xD5glVn-4mB2Jmi2g/edit) +* [2019-07-03 CNCF TAG-Security Meeting](https://docs.google.com/document/d/170y5biX9k95hYRwprITprG6Mc9xD5glVn-4mB2Jmi2g/edit) +* [2019-06-26 CNCF TAG-Security Meeting](https://docs.google.com/document/d/170y5biX9k95hYRwprITprG6Mc9xD5glVn-4mB2Jmi2g/edit) +* [2019-06-19 CNCF TAG-Security Meeting](https://docs.google.com/document/d/170y5biX9k95hYRwprITprG6Mc9xD5glVn-4mB2Jmi2g/edit) +* [2019-06-12 CNCF TAG-Security Meeting](https://docs.google.com/document/d/170y5biX9k95hYRwprITprG6Mc9xD5glVn-4mB2Jmi2g/edit) +* [2019-06-05 CNCF TAG-Security Meeting](https://docs.google.com/document/d/170y5biX9k95hYRwprITprG6Mc9xD5glVn-4mB2Jmi2g/edit) +* [2019-05-29 CNCF TAG-Security Meeting](https://docs.google.com/document/d/170y5biX9k95hYRwprITprG6Mc9xD5glVn-4mB2Jmi2g/edit) +* 2019-05-22 CNCF TAG-Security Meeting - No Meeting due to KubeCon Europe +* [2019-05-15 CNCF TAG-Security Meeting](https://docs.google.com/document/d/170y5biX9k95hYRwprITprG6Mc9xD5glVn-4mB2Jmi2g/edit) - OPA with SAFE Presentation Framework +* [2019-05-08 CNCF TAG-Security Meeting](https://docs.google.com/document/d/170y5biX9k95hYRwprITprG6Mc9xD5glVn-4mB2Jmi2g/edit) * [2019-04-12 SAFE Meeting](https://docs.google.com/document/d/1WLnEErqODywjkQVTAESpwK8pgIbxsNDp6SqOtw3kjlk/edit) * [2019-04-11 SAFE Meeting](https://docs.google.com/document/d/1WLnEErqODywjkQVTAESpwK8pgIbxsNDp6SqOtw3kjlk/edit) - Working Session * [2019-04-05 SAFE Meeting](https://docs.google.com/document/d/1WLnEErqODywjkQVTAESpwK8pgIbxsNDp6SqOtw3kjlk/edit) - Google Open Source Project Onboarding * [2019-04-04 SAFE Meeting](https://docs.google.com/document/d/1WLnEErqODywjkQVTAESpwK8pgIbxsNDp6SqOtw3kjlk/edit) - Working Session -* [2019-03-29 SAFE Meeting](https://docs.google.com/document/d/1WLnEErqODywjkQVTAESpwK8pgIbxsNDp6SqOtw3kjlk/edit) - Revised presentation framework with in-toto (OPA, Kamus, TOC invited) +* [2019-03-29 SAFE Meeting](https://docs.google.com/document/d/1WLnEErqODywjkQVTAESpwK8pgIbxsNDp6SqOtw3kjlk/edit) - Revised presentation framework with in-toto (OPA, Kamus, TOC invited) * [2019-03-28 SAFE Meeting](https://docs.google.com/document/d/1WLnEErqODywjkQVTAESpwK8pgIbxsNDp6SqOtw3kjlk/edit) - Working Session * [2019-03-22 SAFE Meeting](https://docs.google.com/document/d/1WLnEErqODywjkQVTAESpwK8pgIbxsNDp6SqOtw3kjlk/edit) * [2019-03-22 SAFE Meeting](https://docs.google.com/document/d/1WLnEErqODywjkQVTAESpwK8pgIbxsNDp6SqOtw3kjlk/edit) - SAFE Whitepaper Working Session diff --git a/policy/overview-policy-formal-verification.md b/policy/overview-policy-formal-verification.md index e8b8c6a82..1c2c153f4 100644 --- a/policy/overview-policy-formal-verification.md +++ b/policy/overview-policy-formal-verification.md @@ -5,142 +5,142 @@ To borrow from an AWS paper [[0]], the origin of this discussion is: > The security challenge for many ... is becoming one of reasoning about > static policies for their dynamic systems. Cloud [users] want a tool that -> allows them to check policy configurations based on their security -> requirements. - -Let's first define what I mean by "verification". In simplest terms it is a -means to tell that a program was built as _intended_. To say if the -appropriate program was built for a particular job requires "validation". -Verification is what I attempt to formalize, whereas validation relies on -testing and review. In short, I can formally verify whether a security policy -does what I intended; I still must validate whether what I intended in the -context of all possible attacks stops attackers. For example, I might -construct and formally verify a bucket access policy that restricts access to +> allows them to check policy configurations based on their security +> requirements. + +Let's first define what I mean by "verification". In simplest terms it is a +means to tell that a program was built as _intended_. To say if the +appropriate program was built for a particular job requires "validation". +Verification is what I attempt to formalize, whereas validation relies on +testing and review. In short, I can formally verify whether a security policy +does what I intended; I still must validate whether what I intended in the +context of all possible attacks stops attackers. For example, I might +construct and formally verify a bucket access policy that restricts access to data, but then put the access token in a public github repo for anyone to use. OVERVIEW DIAGRAM [[2]] ![OVERVIEW DIAGRAM](overview-formal-verification.png "CONCETPTUAL OVERVIEW") -## Definitions and Terms +## Definitions and Terms -"Formal" means I have something symbolic, i.e. mathematical formulae. Of -course, using human prose, or diagrams, or pictures, I can do both -verification and validation of a sort today, but machines cannot completly +"Formal" means I have something symbolic, i.e. mathematical formulae. Of +course, using human prose, or diagrams, or pictures, I can do both +verification and validation of a sort today, but machines cannot completly automate the proof of correctness from these less specific notations (not yet). -It is assumed that machine proofs are more reliable than manual processes, -especially when such manual processes are ad hoc and the proofs are highly -complex. Even if/when AI exists where diagrams go in and proof comes out, it -would probably convert diagrams to intermediate symbolic formulae. - -Formal verification is discussed here in the context of security policy -(formal verification could be used to verify other types of security -properties). A "security policy" is the statement of human _intent_ for a +It is assumed that machine proofs are more reliable than manual processes, +especially when such manual processes are ad hoc and the proofs are highly +complex. Even if/when AI exists where diagrams go in and proof comes out, it +would probably convert diagrams to intermediate symbolic formulae. + +Formal verification is discussed here in the context of security policy +(formal verification could be used to verify other types of security +properties). A "security policy" is the statement of human _intent_ for a system that constraints: * who can use it (human or machine actors) * what operations are allowed by those actors -* what resources can be accessed or modified by those operations (leaving +* what resources can be accessed or modified by those operations (leaving resources undefined, could be services, VMs, data) * which capabilities are required by those operations -As such, a security policy is simply a collection of intended constraints on -the above that can be expressed in human language (possibly supplemented by -diagrams and other notation), ignoring any particular format or framework. We +As such, a security policy is simply a collection of intended constraints on +the above that can be expressed in human language (possibly supplemented by +diagrams and other notation), ignoring any particular format or framework. We haven't bound the intent to any particular software implementation yet. -Next we need a "specification" that refines this intent (security policy -constraints) into something machine readable, but not yet as specific as a -logic language. I like specification here instead of model, since I think -model is overloaded with myriad meanings to practitioners of different -methodologies. I've seen "contract" also used. +Next we need a "specification" that refines this intent (security policy +constraints) into something machine readable, but not yet as specific as a +logic language. I like specification here instead of model, since I think +model is overloaded with myriad meanings to practitioners of different +methodologies. I've seen "contract" also used. -The specification encodes the desired constraints as properties that can be -evaluated to make a decision about a given behavior/operation in the cloud +The specification encodes the desired constraints as properties that can be +evaluated to make a decision about a given behavior/operation in the cloud native system. -A "specification parameter" is a variable declared in the specification. +A "specification parameter" is a variable declared in the specification. -"Context" are inputs to the policy used during policy evaluation; context -binds specification parameters to particular values. For example AWS considers -the Context to be "the principal making the request, the resource being -requested, and the specific action being requested." [[0]]. Another -example might be a snapshot of the network. Or an API call with the values -passed +"Context" are inputs to the policy used during policy evaluation; context +binds specification parameters to particular values. For example AWS considers +the Context to be "the principal making the request, the resource being +requested, and the specific action being requested." [[0]]. Another +example might be a snapshot of the network. Or an API call with the values +passed into the API. -With a policy intent, the specification, and context defined we can now -construct an actual security policy "encoding". This is probably what most -devops users would imagine when talking about a _security policy_. It's a -specific language expression, e.g. JSON or Rego or yaml, that encodes the -desired system properties in expressions that software can process and make +With a policy intent, the specification, and context defined we can now +construct an actual security policy "encoding". This is probably what most +devops users would imagine when talking about a _security policy_. It's a +specific language expression, e.g. JSON or Rego or yaml, that encodes the +desired system properties in expressions that software can process and make _allow_ or _deny_ or other types of decisions. -A "policy configuration" is a combination of a policy encoding (e.g. a -particular set of parameterized expressions to be validated) combined with the -context/inputs fulfilling the parameters that the specification allows. +A "policy configuration" is a combination of a policy encoding (e.g. a +particular set of parameterized expressions to be validated) combined with the +context/inputs fulfilling the parameters that the specification allows. -ASIDE: the specification can be distinct and separate from the policy encoding -itself, though some like AWS Zelkova seem to use the policy language itself -_as_ the specification language: "The property to be verified is specified in -the policy language itself, eliminating the need for a different specification +ASIDE: the specification can be distinct and separate from the policy encoding +itself, though some like AWS Zelkova seem to use the policy language itself +_as_ the specification language: "The property to be verified is specified in +the policy language itself, eliminating the need for a different specification or formalism for properties." [[0]] ## Policy Formal Verification -Once we define the intent, the specification and parameters, the policy -encoding, and context/inputs, we now desire a tool that can query the policy -configurations (policy+context) with respect to a parameterized specification -(intent expressed as properties) so we can verify whether the policy -configurations meet the specified security requirements for a particular -system state. In other words, can we _prove_ that the constraint(s), -specification(s), encoded properties, and input(s) for a given decision(s) are -consistent and valid, ie correct, with respect to the intent(s)? And do it at +Once we define the intent, the specification and parameters, the policy +encoding, and context/inputs, we now desire a tool that can query the policy +configurations (policy+context) with respect to a parameterized specification +(intent expressed as properties) so we can verify whether the policy +configurations meet the specified security requirements for a particular +system state. In other words, can we _prove_ that the constraint(s), +specification(s), encoded properties, and input(s) for a given decision(s) are +consistent and valid, ie correct, with respect to the intent(s)? And do it at scale, reliably, in a protean operating environment? This is where formal verification helps. To quote[[2]]: -> "With the translations from ideal concepts and from the physical world into -formal logic, that we can use the tool of formal proof ... we are able to make -formal correctness guarantees with an absolute degree of assurance. Even in -the less than perfect real world, with machine-checked proof we can achieve a -level of assurance about our formal statements that surpasses our confidence +> "With the translations from ideal concepts and from the physical world into +formal logic, that we can use the tool of formal proof ... we are able to make +formal correctness guarantees with an absolute degree of assurance. Even in +the less than perfect real world, with machine-checked proof we can achieve a +level of assurance about our formal statements that surpasses our confidence in mathematical theorems which we base all of physics and engineering on." ![POLICY FORMAL VERIFICATION](PolicyFormalVerificationDiagram.png "POLICY FORMAL VERIFICATION") -As others have observed [[4]], there exist several formal methods -to prove the correctness with respect to constraints, specification, -properties and inputs. _The trade-off is between the expressiveness of the -logic and the degree of automation_. For example it is difficult to write the -required logical formulae for SAT solvers, and difficult to understand the -resulting formalisations, but SAT solvers provide a high degree of automation -[[10]]. SMT solvers provide a good balance between speed and -expressiveness, providing decision procedures for bitvectors, arithmetic, and -arrays, though SMT solvers have limitations [[11]],[[12]]. -Zermelo-Fraenkel Set Theory (e.g. [Z notation](https://en.wikipedia.org/wiki/Z_notation) ) -or Higher-Order Logic[[13]] make it easier to express properties -and specifications precisely and in a readable way, but they require human -effort and expertise in performing the interactive, machine-assisted and -machine-checked proof. Intermediate examples include model checking -(algorithmic verifcation) [[14]] and automated first-order theorem +As others have observed [[4]], there exist several formal methods +to prove the correctness with respect to constraints, specification, +properties and inputs. _The trade-off is between the expressiveness of the +logic and the degree of automation_. For example it is difficult to write the +required logical formulae for SAT solvers, and difficult to understand the +resulting formalisations, but SAT solvers provide a high degree of automation +[[10]]. SMT solvers provide a good balance between speed and +expressiveness, providing decision procedures for bitvectors, arithmetic, and +arrays, though SMT solvers have limitations [[11]],[[12]]. +Zermelo-Fraenkel Set Theory (e.g. [Z notation](https://en.wikipedia.org/wiki/Z_notation) ) +or Higher-Order Logic[[13]] make it easier to express properties +and specifications precisely and in a readable way, but they require human +effort and expertise in performing the interactive, machine-assisted and +machine-checked proof. Intermediate examples include model checking +(algorithmic verifcation) [[14]] and automated first-order theorem proving (deductive verifcation)[[15]],[[16]],[[17]],[[18]]. ### Trivial Example -Let's consider a hypothetical trivial use case: a Kubernetes operator has an -Admission Control policy intent, e.g. don't allow pods with label "foo" in -namespace "bar", and wants to reliably verify their encoded policy does that -(and also ensure it _does_ allow a "foo" pod to deploy into other namespaces, -eg "baz"). +Let's consider a hypothetical trivial use case: a Kubernetes operator has an +Admission Control policy intent, e.g. don't allow pods with label "foo" in +namespace "bar", and wants to reliably verify their encoded policy does that +(and also ensure it _does_ allow a "foo" pod to deploy into other namespaces, +eg "baz"). This is expressed in our specification as something like: -"foo" in pod.labels & node.namespace = "bar" => +"foo" in pod.labels & node.namespace = "bar" => node.namespace = "bar" | ( "bar" not in node.namespaces & node.namespace = Nil) This is translated to boolean variables: ~p1 | ~p2 | p3 | (p4 & p5) -A theory solver checks its satisfiability given values for the context of the +A theory solver checks its satisfiability given values for the context of the system with its existing policies and labels and namespaces: UNSAT @@ -154,147 +154,147 @@ UNSAT * "bar" in node.namespaces * pod.node.namespace = Nil -In the above example, the parameterized specification describes how the -kubernetes pod and namespace topology must be constrained. Using this, the -desired tool can answer yes/no questions about specific inputs, or perhaps -provide an list answer of all pod-namespace combinations allowed or denied by -the policy. As the scale and complexity of the Kubernetes cluster(s) grows, -with dozens/hundreds of labels and namespaces and many possibly conflicting -policies deployed by other users for pod admission control, these questions +In the above example, the parameterized specification describes how the +kubernetes pod and namespace topology must be constrained. Using this, the +desired tool can answer yes/no questions about specific inputs, or perhaps +provide an list answer of all pod-namespace combinations allowed or denied by +the policy. As the scale and complexity of the Kubernetes cluster(s) grows, +with dozens/hundreds of labels and namespaces and many possibly conflicting +policies deployed by other users for pod admission control, these questions become increasingly more difficult to process manually, with any confidence. ## More Use Cases/Stories -These are some example ideas I've heard in various calls and threads that the +These are some example ideas I've heard in various calls and threads that the tool should improve if not completely automate: -* Human operator wants to ask questions about users and resources under a +* Human operator wants to ask questions about users and resources under a policy or set of policies: * Is resource X accessible by a particular user Alice? - * Can any user deploy to this namespace? - * is one policy less-or-equally permissive than another? put another way, - check whether a policy is over or under-constrained with respect to another + * Can any user deploy to this namespace? + * is one policy less-or-equally permissive than another? put another way, + check whether a policy is over or under-constrained with respect to another one. - * Did I deny access to authorized users unintentionally? If so which ones? + * Did I deny access to authorized users unintentionally? If so which ones? Which policy did that? * Operator wants to ask questions about the network: - * Is access to a resource allowed from a certain set (or all, or empty set) - of IP addresses? If so which? If not which policy is granting access to + * Is access to a resource allowed from a certain set (or all, or empty set) + of IP addresses? If so which? If not which policy is granting access to which IPs? Which are blocking access? - * Are there any NetworkPolicies, Endpoints, or Pods in namespace ‘Web’ that + * Are there any NetworkPolicies, Endpoints, or Pods in namespace ‘Web’ that are labeled as ‘Bastion’? - * All nodes/pods in the subnet “Web” can access all network nodes in the + * All nodes/pods in the subnet “Web” can access all network nodes in the subnet “Database”? - * only nodes/pods that have the label "dmz" have port 22 (SSH) accessible + * only nodes/pods that have the label "dmz" have port 22 (SSH) accessible from the internet. -* Human needs to show a reviewer/auditor that there are no missing or +* Human needs to show a reviewer/auditor that there are no missing or superfluous policies. -* Human gets a particular response from the combined set of policies (or one -very large policy) under test (ACCEPT/DENY) and wants to see the particular +* Human gets a particular response from the combined set of policies (or one +very large policy) under test (ACCEPT/DENY) and wants to see the particular policies or policy rules responsible for the response. -* Human wants to understand the impact of changing policy P to P'. Enumerate +* Human wants to understand the impact of changing policy P to P'. Enumerate the users or resources that will be affected and how. -* CI/CD or daemon running software wants to continuously monitor a stream of -configuration changes and validate the updated configurations against their +* CI/CD or daemon running software wants to continuously monitor a stream of +configuration changes and validate the updated configurations against their respective specifications, * report and alert on the validation - * Alerts raised should contains detailed difference info that can be used to + * Alerts raised should contains detailed difference info that can be used to deduce the changes needed to correct the policy configuration -* "return to the user a concrete request context using the model generated by -the SMT solver when performing the check. The concrete request context will +* "return to the user a concrete request context using the model generated by +the SMT solver when performing the check. The concrete request context will provide information to the user on why a certain check passed or failed." [[0]] -* "support for recommending policy repairs in cases when the policy fails a +* "support for recommending policy repairs in cases when the policy fails a certain check." [[0]] * provide a "defense-in-depth-o-meter" Considering the above "policy" examples: -* it might be a policy to grant or deny user access to a resource in a multi-tenant +* it might be a policy to grant or deny user access to a resource in a multi-tenant cluster, -* or it might be a policy that requires certain syscall activity to be +* or it might be a policy that requires certain syscall activity to be monitored on some pods with certain labels, -* or it might be a policy that says network traffic that is regulated by PCI +* or it might be a policy that says network traffic that is regulated by PCI or HIPAA should be read-only to some microservices but writeable by others, -* or it might be a policy that specifies some alert action to be triggered +* or it might be a policy that specifies some alert action to be triggered when a given audit event occurs; * deny microservices granting unrestricted access to data stores * deny write requests to data stores that do not have encryption configured * deny deployments of load balancers that do not use https traffic -* check compliance whenever a new resource is created or the policy attached -to it is changed. +* check compliance whenever a new resource is created or the policy attached +to it is changed. -An ongoing task in this effort is to catalog the fuller set of interesting use -cases/stories and map the enumeration of those to specific features of the +An ongoing task in this effort is to catalog the fuller set of interesting use +cases/stories and map the enumeration of those to specific features of the verification tool. ## What Can I Do Today? -As a devops person responsible for answering the question "are we secure?" -today, there are some things one can do today given time, money, people, and -focus. These have been built in some form or another already, so I could +As a devops person responsible for answering the question "are we secure?" +today, there are some things one can do today given time, money, people, and +focus. These have been built in some form or another already, so I could modify or improve existing examples: -* look for patterns in policies, e.g., the use of a wildcard that makes -resources publicly accessible. -* attempt to explicitly enumerate all possible requests to a policy (test +* look for patterns in policies, e.g., the use of a wildcard that makes +resources publicly accessible. +* attempt to explicitly enumerate all possible requests to a policy (test generator, record/playback) -* use commercial tools or cloud-specific tools provided by my public cloud +* use commercial tools or cloud-specific tools provided by my public cloud host (Zelkova, SecGuru) -* define a mapping/translation from a given policy to a logic notation and -then convert that to boolean (SAT) or more complex formulas (SMT) and then +* define a mapping/translation from a given policy to a logic notation and +then convert that to boolean (SAT) or more complex formulas (SMT) and then check if the formulas are satisfiable. * eg encode policies as bit vectors and use [Z3 solver](https://rise4fun.com/z3/) [[1]] * eg use FormuLog as the specification and use [Z3 solver](https://rise4fun.com/z3/) [[6]] * eg use Souffle to evaluate a Datalog specification as discussed in [[5]] -* model policy as a workflow, automata, or FSM (e.g. PrT nets) and use -temporal logic [[24]], [[25]], [[26]], [[27]], [[28]], [[29]] +* model policy as a workflow, automata, or FSM (e.g. PrT nets) and use +temporal logic [[24]], [[25]], [[26]], [[27]], [[28]], [[29]] * use graph algorithms [[22]] * read review papers [[23]] -* write up GHIs on Formal Verification, and hope smarter people jump in and -magically make the world a better place :) +* write up GHIs on Formal Verification, and hope smarter people jump in and +magically make the world a better place :) ## Possible Action Items and Next Steps -* We could collect real world policy examples and/or generate test policies to +* We could collect real world policy examples and/or generate test policies to reverse engineer the requirements for policy configuration. -* We could create de novo the security policy requirements by reviewing -existing code and design notes and extracting a more thorough requirements -document that can be translated into some form of a machine readable +* We could create de novo the security policy requirements by reviewing +existing code and design notes and extracting a more thorough requirements +document that can be translated into some form of a machine readable specification. -* Once we have a solid requirements document, we can create a formal -specification for various facets of kubernetes and other CNCF projects and +* Once we have a solid requirements document, we can create a formal +specification for various facets of kubernetes and other CNCF projects and encode the security specification in some symbolic language. - * admission control policy + * admission control policy * RBAC policy * network policy eg Tiros [[3]] -* We can use Z, TLA+, Alloy, Souffle [[4]], Scheme[[20]], [[21]], +* We can use Z, TLA+, Alloy, Souffle [[4]], Scheme[[20]], [[21]], Rego, (modified) datalog, or come up with something new as the specification language -* The human operator can then write a new policy and run a tool that uses the +* The human operator can then write a new policy and run a tool that uses the specifications for various parameterized operations to verify the policy -* Human operator or a tool would somehow need to collect, enumerate, generate, +* Human operator or a tool would somehow need to collect, enumerate, generate, or in some way bind inputs to the parameters of a specification: * eg. LDAP data, namespace list, IP addresses, buckets, keys, CIDRs, etc ## Open Questions, Challenges -* To bootstrap, it is sufficient to formally verify the policy only, or must we first +* To bootstrap, it is sufficient to formally verify the policy only, or must we first formally verify the policy enforcement software (e.g. OPA, CNI plugins, etc)? Or can we "compose" a formal structure within an unverified environment akin to UC [[30]] ? -* bounded or unbounded analysis? unbounded is NP-complete or maybe NP-hard. -Using wildcards is PSPACE-complete but practical [[0]]. +* bounded or unbounded analysis? unbounded is NP-complete or maybe NP-hard. +Using wildcards is PSPACE-complete but practical [[0]]. * ordering constraints on statements in a policy, eg. firewall rules * policy language constructs such as loops or dynamically allocated arrays -* per AWS: solvers seem very sensitive to small changes in the input encoding, -where a quickly solved problem in our domain becomes non-terminating. Yet, the -theory of regular expressions is decidable. how current is this observation? +* per AWS: solvers seem very sensitive to small changes in the input encoding, +where a quickly solved problem in our domain becomes non-terminating. Yet, the +theory of regular expressions is decidable. how current is this observation? Zelkova "solves regular expression problems using the -standard translation to deterministic finite automata (DFAs) via -non-deterministic finite automata (NFAs). It uses Hopcroft’s algorithm for DFA -minimization...treats each regular expression match as an atom...how to -integrate this into the traditional Nelson-Oppen framework?" -* Consider Z3 string support and CVC4 compatible[[7]],[[8]] string +standard translation to deterministic finite automata (DFAs) via +non-deterministic finite automata (NFAs). It uses Hopcroft’s algorithm for DFA +minimization...treats each regular expression match as an atom...how to +integrate this into the traditional Nelson-Oppen framework?" +* Consider Z3 string support and CVC4 compatible[[7]],[[8]] string solvers? * Can we combine theorem provers with symbolic execution techniques [[19]]? -## Author: [@rficcaglia](https://github.com/rficcaglia) +## Author: [@rficcaglia](https://github.com/rficcaglia) ## Thanks To Feedback From: @@ -339,20 +339,20 @@ solvers? ### Historical Note -This started with a Policy-WG call on 6/5/2019 where we discussed how/if -policies might be formally verified, and then subsequent comment and -discussion on https://github.com/cncf/sig-security/issues/196 . +This started with a Policy-WG call on 6/5/2019 where we discussed how/if +policies might be formally verified, and then subsequent comment and +discussion on https://github.com/cncf/tag-security/issues/196 . ### Post-Script -Since the start of this discussion, the [CapitalOne data loss incident](https://news.ycombinator.com/item?id=20565014) -[concretely demonstrates](https://krebsonsecurity.com/2019/08/what-we-can-learn-from-the-capital-one-hack/) -how relatively simple policies...e.g. assign only the minimally necessary -permissions to components ... are [not being adequately enforced in real -world, industrial scale environments](https://news.ycombinator.com/item?id=20568708). -It would be great to have a tool to automate policy proofs when someone wants -a "temporary" monkey patch policy to circumvent the -expected/intended/reviewed/approved policies, both when the change is -proposed, and even if/when it is jammed in for "agile" reasons, to continually -alert of its continued presence so it can be removed in a -timely manner. Say for example an overly permissive WAF policy? +Since the start of this discussion, the [CapitalOne data loss incident](https://news.ycombinator.com/item?id=20565014) +[concretely demonstrates](https://krebsonsecurity.com/2019/08/what-we-can-learn-from-the-capital-one-hack/) +how relatively simple policies...e.g. assign only the minimally necessary +permissions to components ... are [not being adequately enforced in real +world, industrial scale environments](https://news.ycombinator.com/item?id=20568708). +It would be great to have a tool to automate policy proofs when someone wants +a "temporary" monkey patch policy to circumvent the +expected/intended/reviewed/approved policies, both when the change is +proposed, and even if/when it is jammed in for "agile" reasons, to continually +alert of its continued presence so it can be removed in a +timely manner. Say for example an overly permissive WAF policy? ¯\_(ツ)_/¯ diff --git a/roadmap.md b/roadmap.md index 9f644015e..ba31fc888 100644 --- a/roadmap.md +++ b/roadmap.md @@ -7,13 +7,13 @@ * [Completed](completed) ## Overview -Note: SIG-Security was rebranded from SAFE working group. The below roadmap -includes SAFE WG and SIG-Security in its timeline. +Note: TAG-Security was rebranded from SAFE working group. The below roadmap +includes SAFE WG and TAG-Security in its timeline. | | #2 Discover | #3 Describe | #4 Identify | --- | --- | --- | --- | | Artifacts | Personas
Use Cases
Categories | Standards
Common Definitions
Block Architecture | Catalog Projects
Fill in Boxes
Identify Gaps -| Topics | Presentations
SIG members & guests | Standards in Practice
Real World Systems Architecture | Platforms & Products
Tools & Libraries +| Topics | Presentations
TAG members & guests | Standards in Practice
Real World Systems Architecture | Platforms & Products
Tools & Libraries ## Details @@ -41,52 +41,52 @@ includes SAFE WG and SIG-Security in its timeline. ## Upcoming -SIG-Security strives to perform annual planning and quarterly reviews of our +TAG-Security strives to perform annual planning and quarterly reviews of our roadmap plans. The Roadmap planning project board for each annum is a live board and is continually updated. Boards may have cards added which indicate early concepts or needs for discovery, prior to become proposals or projects. -| Year | Board Link | -| --- | --- | -| 2021-2022 | [RoadMap Planning Board](https://github.com/cncf/sig-security/projects/4) | +| Year | Board Link | +| --- | --- | +| 2021-2022 | [RoadMap Planning Board](https://github.com/cncf/tag-security/projects/4) | ### Ongoing efforts -SIG-Security maintains a few activities as regular business. Boards tracking +TAG-Security maintains a few activities as regular business. Boards tracking these items linked below. | Effort | Board Link | Description | | --- | --- | -- | -| CNCF project security reviews | [Security Review Queue](https://github.com/cncf/sig-security/projects/2) | This board is used to manage upcoming and current security reviews and security review related activities. | -| TAG-Security Projects | [Project Tracking Board](https://github.com/cncf/sig-security/projects/1) | This board is used to manage upcoming proposals (backlog) and ongoing projects. | -| Issue Triage | [Triage Board](https://github.com/cncf/sig-security/projects/3) | This board is used to assist the Triage team in managing the queue of issues. | +| CNCF project security reviews | [Security Review Queue](https://github.com/cncf/tag-security/projects/2) | This board is used to manage upcoming and current security reviews and security review related activities. | +| TAG-Security Projects | [Project Tracking Board](https://github.com/cncf/tag-security/projects/1) | This board is used to manage upcoming proposals (backlog) and ongoing projects. | +| Issue Triage | [Triage Board](https://github.com/cncf/tag-security/projects/3) | This board is used to assist the Triage team in managing the queue of issues. | ## Completed | Milestone | Date | Action | --- | --- | --- | -| First Community Translation | 27 Feb 2021 | [Chinese translation of Whitepaper](https://github.com/cncf/sig-security/pull/471) | -| Security Assessments => Reviews | 23 Feb 2021 | Retrospective resulted in [process updates](https://github.com/cncf/sig-security/pull/488) | -| APAC meetings start | 1 Feb 2021 | [Regular meeting time added to README](https://github.com/cncf/sig-security/pull/518) +| First Community Translation | 27 Feb 2021 | [Chinese translation of Whitepaper](https://github.com/cncf/tag-security/pull/471) | +| Security Assessments => Reviews | 23 Feb 2021 | Retrospective resulted in [process updates](https://github.com/cncf/tag-security/pull/488) | +| APAC meetings start | 1 Feb 2021 | [Regular meeting time added to README](https://github.com/cncf/tag-security/pull/518) | Expanded to 5 Tech Leads | 13 Jan 2021 | [TOC Approves](https://lists.cncf.io/g/cncf-toc/topic/79052801#5599) [@ashutosh-narkar](https://github.com/ashutosh-narkar), [@achetal01](https://github.com/achetal01), [@anvega](https://github.com/anvega) | -| Cloud Native Security Whitepaper v1 | 18 Nov 2020 | [Markdown source and images in repo](https://github.com/cncf/sig-security/pull/452) | -| First five security assessments | 21 Oct 2020 | [In-toto, OPA, SPIFFE/SPIRE, Harbor, Keycloak](https://github.com/cncf/sig-security/issues/167) | -| First chair rotation | 15 Sep 2020 | [TOC approves](https://lists.cncf.io/g/cncf-toc/topic/77001316#5303) [@TheFoxAtWork](https://github.com/TheFoxAtWork) with new [chair proposal process](https://github.com/cncf/sig-security/pull/419/files) +| Cloud Native Security Whitepaper v1 | 18 Nov 2020 | [Markdown source and images in repo](https://github.com/cncf/tag-security/pull/452) | +| First five security assessments | 21 Oct 2020 | [In-toto, OPA, SPIFFE/SPIRE, Harbor, Keycloak](https://github.com/cncf/tag-security/issues/167) | +| First chair rotation | 15 Sep 2020 | [TOC approves](https://lists.cncf.io/g/cncf-toc/topic/77001316#5303) [@TheFoxAtWork](https://github.com/TheFoxAtWork) with new [chair proposal process](https://github.com/cncf/tag-security/pull/419/files) | DoD Kubernetes/Container Security controls proposed | 26 Jun 2020 | LF collaboration with US DoD [merged to DoD repo](https://repo1.dso.mil/dsawg-devsecops/kubernetes-srg/k8-srg-artifacts/-/tree/master/linuxfoundation) | | First Tech Leads | 25 Feb 2020 | [TOC approves](https://lists.cncf.io/g/cncf-toc/topic/71341283#4198) [@lumjjb](https://github.com/lumjjb) [@TheFoxAtWork](https://github.com/TheFoxAtWork) [@JustinCappos](https://github.com/JustinCappos) | -| Security Assessment intake process | 7 Jan 2020 | [Intake process and prioritization](https://github.com/cncf/sig-security/pull/296) | -| First Cloud Native Security Day | 19 Nov 2019 | [Event](https://events19.linuxfoundation.org/events/cloud-native-security-day-2019/) organized by [@mfdii and @TheFoxAtWork](https://github.com/cncf/sig-security/issues/209) | -| Software supply chain catalog | 14 Nov 2019 | [Catalog](https://github.com/cncf/sig-security/pull/284) | -| Updated personas & use cases | 23 Sept 2019 | [Added platform implementer](https://github.com/cncf/sig-security/pull/246) -| Policy formal verification overview | 10 Sept 2019 | [Documentation](https://github.com/cncf/sig-security/pull/242) -| First Security Assessment | May 2019 | [In-toto](https://github.com/cncf/sig-security/pull/202) | +| Security Assessment intake process | 7 Jan 2020 | [Intake process and prioritization](https://github.com/cncf/tag-security/pull/296) | +| First Cloud Native Security Day | 19 Nov 2019 | [Event](https://events19.linuxfoundation.org/events/cloud-native-security-day-2019/) organized by [@mfdii and @TheFoxAtWork](https://github.com/cncf/tag-security/issues/209) | +| Software supply chain catalog | 14 Nov 2019 | [Catalog](https://github.com/cncf/tag-security/pull/284) | +| Updated personas & use cases | 23 Sept 2019 | [Added platform implementer](https://github.com/cncf/tag-security/pull/246) +| Policy formal verification overview | 10 Sept 2019 | [Documentation](https://github.com/cncf/tag-security/pull/242) +| First Security Assessment | May 2019 | [In-toto](https://github.com/cncf/tag-security/pull/202) | | Updated Charter and Governance ratified by CNCF TOC | 7 May 2019 | [New repo](https://github.com/cncf/tag-security/tree/main/governance) | -| First cut security audit guidelines | 2 May 2019 | [Guidelines](https://github.com/cncf/sig-security/pull/125) | -| Moved SAFE WG to CNCF | 15 Apr 2019 | [Repo rename](https://github.com/cncf/sig-security/pull/148) | -| CNCF WG proposal | 21 Aug 2018 | [CNCF SIG-Security charter and roles](https://github.com/cncf/toc/pull/146) | +| First cut security audit guidelines | 2 May 2019 | [Guidelines](https://github.com/cncf/tag-security/pull/125) | +| Moved SAFE WG to CNCF | 15 Apr 2019 | [Repo rename](https://github.com/cncf/tag-security/pull/148) | +| CNCF WG proposal | 21 Aug 2018 | [CNCF TAG-Security charter and roles](https://github.com/cncf/toc/pull/146) | | Policy WG merged | 10 Aug 2018 | [Merging policy WG](https://github.com/cncf/tag-security/blob/main/policy-wg-merging.md) | | First KubeCon Presentations | 2-4 May 2018 | [Intro](https://kccnceu18.sched.com/event/ENw3/safe-wg-intro-jeyappragash-j-j-padmeio-ray-colline-google-any-skill-level) and [deep dive](https://kccnceu18.sched.com/event/ENw5/safe-wg-deep-dive-ray-colline-google-intermediate-skill-level) | -| Personas & use cases | 20 Apr 2018 | [Shared doc into repo markdown](https://github.com/cncf/sig-security/pull/16) -| Initial Commit for SAFE repo | 13 Mar 2018 | [First commit](https://github.com/cncf/sig-security/commit/fe999bd637456ade5e6cc8866d0db4107a0d9778) | +| Personas & use cases | 20 Apr 2018 | [Shared doc into repo markdown](https://github.com/cncf/tag-security/pull/16) +| Initial Commit for SAFE repo | 13 Mar 2018 | [First commit](https://github.com/cncf/tag-security/commit/fe999bd637456ade5e6cc8866d0db4107a0d9778) | | Informal discussions at Kubecon Austin | Dec 2017 | Meeting with CNCF community and gathering feedback | diff --git a/security-whitepaper/README.md b/security-whitepaper/README.md index 0d78e41ff..ba3bc54da 100644 --- a/security-whitepaper/README.md +++ b/security-whitepaper/README.md @@ -1,29 +1,29 @@ # Cloud Native Security Whitepaper -## About +## About The Cloud Native Security Whitepaper is a TAG-Security effort to ensure the cloud native community has access to information about building, distributing, deploying, and running secure cloud native capabilities. -## Updates to the paper +## Updates to the paper -The Cloud Native Security Whitepaper (CNSWP) is intended to be a living -document created and maintained for the community, by its members. +The Cloud Native Security Whitepaper (CNSWP) is intended to be a living +document created and maintained for the community, by its members. Updates to the whitepaper, suggestions for updates, or discussion for updates should initiate with an [issue](https://github.com/cncf/tag-security/issues) submitted to the repo and labeled with "suggestion" and "whitepaper". -### Markdown +### Markdown The living CNSWP is maintained in [markdown](https://github.com/cncf/tag-security/blob/main/security-whitepaper/cloud-native-security-whitepaper.md) and all updates will be made in - markdown. + markdown. -### Contributing updates +### Contributing updates All members of the community are welcome to contribute updates to the CNSWP. -We ask potential contributors to refer to the original design decisions, +We ask potential contributors to refer to the original design decisions, listed below, as guidance when determining the content of their updates. It is highly recommended that you seek peer review for your updates beyond that @@ -32,10 +32,10 @@ of the Technical Leads and Co-Chairs of the TAG. Once the PR is submitted, please place the link in the CNCF TAG-Security Channel for the CNSWP: [#tag-security-whitepaper](https://cloud-native.slack.com/archives/C017K5AN70T) to request a review. -### Versioning and publishing +### Versioning and publishing -It is expected that many minor updates will occur, corrections to grammar, -spelling, clarification in language, translations, etc. When these occur +It is expected that many minor updates will occur, corrections to grammar, +spelling, clarification in language, translations, etc. When these occur they are considered minor changes to the overall content and will not warrant the regeneration of the PDF. @@ -49,16 +49,16 @@ annotating the new version, updating the links in the README.md accordingly. Minor updates to the markdown shall receive a minor version bump indicated in the Metadata table of the document and recorded as WIP. When enough significant changes have been recorded, the markdown will be placed "In Review" (via PR) and -solicited to the CNCF SIG-Security and TOC mailing list for review, at a minimum. +solicited to the CNCF TAG-Security and TOC mailing list for review, at a minimum. -Upon completion of review, the SIG-Security TOC Liaison shall provide final +Upon completion of review, the TAG-Security TOC Liaison shall provide final approval on the PR. At which point the markdown state will be changed to -"Approved" and merged. +"Approved" and merged. ## Original design decisions - -The CNSWP's creation occurred using the below general design decisions which -should be considered when updating the content. + +The CNSWP's creation occurred using the below general design decisions which +should be considered when updating the content. * Avoid identifying specific projects and products. Use general terms identifying the capabilities of the projects that meet the content under discussion. Examples include, but are not limited to: diff --git a/security-whitepaper/cloud-native-security-whitepaper-simplified-chinese.md b/security-whitepaper/cloud-native-security-whitepaper-simplified-chinese.md index f147e4a40..2afabc1f1 100644 --- a/security-whitepaper/cloud-native-security-whitepaper-simplified-chinese.md +++ b/security-whitepaper/cloud-native-security-whitepaper-simplified-chinese.md @@ -252,7 +252,7 @@ IaC 越来越受欢迎，在企业中的部署迅速增加，以部署云和容 ## 部署 -![Figure 4](cnswp-images/RackMultipart20201111_figure4.png) +![Figure 4](cnswp-images/RackMultipart20201111_figure4.png) _图四_ @@ -611,7 +611,7 @@ _图四_ ## 角色和用例 -重点是安全、保护、检测和尽可能的自动响应。它不一定是独立的开发工具，而是透明地集成到开发流程中的安全工具，使得开发过程中就能够执行安全策略、快速反馈和直接补救。有关云原生安全用例的具体信息，请参考 [SIG-Security 的用例列表](https://github.com/cncf/tag-security/blob/main/usecase-personas)。 +重点是安全、保护、检测和尽可能的自动响应。它不一定是独立的开发工具，而是透明地集成到开发流程中的安全工具，使得开发过程中就能够执行安全策略、快速反馈和直接补救。有关云原生安全用例的具体信息，请参考 [TAG-Security 的用例列表](https://github.com/cncf/tag-security/blob/main/usecase-personas)。 ### 行业 @@ -712,7 +712,7 @@ https://owasp.org/www-community/Application_Threat_Modeling # **鸣谢** -本白皮书是由 CNCF Security-SIG 成员推动的社区工作。感谢大家的杰出贡献。特别感谢 Emily Fox 和 Jeyappragash JJ。 +本白皮书是由 CNCF Security-TAG 成员推动的社区工作。感谢大家的杰出贡献。特别感谢 Emily Fox 和 Jeyappragash JJ。 原版撰稿人： diff --git a/security-whitepaper/cloud-native-security-whitepaper.md b/security-whitepaper/cloud-native-security-whitepaper.md index e2f35d20b..ccb891758 100644 --- a/security-whitepaper/cloud-native-security-whitepaper.md +++ b/security-whitepaper/cloud-native-security-whitepaper.md @@ -14,13 +14,13 @@ Shared with CNCF Community | **Created** | 2020-FEB-01 | | **Last Reviewed** | 2020-OCT-27 | | **PDF Published** | 2020-NOV-18 | -| **Release Version** | 1.0 | +| **Release Version** | 1.0 | | **Final PDF Approvers** | [x] @lizrice [x] @justincormack | | **Originating Content and Review** | | | -- | --| | **Contributors** | [aradhna.chetal@gmail.com](mailto:aradhna.chetal@gmail.com), [@theFoxAtWork](mailto:themoxiefoxatwork@gmail.com), [jj@tetrate.io](mailto:jj@tetrate.io), gadi@alcide.io @lumjjb, @trishankatdatadog, [@vvenkatara@paloaltonetworks.com](mailto:vvenkatara@paloaltonetworks.com), @pushkarj, @whaber, @sublimino, @rowan-baker, [chase.pettet@gmail.com](mailto:chase.pettet@gmail.com), [harsingh@us.ibm.com](mailto:harsingh@us.ibm.com), jeff.lombardo@gmail.com | -| **Reviewers** | @justincappos, @lumjjb, @whaber, @craigbox, @anvega, @magnologan, @magnologan, alok@xenonstack.com, @nyrahul, @ranio1, Itay Shakury (@itaysk) | +| **Reviewers** | @justincappos, @lumjjb, @whaber, @craigbox, @anvega, @magnologan, @magnologan, alok@xenonstack.com, @nyrahul, @ranio1, Itay Shakury (@itaysk) | ## Index - [**Cloud Native Security Whitepaper**](#cloud-native-security-whitepaper) @@ -233,7 +233,7 @@ Utilization of security benchmarks (e.g. [NIST Application Container Security Gu The next few sections provide a detailed analysis of the implications, tools, mechanisms and best practices to integrate security throughout the application lifecycle. -## Develop +## Develop ![Figure 2](cnswp-images/RackMultipart20201111_figure2.png) @@ -585,7 +585,7 @@ In contrast, compliance standards form principles of controls to ascertain or cr ## Threat Modeling -For organizations adopting cloud native, a primary mechanism for identifying risks, controls and mitigations is to perform threat modeling. While there are many threat modeling techniques they share several core characteristics. All start with building a scoped representation of a system's architecture. This begins with identifying all important processes, data stores, and [security boundaries](https://www.oreilly.com/library/view/cissp-certified-information/9780470276884/9780470276884_security_boundaries.html). Once boundaries have been established and the relevant elements of the system are partitioned within them, the next step is to model how these elements interact with special attention paid to any interactions that cross security boundaries. +For organizations adopting cloud native, a primary mechanism for identifying risks, controls and mitigations is to perform threat modeling. While there are many threat modeling techniques they share several core characteristics. All start with building a scoped representation of a system's architecture. This begins with identifying all important processes, data stores, and [security boundaries](https://www.oreilly.com/library/view/cissp-certified-information/9780470276884/9780470276884_security_boundaries.html). Once boundaries have been established and the relevant elements of the system are partitioned within them, the next step is to model how these elements interact with special attention paid to any interactions that cross security boundaries. The below guidance is an enhancement of the four step [OWASP threat modeling](https://owasp.org/www-community/Threat_Modeling) recommended for cloud native capabilities. @@ -705,11 +705,11 @@ Many financial, health, government, and other entities need to comply with a spe ### Personas and Use Cases -The focus is on security, protection, detection, and auto-response where ever possible. -It is not necessarily development tooling alone, but security tooling that integrates -transparently into the development process to enforce security policies where fast +The focus is on security, protection, detection, and auto-response where ever possible. +It is not necessarily development tooling alone, but security tooling that integrates +transparently into the development process to enforce security policies where fast feedback and most immediate actions to remediate can occur. For specific information - on cloud native security use cases refer to the [SIG-Security's use cases listing](https://github.com/cncf/sig-security/usecase-personas/). + on cloud native security use cases refer to the [TAG-Security's use cases listing](https://github.com/cncf/tag-security/usecase-personas/). ## Industries @@ -804,7 +804,7 @@ https://www.cisecurity.org/benchmark/Kubernetes/ ### Acknowledgements -This white paper is a community effort driven by the members of the CNCF Security-SIG. Thank you to everyone for their outstanding contributions. Special thanks to Emily Fox and Jeyappragash JJ. +This white paper is a community effort driven by the members of the CNCF Security-TAG. Thank you to everyone for their outstanding contributions. Special thanks to Emily Fox and Jeyappragash JJ. Contributors: @@ -836,8 +836,8 @@ Reviewers: - Alok Raj - [XenonStack](https://www.xenonstack.com/) ([alok@xenonstack.com](mailto:alok@xenonstack.com)) - @nyrahul - @ranio1 -- @lizrice -- @justincormack +- @lizrice +- @justincormack [1^]: Another model to consider is Cloud, Clusters, Containers, and Code: [https://kubernetes.io/docs/concepts/security/overview/](https://kubernetes.io/docs/concepts/security/overview/) @@ -845,9 +845,9 @@ Reviewers: [3^]: [Shifting security left](https://www.devsecops.org/blog/2016/5/20/-security) often leaves organizations to lapse operational security monitoring. It is important that security exists in all parts of the lifecycle and organizations continually evaluate other aspects of their business and technology processes where they may reach beyond modern security paradigms to embrace security as a culture and habit. -[4^]: Human capital is a vital asset necessary to the success of any organization, the corresponding intellectual property and relational capital brought as a result is equally in need of protection. +[4^]: Human capital is a vital asset necessary to the success of any organization, the corresponding intellectual property and relational capital brought as a result is equally in need of protection. -[5^] +[5^] [6^]: According to Applied Software Measurement, Capers Jones, 1996 and adjusting for inflation - 85% of defects are introduced during coding with a cost of $41 to fix compared to a post release fix cost of $26,542. diff --git a/slack.md b/slack.md index deab96ee3..cdd7b73e6 100644 --- a/slack.md +++ b/slack.md @@ -1,11 +1,11 @@ -# SIG-Security channels housekeeping +# TAG-Security channels housekeeping ## Identifying and creating channels -Just for approved projects, "sec-assessment-xxxx" exception SIG-Security channels -are identified with the “sig-security-” prefix. Except during conferences, the -CNCF permits slack members to create channels; however, sig-security-related +Just for approved projects, "sec-assessment-xxxx" exception TAG-Security channels +are identified with the “tag-security-” prefix. Except during conferences, the +CNCF permits slack members to create channels; however, tag-security-related channels should only be created by chairs or tech leads, and are typically -prefixed by sig-security- following hyphenation of the topic/subject. This +prefixed by tag-security- following hyphenation of the topic/subject. This helps the community find topics of relevance as well as discover areas to collaborate. @@ -15,12 +15,12 @@ Additional information may be found in the [CNCF slack guidelines](https://githu ## Code of conduct -Members of SIG-Security channels are expected to abide by the [code of conduct](https://github.com/cncf/sig-security/blob/master/CODE-OF-CONDUCT.md). +Members of TAG-Security channels are expected to abide by the [code of conduct](https://github.com/cncf/tag-security/blob/master/CODE-OF-CONDUCT.md). ## Posting outside content -The SIG-Security channels are mechanisms for cloud native security discussions. -It is expected that outside, non-sig created content will be posted; however, +The TAG-Security channels are mechanisms for cloud native security discussions. +It is expected that outside, non-tag created content will be posted; however, these should include topics of relevance and interest to the cloud native community space, rather than marketing or promotion of a vendor-specific product. diff --git a/supply-chain-security/compromises/README.md b/supply-chain-security/compromises/README.md index e69bb5786..d2b25f2fa 100644 --- a/supply-chain-security/compromises/README.md +++ b/supply-chain-security/compromises/README.md @@ -2,15 +2,15 @@ This repository contains links to articles of software supply chain -compromises. The goal is not to catalog every known supply chain attack, but -rather to capture many examples of different kinds of attack, so that we +compromises. The goal is not to catalog every known supply chain attack, but +rather to capture many examples of different kinds of attack, so that we can better understand the patterns and develop best practices and tools. For definitions of each compromise type, please check out our [compromise definitions page](/supply-chain-security/compromises/compromise-definitions.md) -We welcome additions to this catalog by -[filing an issue](https://github.com/cncf/sig-security/issues/new/choose) or -[github pull request](https://github.com/cncf/sig-security) +We welcome additions to this catalog by +[filing an issue](https://github.com/cncf/tag-security/issues/new/choose) or +[github pull request](https://github.com/cncf/tag-security) | Name | Year | Type of compromise | Link | @@ -39,17 +39,17 @@ We welcome additions to this catalog by | [Kingslayer](2017/kingslayer.md) | 2017 | Publishing Infrastructure | [1](https://www.rsa.com/content/dam/premium/en/white-paper/kingslayer-a-supply-chain-attack.pdf) | | [HackTask](2017/hacktask.md) | 2017 | Negligence | [1](https://securityintelligence.com/news/typosquatting-attack-puts-developers-at-risk-from-infected-javascript-packages/) | | [NotPetya](2017/notpetya.md) | 2017 | Multiple steps | [1](https://www.welivesecurity.com/2017/07/04/analysis-of-telebots-cunning-backdoor/) | -| [Bitcoin Gold](2017/bitcoingold.md) | 2017 | Source Code | [1](https://bitcoingold.org/critical-warning-nov-26/) | +| [Bitcoin Gold](2017/bitcoingold.md) | 2017 | Source Code | [1](https://bitcoingold.org/critical-warning-nov-26/) | | [ExpensiveWall](2017/expensivewall.md) | 2017 | Dev Tooling | [1](https://blog.checkpoint.com/2017/09/14/expensivewall-dangerous-packed-malware-google-play-will-hit-wallet/), [2](https://research.checkpoint.com/expensivewall-dangerous-packed-malware-google-play-will-hit-wallet/) | [OSX Elmedia player](2017/elmedia.md) | 2017 | Publishing infrastructure | [1](https://www.hackread.com/hackers-infect-mac-users-proton-malware-using-elmedia-player/) | | [keydnap](2016/keydnap.md) | 2016 | Publishing infrastructure | [1](https://blog.malwarebytes.com/threat-analysis/2016/09/transmission-hijacked-again-to-spread-malware), [2](https://www.welivesecurity.com/2016/08/30/osxkeydnap-spreads-via-signed-transmission-application/) | | [Fosshub Breach](2016/fosshub.md) | 2016 | Publishing infrastructure | [1](https://www.ghacks.net/2016/08/03/attention-fosshub-downloads-compromised/), [2](https://www.theregister.co.uk/2016/08/04/classicshell_audicity_infection/) | | [Linux Mint](2016/mint.md) | 2016 | Publishing infrastructure | [1](https://www.zdnet.com/article/linux-mint-website-hacked-malicious-backdoor-version/) | | [Juniper Incident](2015/juniper.md) | 2015 | Source Code Compromise| [1](https://eprint.iacr.org/2016/376.pdf) -| [XCodeGhost](2015/xcodeghost.md) | 2015 | Fake toolchain | [1](https://www.theregister.co.uk/2015/09/21/xcodeghost_apple_ios_store_malware_zapped/) | +| [XCodeGhost](2015/xcodeghost.md) | 2015 | Fake toolchain | [1](https://www.theregister.co.uk/2015/09/21/xcodeghost_apple_ios_store_malware_zapped/) | | [Ceph and Inktank](2015/ceph-and-inktank.md) | 2015 | Build, source and publishing infrastructure | [1](https://www.zdnet.com/article/red-hats-ceph-and-inktank-code-repositories-were-cracked/) | | [Code Spaces](2014/code-spaces.md) | 2014 | Source Code | [1](https://threatpost.com/hacker-puts-hosting-service-code-spaces-out-of-business/106761/) | [Monju Incident](2014/monju.md) | 2014 | Publishing infrastructure| [1](https://www.contextis.com/en/blog/context-threat-intelligence-the-monju-incident) -| [Operation Aurora](2010/aurora.md) | 2010 | Watering-hole attack | [1](https://www.wired.com/2010/03/source-code-hacks/) | +| [Operation Aurora](2010/aurora.md) | 2010 | Watering-hole attack | [1](https://www.wired.com/2010/03/source-code-hacks/) | | [ProFTPD](2010/proftpd.md) | 2010 | Source Code | [1](https://www.zdnet.com/article/open-source-proftpd-hacked-backdoor-planted-in-source-code/) | | [gentoo rsync compromise](2003/gentoo-rsync.md) | 2003 | Source Code | [1](https://archives.gentoo.org/gentoo-announce/message/7b0581416ddd91522c14513cb789f17a) |