Security - Iterate to improve the management of application credentials

[jhouse-solvd]

Problem Statement

Maintaining application credentials is difficult, due to a very flat design, that also lacks the ability to grant granular access to specific credentials for specific teams. There is also inconsistency in the existing design of various security-related resources. There is broad exposure in the form of the existing credstash DynamoDB table, and everything that comes with it. This design doesn't follow least-privilege best practice.

How might we add easily manage application credentials in a way that enforces least-privilege? How might we integrate this new credentials management workflow into ops-owned applications and services? How might we reduce administrative overhead by automating this workflow?

Hypothesis or Bet

Our hypothesis is that by implementing a solution for better management of application credentials, we can enforce better security and modernize application credential and parameter access patterns.

We will know we're done when... ("Definition of Done")

There is a clear, documented process in place for managing application credentials in a way efficiently. There is plan in place for how applications will use only SSM integration. When we've successfully migrate at least (1) ops-owned services, and (1) service owned by another platform team

Known Blockers/Dependencies

List any blockers or dependencies for this work to be completed

Projected Launch Date

By the end of Q1 2021, we expect to have new application credentials management system in place.

Launch Checklist

Is this service / tool / feature...

... documented?

• [ ] New documentation is written pursuant to our documentation style guide
• [x] Product is included in the List of VSP Products
  • List the existing product that this initiative fits within, or add a new product to this list.
• [ ] Internal-facing: there's a Product Outline checked into products/platform/PRODUCT_NAME/
  • Note: the Product Directory Name should match 1:1 with the List of VSP Products
• [ ] External-facing: a VFS-facing README exists for this product/feature tool
  • [ ] ... and should be located at platform/PRODUCT_NAME/README.md

Required Artifacts

Documentation

• PRODUCT_NAME: directory name used for your product documentation
• Product Outline: link to Product Outline
• README: link to VFS-facing README for your product
• User Guide: link to User Guide

Measurement (may not be necessary)

• Success metrics:

• developer onboarding time ~24 hours (match current request SLA)

• no empty groups in IAM

• only operations team members have administrative privileges (unless service account and/or unless justifiable, documented reason for enhanced privileges for a given user)

• full accounting / audit of existing policies

TODOs

• [x] Convert this issue to an epic
• [x] Add your team's label to this epic

[jhouse-solvd]

We will need to continue to consider how to break out user credentials stories and figuring out to properly scope those within this or a future initiative.

This initiative, as is, will focus on APPLICATION CREDENTIALS, which is a necessary starting place and makes most sense given where we are currently.

[jhouse-solvd]

Need to link up supporting artifacts and close this out.

[jhouse-solvd]

Please see "Store a secret in Parameter Store" for documentation pertaining to managing application credentials.

[jhouse-solvd]

This issue can be closed.