As an operator of notify, I want to be able to quickly spin up a debug pod that has the necessary tools to troubleshoot the system while also maintaining a level of security and audibility.
WHY are we building?
The existing jump box is running all of the time which is not ideal. Additionally the tools required to troubleshoot (pgsql etc) are not installed by default. Finally, any commands run are not sent to security log groups for auditing.
WHAT are we building?
We can create a custom jump box image that has the tools we need, and redirects all shell output to the global stdout so that fluent bit picks it up. We can also use a variation of the following command to only run the pod when needed:
kubectl run -i --tty --rm debug --image=postgres --restart=Never -- /bin/bash
VALUE created by our solution
Easier to troubleshoot environments, better security, less overhead on the k8s cluster
Acceptance Criteria
[ ] All tools we need to debug notify are in a custom docker image that is stored in the notify container registry (aws)
[ ] Shell commands are logged to a cloudwatch log group
Description
As an operator of notify, I want to be able to quickly spin up a debug pod that has the necessary tools to troubleshoot the system while also maintaining a level of security and audibility.
WHY are we building?
The existing jump box is running all of the time which is not ideal. Additionally the tools required to troubleshoot (pgsql etc) are not installed by default. Finally, any commands run are not sent to security log groups for auditing.
WHAT are we building?
We can create a custom jump box image that has the tools we need, and redirects all shell output to the global stdout so that fluent bit picks it up. We can also use a variation of the following command to only run the pod when needed: kubectl run -i --tty --rm debug --image=postgres --restart=Never -- /bin/bash
VALUE created by our solution
Easier to troubleshoot environments, better security, less overhead on the k8s cluster
Acceptance Criteria
QA Steps
TODO