AK.広く浅くなITな人

社会人10年目インフラエンジニアです。

[yousukezan @yousukezan]

この1年、日本で公表され��大規模な情報流出・漏えい可能性事案 TOP10

1位 EPARKリラク＆エステ「PeakManager」 約3,300万件
2位 Gyazo 約2,362万件
3位 KDDI ISP向けメールシステム 約1,223万件
4位 九州電力送配電 約1,090万件
5位 Eストアー「ショップサーブ」 約885万件
6位 ムラウチドット��ム 約772万件
7位 タイムズカー 約660万件 <-New!!
8位 アフラック生命保険 約440万件
9位 2りんかん 約346万件
10位 ユニバーサル ミュージック 約311万件

【直近の主な事案】
ファインズ 約154万件
セイコーマート 約57万アカウント
OZmall 最大約44.8万件
東京メトロ「メトポ」 約5.9万件
※2025年9月29日〜2026年9月29日に公表された事案
※件数は各社公表値。人数・レコード数・延べ件数、「漏えいのおそれ」を含む
※Gyazoはこのほか画像メタデータ約4.9億件＋削除済み画像メタデータ約1.74億件の流出も確認

[Ayaan 🐧 @twtayaan]

A Google researcher says the Windows NT kernel still “puts Linux to shame” in many ways.

Laurie Kirk, a former Microsoft reverse engineer, argues that NT was built with a cleaner and more consistent security model.

Linux took a different path, adding capabilities, namespaces, cgroups and SELinux over time.

But her most controversial point is about AI agents.

Kirk argues that Linux permissions are spread across too many mechanisms, while NT handles resources, permissions and auditing more consistently.

She even says that if we designed an OS kernel from scratch in 2026, it probably wouldn’t look like Linux.

Linux engineers are already pushing back, defending the modular approach that helped Linux dominate servers, cloud and containers.

Windows vs Linux just got interesting again.

Full story: https://t.co/AaEj3YAGE0

[Akhilesh Mishra @livingdevops]

Kubernetes world is moving away from sidecar patterns.
Let me explain why.

A sidecar is a helper container. It sits next to your app container. Same pod. Same network. Same lifecycle.

People used sidecars for a lot of things.

Service mesh was the big one. Envoy would sit next to your app.
- It handled traffic. It handled retries and timeouts. It handled security between services(MTLS). Your app never knew it was there.

- Logging was another one. A small agent would sit next to your app. It would read the logs. It would ship them somewhere else.
- Metrics scraping worked the same way.
- Secrets injection too. Vault agent would run as a sidecar. It would fetch secrets and write them to a file.

This pattern felt smart. One app. Many helpers. No code changes needed.

But then problems showed up.

Every sidecar is another container.
That means more CPU, more memory.
One sidecar on ten pods is fine.
One sidecar on ten thousand pods is not fine.

Every sidecar can crash.
Every sidecar needs patching.
Every sidecar needs upgrading.
Multiply that by hundreds and thousands.

Startup order became a pain too.
- Sometimes the sidecar was not ready before the app started.
- Sometimes the sidecar died before the app finished its work. Small bugs. Big headaches.

Debugging got harder.
- Now you have two containers to check instead of one.

Cost added up quickly at scale.

So the industry asked a new question.

What if we do not need the sidecar at all?

Istio built something called an ambient mesh that required no sidecar injection.
The proxy moves completely outside the pod.

Cilium went even further by using eBPF (a kernel-level technology).
That means the networking logic lives in the kernel, so no sidecar container, and lightning-fast networking.

OpenTelemetry solved this for metrics and logs.
Instead of one sidecar per pod, you get one collector for many pods(runs as a DaemonSet and deployment).

Even Kubernetes noticed the pain.
In version 1.29, it gave sidecars a proper place in the pod lifecycle, fixing a lot of old bugs and startup issues.
It did not remove the sidecar. It just made it better.

Today we have two paths.
Some teams are removing sidecars completely.
Some teams are keeping sidecars but doing it the right way.

Where do you stand?

[Subhamoy @neo_subhamoy]

JSON Statham 😭

[Akhilesh Mishra @livingdevops]

Most Kubernetes engineers don't know these kubectl tricks that save hours during outages

𝗸𝘂𝗯𝗲𝗰𝘁𝗹 𝗴𝗲𝘁 𝗲𝘃𝗲𝗻𝘁𝘀 -𝗔 -𝘄 | 𝗴𝗿𝗲𝗽 -𝘃 "𝗡𝗼𝗿𝗺𝗮𝗹"
--> Watch only the bad stuff across the entire cluster
> It streams warnings and failures from every namespace in real time so you can catch issues before they turn into incidents.

