cyberark / community Goto Github PK

View Code? Open in Web Editor NEW

7.0 17.0 5.0 245 KB

Information for the CyberArk contributor community

License: Apache License 2.0

cyberark contributors community-guidelines conjur-community-team conjbot-notify

community's Introduction

CyberArk Commons

Welcome to the CyberArk Community!

Consider this your starting point for contributing to CyberArk code, documents, and getting involved in discussion.

Here, you'll find both general and team-specific resources that will guide you through the process of becoming a contributor to one of our open-source projects.

General Guidelines
- Communicating
- Contributing
Group-Specific Guidelines
- CyberArk Conjur
  - What we do
  - Projects we work on
- CyberArk Labs
  - What we do
  - Projects we work on

Table of contents generated with markdown-toc

General Guidelines

Communicating

Start a conversation with us on Discourse!

Our CyberArk Commons Discourse is where we share tips and tricks for using our products and tools, updates on product changes and design conversations, discuss relevant blog posts and articles, and answer your questions. Join us there to find out what we're thinking about - we'd be glad to have you as part of our conversation!

Contributing

Many projects in our Github repositories encourage contribution, even this one! Our contributor's guide contains information on:

If you already know which project you'd like to work on, check out the Group-Specific Guidelines to learn more about additional tips and tricks as you get started.

Questions? Let's talk!

Group-Specific Guidelines

CyberArk publishes many open source projects in https://github.com/cyberark - and there are a few primary groups publishing this content who each may have slightly different guidelines for contributing. In this section, you can learn more about the projects each group is working on and read up on the contribution guidelines that are specific to each group.

CyberArk Conjur

What we do

At Conjur Open Source, we’re creating the tools to help you build applications safely and securely - without having to be a security expert. From our flagship Conjur server (a secret store and RBAC engine), to custom authenticators that make the secret zero problem a thing of the past, to Secretless Broker, which aims to make sure your apps never have to worry about secrets again.

Projects we work on

Visit our Conjur OSS Suite Landing Page to view a full list of our projects and find helpful resources for learning more about our approach to security!

CyberArk Labs

What we do

The security research groups at CyberArk Labs are busy with studying the attack surface of common and emerging technologies. We fuzz, poke, bypass, maneuver, misuse, escalate, hijack, deny service, degrade, escape and exploit the technologies, and from time to time we share here new tools you can use to detect vulnerabilities and identify threats; based on our research of course.

You can have a look at what we are currently working on right here - https://www.cyberark.com/threat-research-blog/.

Projects we work on

We have a variety of projects for analyzing threats and detecting vulnerabilities. Click the dropdown below to view and browse them!

View Projects

Name	Description
ACLight	A script for advanced discovery of Privileged Accounts - includes Shadow Admins.
BlobHunter	A tool for finding exposed data in Azure Blob Storage.
DLLSpy	DLL Hijacking Detection Tool
EasyPeasy	Find accounts using common and default passwords in Active Directory.
KDSnap	KDSnap is a DLL extension for WinDbg that integrates your debugger with your virtualization platform of choice.
ketshash	A little tool for detecting suspicious privileged NTLM connections, in particular Pass-The-Hash attack, based on event viewer logs.
Kubeletctl	A command line tool that implement kubelet's API.
KubiScan	A tool to scan Kubernetes cluster for risky permissions.
Mystique	PowerShell module to play with Kerberos S4U extensions.
NetRay	A modular, python tool that detects attacks against the Kerberos protocol.
PreCog	Discover "HotSpots" - potential spots for credentials theft.
RiskySPN	Detect and abuse risky SPNs
shimit	A tool that implements the Golden SAML attack
SkyArk	SkyArk helps to discover, assess and secure the most privileged entities in Azure and AWS.
SkyWrapper	A tool for discovering suspicious creation forms and uses of temporary tokens in AWS.
zBang	zBang is a risk assessment tool that detects potential privileged account threats.

community's People

Contributors

Stargazers

Watchers

Forkers

andrewcopeland izgeri-test shulifink lumjjb raghav1674

community's Issues

All community team repos have a CODEOWNERS file

The following repos should have a CODEOWNERS file in .github/CODEOWNERS that includes the single line:

