What if your Kubernetes cluster simply refused to run unsigned images? I spent some time experimenting with enforcing image provenance in a small Kubernetes setup using MicroK8s. The idea was simple: Only container images with valid cryptographic signatures are allowed to run in the cluster. For this I used: GitLab CI/CD (build + signing pipeline) Cosign / Sigstore (image signing) Kyverno (admissi
Windows에서 한/영 전환할 때마다 키보드 종류 설정 → 재부팅 → 다시 풀려있음 → 또 재부팅... 이 무한루프 겪어보신 분 있을 겁니다. 이런 유틸들은 예전부터 많이 있었습니다. 그런데 막상 필요할 때 검색하면 잘 안 나오고 ("개똥도 약에 쓰려면 없다"고), 어쩌다 찾아도 출처 모를 binary 파일만 굴러다녀 실행하기 불안하기도 합니다. 그래서 직접 만들어 소스코드까지 공개합니다. GitHub: https://github.com/coverboy/hangul_switcher Windows 10/11에서 Shift+Space → 한/영 IME 토글 백그라운드 트레이 상주 키보드 종류(PC/AT 101키 종류 3) 설정·재부팅 불필요 블루투스 · 노트북 내장 · USB · 외장 모든 키보드에서 동일 동
Most teams I have worked with have one auth test in their suite. It looks like this: test('valid token verifies', () => { const token = signSync({ sub: 'user-1', aud: 'api://backend' }, secret); const result = verify(token, options); expect(result.valid).toBe(true); }); That test is fine. It is also a smoke test, not a regression suite. It catches the case where verification is completely b
The on-call alert at 02:14 said auth_5xx_rate spiked from 0.01 to 31.4. Not a deploy window. Not a traffic spike. Just thirty-one percent of authenticated requests failing for ~four minutes, then back to baseline. The cause was a JWKS rotation on the issuer side. New keys came in. Old keys went out. Caches in our service didn't refresh fast enough. Tokens signed with the new key were rejected beca