𝗸𝘂𝗯𝗲𝗰𝘁𝗹 𝗱𝗶𝗳𝗳 -𝗳 𝗱𝗲𝗽𝗹𝗼𝘆𝗺𝗲𝗻𝘁.𝘆𝗮𝗺𝗹
--> See exactly what will change before applying
> It helps catch accidental changes like wrong image tags, deleted environment variables, or broken resource limits before deployment.

𝗸𝘂𝗯𝗲𝗰𝘁𝗹 𝗴𝗲𝘁 𝗽𝗼𝗱𝘀 -𝗔 --𝘀𝗼𝗿𝘁-𝗯𝘆='.𝘀𝘁𝗮𝘁𝘂𝘀.𝗰𝗼𝗻𝘁𝗮𝗶𝗻𝗲𝗿𝗦𝘁𝗮𝘁𝘂𝘀𝗲𝘀[𝟬].𝗿𝗲𝘀𝘁𝗮𝗿𝘁𝗖𝗼𝘂𝗻𝘁'
--> Find unstable pods instantly
> This sorts pods by restart count so the most unstable workloads appear first.

𝗸𝘂𝗯𝗲𝗰𝘁𝗹 𝘁𝗼𝗽 𝗽𝗼𝗱𝘀 -𝗔 --𝘀𝗼𝗿𝘁-𝗯𝘆=𝗺𝗲𝗺𝗼𝗿𝘆 --𝗰𝗼𝗻𝘁𝗮𝗶𝗻𝗲𝗿𝘀
--> Find who is actually consuming memory
> The `--containers` flag breaks usage down per container instead of showing only pod-level metrics.

𝗸𝘂𝗯𝗲𝗰𝘁𝗹 𝗱𝗲𝗯𝘂𝗴 -𝗶𝘁 <𝗽𝗼𝗱-𝗻𝗮𝗺𝗲> --𝗶𝗺𝗮𝗴𝗲=𝗯𝘂𝘀𝘆𝗯𝗼𝘅 --𝗰𝗼𝗽𝘆-𝘁𝗼=𝗱𝗲𝗯𝘂𝗴-𝗽𝗼𝗱
--> Debug a pod without touching the original workload
> This creates a copy of the failing pod with a debug container attached for investigation.

𝗸𝘂𝗯𝗲𝗰𝘁𝗹 𝗴𝗲𝘁 𝗽𝗼𝗱𝘀 -𝗔 -𝗼 𝘄𝗶𝗱𝗲 --𝗳𝗶𝗲𝗹𝗱-𝘀𝗲𝗹𝗲𝗰𝘁𝗼𝗿 𝘀𝗽𝗲𝗰.𝗻𝗼𝗱𝗲𝗡𝗮𝗺𝗲=<𝗻𝗼𝗱𝗲-𝗻𝗮𝗺𝗲>
--> See every workload sitting on a node before you touch it
> Run this before cordoning or draining a node during maintenance.

𝗸𝘂𝗯𝗲𝗰𝘁𝗹 𝗴𝗲𝘁 𝗲𝘃𝗲𝗻𝘁𝘀 --𝗳𝗶𝗲𝗹𝗱-𝘀𝗲𝗹𝗲𝗰𝘁𝗼𝗿 𝗶𝗻𝘃𝗼𝗹𝘃𝗲𝗱𝗢𝗯𝗷𝗲𝗰𝘁.𝗻𝗮𝗺𝗲=<𝗽𝗼𝗱-𝗻𝗮𝗺𝗲> --𝘀𝗼𝗿𝘁-𝗯𝘆='.𝗹𝗮𝘀𝘁𝗧𝗶𝗺𝗲𝘀𝘁𝗮𝗺𝗽'

--> Get the full chronological event history for one object.
> kubectl describe only shows recent events. This pulls the complete timeline for a specific pod, useful when you're trying to reconstruct what happened over the last hour.

[wang @wangzhr4]

In C programming, do not use:
int, char, unsigned int, unsigned char...

Please use:
uint8_t, int8_t, int32_t, int64_t...

[Akhilesh Mishra @livingdevops]

These Linux commands helped me most in last 13 years of IT career

Daily stuff:
• ps aux | grep {process} - Find that sneaky process
�� lsof -i :{port} - Who's hogging that port?
• df -h - The classic "we're out of space" checker
• netstat -tulpn - Network connection detective
• kubectl get pods | grep -i error - K8s trouble finder