* @cyberark/community-and-integrations-team

Secretless has run MSSQL performance tests with the latest master build (1.5.2-434b05c at this time)

AC:

Juxtaposer 1 hour, single thread, recreateConnections=false (aka persistent connection) performance tests have been run for MSSQL in a realistic environment (eg the XA env)
The tabular results of the performance tests have been attached to this issue

Public repos have issue templates

All public repos have bug and feature request issue templates.

Suggested templates:

Repos:

Conjur README has guidelines on filing GitHub issues

TBD - depends on whether the github landing page is live. If so, we can advise to find the appropriate repository's issue page and click "new issue". Otherwise we may need to come up with more generic guidelines.

Non-LGPL repos use the DCO for contributions

Turn on master branch daily builds for all product repos we own

Add daily build triggers to the Jenkinsfile for any repos in this list that have pipelines but don't already have it turned on:

conjurdemos/cloudfoundry-conjur-demo
conjurdemos/kubernetes-conjur-demo
conjurdemos/pet-store-demo
conjurinc/cloudfoundry-conjur-tile
cyberark/ansible-conjur-host-identity
cyberark/cloudfoundry-conjur-buildpack
cyberark/conjur-puppet
cyberark/conjur-service-broker
cyberark/sidecar-injector
cyberark/terraform-provider-conjur
conjurinc/secretless-broker-e2e-tests
conjurinc/secretless-demo
conjurinc/secretless-server
cyberark/go-mssqldb
cyberark/secretless-broker
conjurinc/summon-chefapi
conjurinc/summon-conjurcli
conjurinc/summon-keyring
conjurinc/summon-s3
cyberark/summon
cyberark/summon-aws-secrets
cyberark/summon-conjur
cyberark/summon-file

Daily pipeline builds can be turned on by adding

triggers {
  cron(getDailyCronString())
}

to the Jenkinsfile

There is an automated process to validate and update acknowledgements files

Each public repository should include an open source acknowledgements file that is kept up-to-date with the OSS dependencies in the project

A blog post exists for running demos using KinD

