Skip to content
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
66 changes: 65 additions & 1 deletion README.md
Original file line number Diff line number Diff line change
@@ -1,5 +1,22 @@
# Riley Swish Challenge - DevSecOps Style Automated Respository

## Index

- [Objective](#objective)
- [Technical Requirements](#technical-requirements)
- [Docker Overview](#docker-overview)
- [User Story / Implementation Notes](#user-story--implementation-notes)
- [Why am I using ubuntu22.04 and not a multi-stage build?](#why-am-i-using-ubuntu2204-and-not-a-multi-stage-build)
- [Why did you leave our GPU requirement out?](#why-did-you-leave-our-gpu-requirement-out)
- [Minikube setup](#minikube-setup)
- [HPA](#hpa)
- [How do we scale resources based on events rather than resources?](#how-do-we-scale-resources-based-on-events-rather-than-resources)
- [How do we scale nodes though?!](#how-do-we-scale-nodes-though)
- [Observability/Logging](#observabilitylogging)
- [Bringing data to Memory?](#bringing-data-to-memory)
- [Room for improvement](#room-for-improvement)
- [Actions and How to Use This Repo](#actions-and-how-to-use-this-repo)
- [Trivy + Dependabot](#trivy--dependabot)

## Objective
The objective of this repo is to create an automated DevSecOps styled repo for use in k8s. This should contain automated code reporting and fixes, and the ability to build docker images in a workflow pipeline via Github Actions
Expand Down Expand Up @@ -86,7 +103,7 @@ python-swish-r-hpa Deployment/python-swish-r-deploy cpu: 2%/50% 1

HPA is for scaling based on _pod_ metrics, and is provided by metrics-server.

### How do we scale resoources based on events rather than resources?
### How do we scale resources based on events rather than resources?
- I mostly go for KEDA in this situation. Remember, HPA is for scaling based on your pods metrics reported usage and only scales replicasets(this is a k8s managed resource from our Deployments defined replica count). KEDA scales based on external events and works really well with HPA from my experience.


Expand All @@ -110,3 +127,50 @@ the actual answer to this.

## Room for improvement
- Lots probably! For respect of everyones time(yours and mine both), I wanted to keep this mostly simple.


## Actions and How to Use This Repo
There is a total of 3 usable actions in this workflow.



### Ephemeral Docker Build and Push + Generate K8s artifacts
- `dev_dispatch.yml` - This is a manual dispatch workflow that builds base ubuntu/debian images with python2,python3,R installed, per our Technical Requirements. This builds with no arguments, and you can click Run Workflow if you do not need to change the defaults. It looks like the below -


<img width="467" height="596" alt="Image" src="https://github.com/user-attachments/assets/d86d4e4b-234e-4dd7-b314-e40894143a3f" />

This also produces the k8s manifests you rendered in the pipeline within the outputted build artifact -
<img width="1622" height="269" alt="Image" src="https://github.com/user-attachments/assets/d9f37469-ede0-42f8-975d-54d34bc22822" />

This outputs the following rendered with your values:
deploy.yaml, hpa.yaml, service.yaml


You definitely could output the k8s manifests in the summary too, but it just looks messy.


### Build and Push to Dockerhub
- `dockerhub.yml` - This actions builds and pushes to dockerhub on every push to the main branch.
You may want to make this a manual trigger depending on the use case, or where you are placing the governance
in the git repo. I made this automatically push to hub for automation demo reasons.


### Trivy + Dependabot
- `trivy.yml` - This scans every new PR for CVE's on the image, and opens a dependabot PR if any are found related to
the image's open source packages, github actions, and Docker bases.

<img width="1883" height="718" alt="Image" src="https://github.com/user-attachments/assets/3246b38f-88b9-4165-bc38-6b69b07fa534" />

There is no code in this repo, so there is no need for code scanning enabled. In a more real prod setup, we would obviously want to enable scanning on the code.

Going to *Insights > Dependency* Graph will show you not only the Dependency Graph, but also generate an SBOM if you need it.


Dependabot config is pretty basic, as explained above for what it scans.
It opens PRs based on recommended fixes, and you can certainly set them to auto-merge but I prefer to review them.

<img width="832" height="295" alt="Image" src="https://github.com/user-attachments/assets/b18c2911-5b62-47ea-abc5-69d828d99299" />


In theory, as long as we stay vigilant and actually use dependanbot PRs to remedy the CVEs it finds and opens, we are in a decent spot for automated security.