Opportunity Areas for Pinniped Contributors

[pabloschuhmacher]

Introduction

This document is intended to be used as a reference point for opportunity areas that community members can leverage when considering contributing to the project. It is derived from a meeting held by the Pinniped maintainers in early January 2021.

Ideally, this document should be considered in conjunction with the Pinniped Project Roadmap. Many of the below items appear at a high-level in our current roadmap. Here one can find particular tactical work items that we believe support the opportunity areas outlined below and exposed in the project roadmap.

Opportunity Areas

• To increase adoption…
  • Add features that decrease adoption friction
  • Deliver documentation that is appropriate for different skill levels and specific integrations (popular OSS and managed IDPs, etc).
  • Have well-written github issues with acceptance criteria and rationale.
  • Continue to improve the user experience
• To offer the best security posture for Kubernetes cluster authentication…
  • Rotate all the things
  • Tie downstream and upstream authentication more closely, and make it more customizable (e.g. flow metadata from upstream through, allow policy creation)
  • Allow customers to bring their own infrastructure, like hardware security modules
• To maintain and improve the Project’s pace of delivery and quality of deliverables…
  • Pay down existing technical debt, if any
  • Improve CI automation
• To make upstream contributions that improve Kubernetes or Pinniped…
  • Replace hacks in the Pinniped implementation with upstream features

Possible Work Items to Support the Above Areas

Here are some ideas for potential work items that the team has mentioned in the past, just to start a brainstorming conversation.

Adoption

• Make it very easy for someone to play with Pinniped in a demo-like environment
• Support authentication of cluster users into web-based applications intended for use by that cluster’s admins and developers
• More customized support for upstream Active Directory, github, etc. IDPs
• Support for multiple upstream IDPs to be configured simultaneously, and support for the end user to choose which provider they would like to use during authentication
• Support configuring workload clusters such that they do not require network access to supervisor clusters
• Store Supervisor session data in another type of backend (e.g. sql)
• Support for configuring custom authentication limit and transformation rules to be applied during upstream IDP flows and/or during workload cluster authentication, to allow for use cases such as "users from this IDP should have their usernames prepended with the IDP name for RBAC purposes", or "only users who belong to certain groups in the upstream IDP can use this cluster" or “limit the length of the upstream groups list so it only contains the relevant groups in the downstream token”.
• Add more Concierge authenticators (e.g., x509 client auth, challenge/response, SSH key, etc.)
• Anonymized usage metrics: Useful metrics like versions of k8s, types of upstream providers, etc. plus vanity metrics like number of clusters in the world.

UX

• Support more upstream IDP protocols (i.e. SAML, LDAP)
• Support for the OAuth 2.0 Device Authorization Grant flow in the downstream OIDC flow, to allow for use cases where the CLI and web browser are on two different computers and/or networks, and for the case where a user is not allowed to open a localhost listening socket on their computer due to enterprise security restrictions

Security

• Upstream token refresh during downstream refresh
• Make it easy for users to meet compliance requirements with popular standards (e.g. FIPS) by using Pinniped
• Make security-related settings more user-configurable (e.g. token timeouts)
• Manual and/or automatic Supervisor secret rotation (JWKS signing key, fosite HMAC key, secure cookie keys, etc)
• Support for pluggable session/token persistence in the CLI, to allow for saving those secrets into a system keychain or other custom storage strategies
• Support for using a hardware or cloud provider KMS for supervisor Pinniped signing keys.
• Support for revocation of supervisor Pinniped downstream OIDC tokens, to allow for immediate revocation of access in the event of a change intended level of access for that user or the loss of a laptop, as opposed to waiting a little while for the short lifetimes of the tokens to expire.
• Support for the CLI trading in its supervisor Pinniped access token for a public/private keypair instead of an audience-constrained ID token, to allow for different security and network failure handling trade-offs.
• Token inactivity timeouts
• Maximum open sessions control
• Disallow authentication if no authorization present on current cluster
• Make the local-user-authenticator into a production-quality component
• Support pluggable encryption, hardware security modules, etc.

Pace

• Improve our CI/CD systems
  • Upgrade tests
  • Windows tests
  • Performance tests
  • Scale tests
  • Soak tests
• Get dependabot working for golang dependencies

Community

• Improve our docs: make it very very clear why and how to use Pinniped
• Improve the PR automation/workflow

Upstream

• Get rid of our cluster signing key hack (maybe with an upstream CSR API feature?)
• Fix the at_hash fosite bug that we found
• How to approach adding a credential issuer style API to Kube itself
• CSR signer should be multi threaded

Non-admin UX

• Manage existing sessions API
• Logout API

Other

• Expose metrics endpoints for Prometheus for operators to use
• Do a deliberate audit of what and how we log, minimize noise and maximize value