@diverdane recently did a POC of revising the [Secretless demo](https://github.com/cyberark/secretless-broker/tree/master/demos/k8s-demo/] to run using KinD: https://github.com/diverdane/secretless-k8s-demo

This would make an interesting blog post. Some points to consider hitting:

the evolution of local K8s dev
the differences between KinD and other options
considerations when choosing a local tool to try k8s
whether you'd use KinD for local dev if you have access to an actual k8s cluster

Code review process is published

AC:

Finalize how PRs are reviewed (applying to both staff and community members.)
Document this process on conjur.org and in the community repo

Add contribution license policy to Conjur guidelines

AC:

The CONTRIBUTING file in the conjur folder of the community repo has guidelines on using the DCO (for MIT / Apache / BSD licensed repos) vs the CLA (can be based on guidelines here)
The community repo includes a copy of the CLA to serve as a central place for projects that use it to refer to it

There is a public community repo with contributor guidelines

AC:

Populate the repo with the contributor license agreement, guidelines on contributing, info on how to get started finding issues, software quality standards and expectations, the process for submitting work and getting it merged
Update existing repositories to refer to the central community repo as appropriate

Create initial repository structure with README and team folders

AC:

The cyberark/community repo has a README that:
- Introduces CyberArk Commons and has a "Welcome to CyberArk Commons" message
- Refers to Discourse, conjur.org, blogs.conjur.org
- Talks about the three primary groups that have software in the cyberark GitHub org, and links to READMEs in separate folders for those three groups. There should be a bullet for each group that is involved - CyberArk Labs, CyberArk Conjur, and CyberArk Cloud Solutions - and the bullets should each link to a README in a folder for each group (eg labs, conjur, and cloud).

Once this is merged and live in the repo, we'll ask PMM for feedback on the main community README, and alert the cloud and lab teams to let them know to add content to their folders

Update Puppet

The current Conjur Puppet page lists Zendesk for support (see the support section

The page needs to be updated with current contact information for Conjur support, i.e. the Conjur channel in Discourse here or this github repo's issues section.

Community repo has been reviewed by a future contributor

We'd love to have a future contributor look through the community repo and give us feedback on what could be clearer and how we can improve it.

A template repository exists

The template repository should include:

README.md with instructions on getting started (that are deleted on copying)
LICENSE
CONTRIBUTING.md
template Jenkinsfile
issue templates
PR templates
...

wrong place

Community README.md clearly describes team roles

The top-level README.md in the community repo should give a clear and detailed introduction to each team (Conjur, Cloud Solutions, Labs, etc.)

Table of contents containing links to other sections of the readme detailing the teams
Full sections that detail information about each group
- "Who we are"-type section
- "What we do"-type section
- Dropdown table with repos owned by the team

Community maturity levels are defined

Aha card: https://cyberark.aha.io/features/AAM-264

The basis for the proposal includes the following:

The original release checklist
@andytinkham's DoD spreadsheet
@brikelly's Slack draft contribution levels

The goal is to define maturity levels for contributions so that we can enable community contributions while continuing to be clear to end users about expected maturity of features in the open source suite of products.

The community guidelines have undergone XA

Broken Terraform build is fixed

The broken terraform provider build here needs to be fixed.

PR submission metrics are tracked on a dashboard

Generate dashboard to track:
- Time to first response for a new PR.
- Number of submitted PRs each quarter.
- Average time from submission to approval.
- Top contributors (CyberArk staff and community members.)

References to Slack are updated to refer to CyberArk Commons

In cyberark/conjur#1261 it was noted that the Conjur github repo still links to Slack in its README.

Our other public repos need to also be reviewed to ensure that they do not also link to Slack - if they do, they should be updated to refer to CyberArk Commons instead.

JDBC Connectivity Tests Exist for Postgres

We verify that connection succeeds with simple queries when connecting to Secretless through JDBC

Spike on creating acknowledgements file automatically for Go modules

Given a project that is written in Go and uses Go modules for package management
Then an acknowledgements file (NOTICES.txt) can automatically be created from the go.mod
And when the go.mod is updated
Then the pipeline can auto-detect an update to the acknowledgements is needed
And there is a script to auto-update the acknowledgements file given the new go.mod

Potential tools to leverage to automate this:

https://github.com/nexB/scancode-toolkit
https://github.com/vmware/tern
https://github.com/pivotal/LicenseFinder (currently used by Secretless and the PCF integration)

There is a standard for documenting security vulnerability reporting

Our public repositories should clearly document what process non-employees should do to report potential security bugs. This could involve:

Including a SECURITY.md file, or similar
Including a snippet in the README or CONTRIBUTING that refers to the security bug policy
Other options?

In this effort, we will define the standard way Conjur Open Source repos should document security vulnerabilities, and we will update the current set of public non-archived repositories to follow this process.

AC:

There is a process defined for documenting how to report security vulnerabilities
Any new repo templates or guidelines are updated with this policy
All existing public non-archived repos follow this process

The user experience of the OSS suite release manager is defined

GIVEN I am the OSS suite release manager
AND I know what is available to release
AND I have determined what I want to include in the next OSS suite release
AND I know the version of the next OSS suite release
THEN I know the process for creating a new OSS suite release
AND I can follow that process to create a new OSS suite release

AC:

README for release manager is written

Community repo has documentation on the code review process

Finalize how PRs are reviewed (applying to both staff and community members.)
Document this process on conjur.org and in the repo.

JDBC Jar is built at runtime for integration tests

The jdbc jar in /tests/util/jdbc currently sits around 4.3 MB, and it would be better practice if we built it for our tests instead of storing the binary in our repository. There are several ways we could approach this, and several steps.

There isn't native support for MsSQL in the JAR, it has to be added along with the official driver from microsoft.
We need to modify the configuration and MANIFEST.md files each time to map the command to the MsSQL driver
Currently, there exists a dependency on eclipse for compiling and exporting. We should try to remove this dependency if possible.
We could introduce building the JAR file as part of our dockerfile build process for the test container

Public repositories have issue templates

Standard issue templates have been added to all public repositories

AC:

The default templates have been updated with actual default Bug and Feature Request templates
Each public repo has at minimum a Bug and Feature Request issue template

CONTRIBUTING.md files in public repos are updated to refer to the community repo for general guidelines

AC:

Every repo in the list below has a basic CONTRIBUTING.md file (template here) - add a file if there isn't one, even if it includes almost no content now
Every CONTRIBUTING.md file links to the community repo "for general contributor information"

Note: as you're adding new contributing files please be sure to update the README to link to the project CONTRIBUTING, and move all contributor focused content from the README to the project CONTRIBUTING.

This means that PRs where you add CONTRIBUTING.md should change two files - CONTRIBUTING and the README. Repos where you update the existing contributing to link to the generic guidelines will just change one file.

Repos:

higher priority repos

lower priority repos

Conjur Golang style guide covers all relevant topics

The Golang Style guide is missing a few categories that are relevant to the work of the Conjur team projects.

Code Coverage - Add target coverage, and example commands to run to get coverage.
Mocking - Determine if we need anything here, e.g. "avoid the use of global variables for mockable interface declarations, and instead propagate mockable interfaces from highest possible level down"
Copyright Notices - Add a sample copyright notice
Logging - Determine what needs to be added here

Issue submission metrics are tracked on a dashboard

Generate dashboard to track:
- Number of issues each month/quarter.
- Breakdown by status (e.g. No response, Confirmed, Wishlist, Resolved.)
- Time to first response.
- Average time to final resolution (e.g. Closed, Resolved.)
- Top contributors (CyberArk staff and community members.)

Create initial Conjur guidelines

AC:
In the Conjur folder, there needs to be:

A README for Conjur Open Source that refers to the content below
A folder for style guides (eg Ruby, Golang, Bash) that is linked to from the README - use existing style guides when possible, and if none exists just create a minimal simple style guide for this directory that liinks to existing content from the pinned style guides in the about-X channels in Slack
A CONTRIBUTING file with:
- Info on looking for CONTRIBUTING.md in other repos
- Info on generic contribution workflow (eg fork, change, PR, etc)
- Special git-flow guidelines that we use, that community users should know about (ie clean commit history, rebase vs merge, etc - can be pulled from our git guide
- General info on typical testing patterns / how to run tests

Repo has bug and feature request issue templates

AC:
The following templates have been added to the repo, with appropriate component labels:

Community repo describes the public issue tracking process

We may need to define this process for the OSS community first. Suggested flow:

Deliver internal issue tracking for public issues (in GitHub):
- Set up statuses.
- Set up any issue templates (e.g. for support issus to be redirected to Discourse.)
Deliver internal issue tracking for private issues (in GitHub):
- Set up statuses.

Public repositories have a valid, up-to-date acknowledgements file

Suite release has undergone XA

User Stories

Open Source Users


As a	Conjur Open Source user
I want	to know what tools and integrations there are for Conjur
so that	I can evaluate whether Conjur is suitable for me to use, and which tools / integrations are compatible with my systems.


As a	Conjur Open Source user
I want	to know what versions of Conjur OSS components to use
so that	I am using reliable, well-tested software that works together as expected when used within my systems.

OSS Suite Component Maintainers


As a	maintainer of a Conjur OSS suite component
I want	to know how to ensure new versions of my component get into the OSS suite release
so that	OSS users can benefit from new features my team is adding to our component.


As a	maintainer of a Conjur OSS suite component
I want	to know what I'm responsible for testing and what will be tested in the OSS suite
so that	it's clear what tests I need to include and maintain in my component repository, and which tests belong in the central OSS suite release repo.


As a	maintainer of a Conjur OSS suite component
I want	to know what standards I need to maintain in my repository
so that	my CHANGELOG entries, releases, READMEs, etc are compatible with the OSS suite release.

Conjur OSS Contributors


As a	Conjur Open Source contributor
I want	to know what components there are
so that	I can find components that I can contribute to.


As a	Conjur Open Source contributor
I want	to know what is included in the Conjur OSS suite
so that	if there are tools or platforms that are not supported, I can make a difference by building something to fill the gap.

Conjur OSS Suite Release Managers


As a	Conjur release manager
I want	o know what changes have been made to components since the last suite release
so that	I can decide if enough changes have been made to merit a new release.


As a	Conjur release manager
I want	to know how to create a new release, including any manual steps that are required
so that	I can successfully create a new release without missing any steps.


As a	Conjur release manager
I want	to know the results of automated tests
so that	I can be sure all included components work together as expecteed at the pinned versions.

Conjur Core Downstream Developer


As a	developer on a downstream project that uses Conjur as its core
I want	to know when there are new Conjur OSS suite releases
so that	I can review the changes and update my project to use the latest OSS suite release version of Conjur.


As a	developer on a downstream project that uses Conjur as its core
I want	a machine readable summary of what is included in each OSS suite release
so that	I can build automation around the OSS suite releases as needed.

MsSQL Connection Details supports additional ssl options

NewConnectionDetails has support for SSLOptions, similar to the PG and MySQL adapter.

sslOptions exists as a value in the connectiondetails struct
"sslrootcert", "sslkey", "sslcert" can be specified in the secretless.yml
unit tests exist for the proper handling of these values

Every repo in the Conjur OSS suite has a license header in every source code file

Add a header to the top of all source code files (e.g. .go and .rb files, etc) with:

// Copyright (c) 2020 CyberArk Software Ltd. All rights reserved.
// Use of this source code is governed by an Apache 2.0
// license that can be found in the LICENSE file.

Copyrights are updated to 2020

The copyrights on our license files in all Conjur-owned repos are updated to

Every Conjur OSS repo has a pull request template

The following projects should be updated to have the same pull request template as the one used in Conjur, here: https://github.com/cyberark/conjur/blob/master/.github/PULL_REQUEST_TEMPLATE.md.

These repos already have a pull request template, please review them and determine whether they can be updated to a format like the Conjur template, or if they need to remain as-is:

cyberark/conjur
cyberark/conjur-template
cyberark/secretless-broker

Community repo has a contribution guide

As with every project, the community repo is open to contributions from the external and internal community.

A CONTRIBUTING.md exists in the top-level directory
Details for internal and external contributors to improve documentation and clarity of community docs structure and content
Details for connecting a project back to the community repo through a README
Common conventions for making a project open for contributions

All suite release repos have bug and issue templates

This is a follow-up to #26, which (oops) did not include all relevant repos.

Suggested templates:

AC: Add or update feature request and bug templates in the following repos:

The updated GCP marketplace integration has gone through XA

Initial metrics on community PRs and issues have been measured

Using a documented manual but repeatable process, metrics are collected on the following:

Time to first response for a new PR.
Number of submitted PRs per month
Average time from submission to approval
Top contributors (CyberArk staff and community members)
Number of issues each month/quarter.
Breakdown by status (e.g. No response, Confirmed, Wishlist, Resolved.) (Note - mapping to these statuses is TBD)
Time to first response.
Average time to final resolution (e.g. Closed, Resolved.)
Top contributors (CyberArk staff and community members.)

There is a blog post on "lessons from the theater"

AC:

There is a blog post on lessons gleaned from the theatre surrounding healthy team dynamics

Find a way to make in progress / soon to be released work more visible

Improve the workflow to make "in progress" and "merged but not released" issues more visibile in GitHub / to people without ZenHub access

A first OSS suite release exists

AC:
There is an initial OSS suite release with:

CHANGELOG in the repo
GitHub tag and release with release notes
Updated documentation and release notes published on conjur.org

All public repos have master branch protection on

All public repos should require pull requests for submitting code to the master branch.

AC:

Review all public repos to determine master branch protection status
Turn on master branch protection (with re-review required if new changes are pushed) if a repository does not yet have it on

There is a file descriptors blog post

AC:

The gist published here: https://gist.github.com/doodlesbykumbi/d2f3a90796e0f83792bb47f310da79ca
is edited based on the feedback already given and migrated to WordPress to be published on blogs.conjur.org

cyberark / community Goto Github PK

community's Introduction

CyberArk Commons

Table of Contents

General Guidelines

Communicating

Contributing

Group-Specific Guidelines

What we do

Projects we work on

What we do

Projects we work on

community's People

Contributors

Stargazers

Watchers

Forkers

community's Issues

Repos:

higher priority repos

lower priority repos

User Stories

Open Source Users

OSS Suite Component Maintainers

Conjur OSS Contributors

Conjur OSS Suite Release Managers

Conjur Core Downstream Developer

Recommend Projects

Recommend Topics

Recommend Org