Skip to content
New issue

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

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

Already on GitHub? Sign in to your account

Approach for applying npm security patches to Docker Images #1401

Closed
2 of 3 tasks
lewisdaly opened this issue May 27, 2020 · 10 comments
Closed
2 of 3 tasks

Approach for applying npm security patches to Docker Images #1401

lewisdaly opened this issue May 27, 2020 · 10 comments
Assignees
Labels
oss-core This is an issue - story or epic related to a feature on a Mojaloop core service or related to it oss-ver Versioning stream stories story
Milestone

Comments

@lewisdaly
Copy link
Contributor

lewisdaly commented May 27, 2020

Goal:

As a hub operator, I want regular security patches applied to my running system, so I can ensure a secure and reliable environment.

  • i.e. how can we make sure docker images are upgraded?
  • what are the docker best practices? Should we rebuild an image with the same tag, or add a suffix?
    • e.g. 10.1.0 or 10.1.0-patch1
    • maybe a patch is just for dependencies (we need to make rules about this)
    • other code changes can be a BUGFIX upgrade
  • what do we want by default? Security patches or surety of code?

Tasks:

  • Propose a model that makes prompts to Hub Operators when a new image with only patches applied is available

Acceptance Criteria:

  • A proposal for a service that helps prompt Hub operators of updated patched images is made.

Pull Requests:

  • TBD

Follow-up:

  • N/A

Dependencies:

  • N/A

Accountability:

  • Owner: TBC
  • QA/Review: TBC
@elnyry-sam-k elnyry-sam-k self-assigned this May 27, 2020
@godfreykutumela
Copy link

I suggest we approach this from two perspective - 1. Capacitywise we may have to make a decision to support the last 3 or 4 versions with security patches but still support on more versions functionality wise. 2 Where fixing security vulnerability is only through version upgrade for a specific version then we will have to explore how that vulnerability can be mitigated. @elnyry

@elnyry-sam-k elnyry-sam-k added this to the Sprint 10.3 milestone May 27, 2020
@lewisdaly
Copy link
Contributor Author

I think there's 2 considerations here, with respect to the developer experience:

  1. when running helm deploy, which docker images are installed by default? Are they the images that were released at the same time as the deployment? (which could be weeks or months ago) Or have they been patched in the meantime (without a new helm deployment)?

  2. Is there a way for an administrator to run a command to apply the latest security patches?

helm upgrade would only work if a new helm release is made, and I don't think will update images in place if the tag hasn't changed (even if the image digest has). What if a user doesn't want to upgrade to the latest deployment, but wants to apply the security patches?

@lewisdaly
Copy link
Contributor Author

@elnyry here's a thread I found on re-pulling updated images for security updates: kubernetes/kubernetes#33664

@godfreykutumela
Copy link

godfreykutumela commented Jun 3, 2020

Noted @lewisdaly expanding your second point a bit, I think we should explore how we can build a way for an administrator to run a command to first check for vulnerabilities on a particular realise\version and also have an option to apply the latest security patches where they exist . From a risk perspective, we should explore a way where we can put a risk score or ratings per version for the adopters make their decision accordinly to the risk level they're willing to accept.

@elnyry-sam-k
Copy link
Member

Thanks @lewisdaly , @godfreykutumela for the inputs and thoughts, I'll go through these resources and your inputs and suggest a guidance here - will continue with the versioning team..

@elnyry-sam-k
Copy link
Member

Discussed with Lewis, Matt and Miguel to use an Operator pattern. @matdehaast also prosed using a controller pattern which may be simpler, investigating this.

@elnyry-sam-k
Copy link
Member

Some notes (from Lewis's mid-pi review presentation)

  1. Investigating best practices around rebuilding docker images with security patches, and how to apply them in running Kubernetes clusters
  2. Images to be with a new security patch suffix: start from mojaloop/ml-api-adapter:v10.4.1; publish a new version: mojaloop/ml-api-adapter:v10.4.1.1-patch when we apply a security patch (change of node_modules only)
  3. Develop a new service that runs inside a deployment; looks for updates to v10.4.1 (i.e. images with tag v10.4.1.X-patch) and then notifies Hub Operators (emails / slack notifications?) or in some cases automatically (or manually) replaces pods with patched images

@godfreykutumela
Copy link

Thanks @elnyry-sam-k and I will chat to @lewisdaly regarding follow through stories to action the 3 points from the notes above.

@elnyry-sam-k
Copy link
Member

Thanks @godfreykutumela , I'll create a story to actually do a PoC for this service in #3 , will keep you posted.. Thanks @lewisdaly and @matdehaast

@godfreykutumela
Copy link

Okay that's perfect, thanks @elnyry-sam-k

@elnyry-sam-k elnyry-sam-k added oss-core This is an issue - story or epic related to a feature on a Mojaloop core service or related to it oss-ver Versioning stream stories labels Jul 13, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
oss-core This is an issue - story or epic related to a feature on a Mojaloop core service or related to it oss-ver Versioning stream stories story
Projects
None yet
Development

No branches or pull requests

3 participants