Log related commands:
• tail -f /var/log/* - Real-time log watcher
• journalctl -fu service-name - SystemD log stalker
• grep -r "error" . - The error hunter
• zcat access.log.gz | grep "500" - Compressed log ninja
• less +F - The better tail command

Container cli:
• docker ps --format '{{.Names}} {{.Status}}' - Clean status check
• docker stats --no-stream - Quick resource check
• crictl logs {container} - Raw container stories
• docker exec -it - The container backdoor
• podman top - Process peek inside containers

System Detectives:
• htop - System resource storyteller
• iostat -xz 1 - Disk performance poet
• free -h - Memory mystery solver
• vmstat 1 - System vital signs
• dmesg -T | tail - Kernel's recent gossip

Network stuff:
• curl -v - HTTP conversation debugger
• dig +short - Quick DNS lookup
• ss -tunlp - Socket statistics simplified
• iptables -L - Firewall rule reader
• traceroute - Path finder

File and stuff:
• find . -name "*.yaml" -type f - YAML hunter
• rsync -avz - Better file copier
• tar -xvf - The unzipper (yes, we all google this)
• ln -s - Symlink wizard
• chmod +x - Make it executable

Performance:
• strace -p {pid} - System call spy
• tcpdump -i any - Network packet sniffer
• sar -n DEV 1 - Network stats watch
• uptime - Load average at a glance
• top -c - Classic process viewer

Git Essentials:
• git log --oneline - History simplified
• git reset --hard HEAD^ - The "oops" eraser
• git stash - The work hider
• git diff --cached - What's staged?
• git blame - The "who did this?" resolver

Quick Fixes:
• sudo !! - Run last command with sudo
• ctrl+r - Command history search
• history | grep - Command time machine
• alias - Command shortcut maker
• watch - Command repeater

[Tech Fusionist | Kushal Gangil @techyoutbe]

Kubernetes, Part 2: 4 More Visual Guides You Should Save. 🧵

Resource Management → Security → Configuration → Observability

[シンジ☁Shinji @sudachikawaii]

セキュリティちょっと分かるので解説します。

従業員のPCから「管理者権限を外す」が意味不明に見えるのは、サイバー攻撃の防御だけで評価しているからで、実務上の理由は主に二つあります。

1. 企業統制・監査の側面
EDR、MDM、資産管理、SASEクライアントは、ローカル管理者であれば原理的に停止・削除できます。主要製品にはタンパープロテクション（改ざん防止）があり通常のアンインストールは防げますが、MDM登録の解除、設定の改変、脆弱な正規ドライバを持ち込んでEDRを無効化する手法（BYOVD）などは管理者権限があれば残ります。すると「全端末にエージェントが入っている」「導入ソフトを把握している」「脆弱性にパッチが当たっている」という、監査で証明すべき前提を、エージェントの死活監視や準拠デバイス要求などの補償統制で別途担保しなければならなくなります。不可能ではありませんが、統制の設計と説明の負荷は確実に上がります。ユーザーが自由にソフトを入れられる環境では、ライセンス管理も同じ理由で崩れます。

2. 悪意ある社員への対処
内部不正の持ち出し自体は正規の権限内で行われることが多く、それを止めるのはDLPやログ監査の役割です。管理者権限が効くのは「証跡の完全性」です。管理者権限があれば、監視エージェントの停止、ローカルログの消去、端末側の転送制限の解除といった「足跡を消す」行為が可能になります。ユーザー権限であればこれらは昇格を伴うため、EDRの検知対象になり得て、クラウド側に証跡が残ります。「誰が何をしたか」を後から証明できることが、懲戒や法的対応の前提です。

3. 「今の攻撃はマルウェアレスだから無意味」なのか
インフォスティーラーによる認証情報やセッションCookieの窃取はユーザー権限で成立し、盗んだ認証情報でSaaSに直接入る攻撃は端末の管理者権限と無関係です。管理者権限の剥奪は初期侵入を止める統制ではありません。
一方で、端末に入った後の横展開・永続化・EDR無効化には管理者権限が必要です。LSASSからの認証情報取得もBYOVDも管理者が前提です。EDRが優秀だから管理者を渡してよいのではなく、EDRが優秀であり続けるために管理者を外す、が正しい順序です。
なお「ユーザー権限にしている企業に限って���理者パスワードが共通」という指摘は正しく、その解はLAPS（ローカル管理者���スワードの自動ランダム化）であって、全員に管理者を配ることではありません。

4. 本当に直すべき箇所
元投稿を真とするなら、生産性を削っているのは権限剥奪ではなく「申請して情シスが入れる」という配布方式です。MDM/UEM（Intune、Jamf等）の承認済みカタログによるセルフサービス配布と、必要時だけのJIT昇格に置き換えれば、統制と生産性は両立します。元投稿で起きているのは統制の是非の問題ではなく、運用設計の古さの問題だと思います。

[AK.広く浅くなITな人 @itnomono33]

ブルーピル攻撃って名称で似た概念あるらしい

[SAKON @sakon310]

@redsasakou OA端末にはEDR入ってても、その上に作ったローカル開発環境コンテナは独自管理でEDR入ってないので、汚染されたOSSからマルウェア入っても検知できないことがありますね。
リモート操作ツールはサポート詐欺で悪用／インストールさせる事が多い印象です。

[AK.広く浅くなITな人 @itnomono33]

jsonいけるのか、、、、
ありがたいポスト

[Ivan Velichko @iximiuz]

TIL: `ip -br address` shows a neat brief table with interface names, states, and addresses.

I've been breaking my eyes looking for the IP addresses in the cryptic full output for way too many years. But no more!

And a kind reminder: `ip -json address` is also a thing.

[大石昌良【オーイシマサヨシ】 @Masayoshi_Oishi]

これ作った奴先生怒らないから出てきなさい

[Cyber Security News @The_Cyber_News]

‼️ Revolut Data Breach Exposes Customers’ Passport Copies & Full Transaction Histories to Hackers

Details: https://t.co/h7lrKqbfMY

Revolut has disclosed a data-security incident in which sensitive customer information was released after the financial technology company received a fraudulent request that appeared to originate from a legitimate government agency.

The incident reportedly exposed highly sensitive Know Your Customer (KYC) documentation and detailed financial records belonging to a limited number of users, including passport or driver’s license copies, identity-verification selfies, account statements, and complete transaction histories that included Bitcoin-related activity.

#cybersecuritynews

[International Cyber Digest @IntCyberDigest]

‼️ Microsoft's patch for Windows Defender zero-day ShieldBreak (CVE-2026-69414) is still bypassable, a new PoC called ShieldCrash was published today by researcher Nightmare-Eclipse. It demonstrates arbitrary file read as SYSTEM on all supported Windows versions running the September 2026 patches.

The researcher describes it as a "skeleton PoC" and says a full SYSTEM exploit may follow.

[りょま＠ゼロトラスト限界課長 @ryoma_it_infra]

「お前の話、マジで何言ってんのかわかんねえよ」をオブラートに包むことが多いのがビシネスの場である

[yousukezan @yousukezan]

一昨年くらいAIがブラウザのreCAPTCHAをバイパスできるかが話題だった気がするけど、今はもう当たり前のようにバイパスできるらしい

[Cyber Security News @The_Cyber_News]

Switzerland Moves Away From Microsoft 365 to Open-Source Alternatives

More Details: https://t.co/qSPa2Yffh2

Switzerland’s federal administration is preparing to test a sovereign, open-source digital workplace that could reduce its long-term dependence on Microsoft 365 for sensitive government operations.

By the end of 2027, approximately 3,000 employees involved in particularly critical business processes are expected to have access to the sovereign platform.

The planned environment will provide core office capabilities, including email, calendars, document and presentation editing, telephony, file storage, collaboration tools, and audio and video conferencing.

#cybersecuritynews

[yousukezan @yousukezan]

Bitcoinのサイドチェーン「Liquid Network」で、裏付け資産を保管するフェデレーションウォレットから約4000BTC、約3億2000万ドル相当が引き出された。実行者は「ホワイトハット」を名乗り、脆弱性修正後に大半を返還すると主張している。

Liquidによると、事件前のウォレット残高は約4200BTCで、約95％が失われた。Liquidはブリッジノードを停止し、取引所にL-BTCの入出金停止を要請した。

実行者はBitcoin取引に埋め込んだメッセージでBlockstreamへ連絡を求め、脆弱性を修正して全ノードを更新した後に資金の大半を返すと表明した。Blockstreamはオンチェーンで連絡先を返し、その後は暗号化通信へ移行したという。

資金はSideSwap経由でPeg-out Authorization Key（PAK）を使って引き出されたが、SideSwapの鍵や他のPAKが侵害された形跡はないとされる。どのようにほぼ全額が認可済みpeg-outとして引き出されたか��調査中だ。Liquid上の他資産やBitcoin本体には直接の影響は確認されていない。
https://t.co/2oO3AbjWMp

[Ayaan 🐧 @twtayaan]

This is the only site you need to actually get good at Docker.

It’ll put you way ahead of anyone just watching random Docker YouTube playlists.

And it’s completely free, with 11+ hours of hands-on content and exercises. 🐳

https://t.co/ZPl8qJUpoW

[AK.広く浅くなITな人 @itnomono33]

レイヤごとの切り分けコマンド手札をどれだけ持ってるかでその人の実力って見えてくる気がするな。

名前解決はnslookupとdigだけで挑むと、
hostsにやられる。