Kevin Herro kevherro
I hereby claim:
- I am kherro on github.
- I am kherro (https://keybase.io/kherro) on keybase.
- I have a public key ASD7yjYPMuh5nTznRgywaaPhTyfQjMbqEdRCmztcfIeHLAo
To claim this, I am signing this object:
- Microservices are independently deployable services modeled around a business domain
- Microservices are technology-agnostic
- Microservices communicate with each other via networks - making them a form of distributed system. They also encapsulate data storage and retrieval, exposing data, via well-defined interfaces. So databases are hidden inside the service boundary
- The GOAL of microservices is to have as small an interface as possible
| { | |
| "AWSEBDockerrunVersion": "1", | |
| "Image": { | |
| "Name": "<AWS_ACCOUNT_ID>.dkr.ecr.<AWS_REGION>.amazonaws.com/<NAME>:<TAG>", | |
| "Update": "true" | |
| }, | |
| "Ports": [ | |
| { | |
| "ContainerPort": "<CONTAINER_PORT>" | |
| } |
We need to reliably handle new, dynamic data that is generated on a continual basis and present it in real-time. A scooter's location could change in a matter of seconds - we need to be able to detect that change with minimal latency in order to provide accurate asset tracking.
Time gives our data meaning. Therefore, the raw data needs to be processed sequentially and incrementally over sliding time windows.
I took the following steps to enable HTTPS on stage.100.ucla.edu via SSL certificate installation. Use this guide as a reference for doing the same on the production server
Step 1: Place 100_ucla_edu_cert.cer and 100_ucla_edu_interm.cer on the production server (via SFTP, SCP, etc.) in any location
Step 2: Generate the chained certificate. Note the order here: the intermediate needs to come second!
$ cat 100_ucla_edu_cert.cer 100_ucla_edu_interm.cer >> certbundle.pemNote: you will need to modify certbundle.pem to include a line-break between the append
I hereby claim:
- I am kevinherro on github.
- I am kevin109104 (https://keybase.io/kevin109104) on keybase.
- I have a public key ASBdDxRXSKrpc-doqvHmuvBLc4BuJaZPPz2UGfNyMx_1Rwo
To claim this, I am signing this object:
- Yubikey: hardware based authentication solution that provides superior defense against phishing, eliminates account takeovers, enables compliance and offers expanded choices for strong authentication
- Fleetsmith: automates device setup, intelligence, patching, and security for your company’s Macs, iPhones, iPads, and Apple TVs.
- 1Password: secure password manager
- Vault: secure, store and tightly control access to tokens, passwords, certificates, encryption keys for protecting secrets and other sensitive data using a UI, CLI, or HTTP API
- Snyk: lives in GitHub repositories, automates finding & fixing vulnerabilities in your dependencies
- Keybase: encrypted chat
Trufflehog searches through git repositories for high [entropy][2] strings and secrets, digging deep into commit history
How it works: Trufflehog will go through the entire commit history of each branch, and check each diff from each commit, and check for secrets. This is both by regex and by entropy. For entropy checks, Trufflehog will evaluate the shannon entropy for both the base64 char set and hexidecimal char set for every blob of text greater than 20 characters comprised of those character sets in each diff. If at any point a high entropy string >20 characters is detected, it will print to the screen
+ Effective at finding secrets accidentally committed
+ Relatively easy to shove into a devops pipeline
+ Custom regexes can be added (things like s3 bucket detection)