2021/11/04 CloudNative Days Tokyo 2021 17:20-18:00 Track F 乗っ取れコンテナ!! 〜開発者から見たコンテナセキュリティの考え方〜 セッション動画 https://event.cloudnativedays.jp/cndt2021/talks/1187
2021/11/04 CloudNative Days Tokyo 2021 17:20-18:00 Track F 乗っ取れコンテナ!! 〜開発者から見たコンテナセキュリティの考え方〜 セッション動画 https://event.cloudnativedays.jp/cndt2021/talks/1187
CloudNative Days Tokyo 2021の発表資料です。 https://event.cloudnativedays.jp/cndt2021/talks/1207 補足資料 https://git.io/operator-bestpractice
This is a slide for CloudNative Days Tokyo 2021 Keynote (https://event.cloudnativedays.jp/cndt2021/talks/1208). At Mercari, we've been building internal development platform top on Kubernetes and Cloud-native ecosystem for more than 3 years. The history of building the platform is the history of security hardening. In this session, I'm going to introduce what kind of security hardening we've imple
Introducing GKE image streaming for fast application startup and autoscaling We’re excited to announce the general availability of a new feature in Google Kubernetes Engine (GKE): image streaming. This revolutionary GKE feature has the potential to drastically improve your application scale-up time, allowing you to respond to increased user demand more rapidly, and save money by provisioning less
長い記事なので先に結論を書きます。 Spectre の登場で、ウェブサイトに必要とされるセキュリティ要件は増えました。具体的に必要な対策は下記の通りです。 すべてのリソースは Cross-Origin-Resource-Policy ヘッダーを使って cross-origin なドキュメントへの読み込みを制御する。 HTML ドキュメントには X-Frame-Options ヘッダーもしくは Content-Security-Policy (CSP) ヘッダーの frame-ancestors ディレクティブを追加して、cross-origin なページへの iframe による埋め込みを制御する。 HTML ドキュメントには Cross-Origin-Opener-Policy ヘッダーを追加して popup ウィンドウとして開かれた場合の cross-origin なページとのコミュニ
Scaling Kubernetes Tenant Management with Hierarchical Namespaces Controller Author: @deeeeeeeet from Platform Developer Experience Team Three years ago, we took the decision to break our monolithic API into microservices, and move from the physical machine deployment on-premise to container deployment on GCP by using Google Kubernetes Engine (GKE). We architected our Kubernetes cluster with multi
はじめに ソフトウェアプロジェクトには不思議な性質があります。現状のスケジュールに課題を感じて、短くするために人員を投下しても、なかなか思い通りに短くならない。それどころか悪化してしまうことがあります。場合によってはプロジェクト自体が破綻して失敗してしまうことすらあります。 今回は、このようなソフトウェアプロジェクトに潜む直感に反する性質を数理的なモデルを介して理解していく試みです。ある種の思考実験としてお楽しみください。 宣伝 Qiitaさんとコラボ企画でアドベントカレンダーをつくりました。 DXをめちゃくちゃ改善した話を募集しています。 https://qiita.com/advent-calendar/2021/dx-improvement 10人の妊婦がいても1ヶ月で一人の子供は生まれない これは誰かの技術力やプロジェクトマネジメント力に欠陥があるのではなく、「人月の神話」で有名な
多職種で実施したふりかえりで基本的なことに気付かされた/Basic key learnings from the pretests conducted in multiple professions
製薬事業の拡大を牽引する、新組織立ち上げます。製薬業界の変革を通じて、医療の発展へ貢献する。 Ubie Pharma Consulting こんにちは。Ubie 株式会社の開発組織 Ubie Discovery で BizDev をしています、Akira です。 2021年10月1日、Ubie株式会社の製薬事業の拡大を牽引するスケール組織を立ち上げました。製薬企業の課題を真に解決し、医療アウトカムを生み出すソリューションを社会実装していく専門性の高いコンサル集団でありたいという想いから、組織名を「Ubie Pharma Consulting(UPC)」としました。 UPCは現在、Ubie Discovery、Ubie Customer Science からの出向者のみで構成されています。プロパー社員は、まだいません。 この記事では、UPC立ち上げ背景、事業概要、将来目指す姿、そして、現在直
むかし、この国が深い森におおわれ、そこに太古からの神々がすんでいた頃から語り尽くされているドキュメントが更新されない問題について雑に書く。 実態が変わったのにドキュメントが更新されない問題はいつどの時代も絶えない。これにいちいち憤りを感じるのは不幸になるだけなので、何かしら対処を考えておかねばならない。パッと思いつくのは次のようなものだろうか。 使う 使わないから更新もされなくなる。定期的に使われるように設計して、そもそも使わない場合は消した方がいい いっそ参照回数が少ないドキュメントは自動でアーカイブしちゃうみたいな硬派なスタイルの方がいいのかも 詳細に書きすぎない 細かいところを書きすぎると保守できない。骨組みだけ大事にして、細かいところはフロー情報として分けて書くのがよい 管理者を置く ちゃんと更新されるようロールを作る。属人化しないようにロールを引き継ぐ設計も必要 個人的にはあんま
Read it now on the O’Reilly learning platform with a 10-day free trial. O’Reilly members get unlimited access to books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers. Securing, observing, and troubleshooting containerized workloads on Kubernetes can be daunting. It requires a range of considerations, from infrastructure choices and cluster configura
こんにちは。SRE部DATA-SREチームの塩崎です。Software Design誌の2021年9月号に弊社でのBigQuery活用事例を寄稿しましたので、書店などで見かけた際は購入していただけますと嬉しいです。 gihyo.jp さて、BigQueryはコンピュートとストレージを分離することで高いスケーラビリティを達成しているData WareHouse(DWH)です。しかし、そのアーキテクチャを採用したがゆえに権限モデルが複雑化し、初心者にとって理解の難しい挙動をすることもあります。この記事ではBigQueryの権限モデルをコンピュートとストレージの分離という観点から紐解きます。 なお、記事中に記載している費用は全てUS Multi Regionにおけるものです。asia-northeast-1 Resion(東京)とは異なりますので、ご注意ください。 よくあるエラーとそこから湧く疑
October 27, 2021 Since we introduced the new GitHub Issues earlier this year in a private beta, we've been working hard to expand access to all developers in order to make GitHub the best place to plan, track, and manage your work. Today, we are really excited to announce that we're moving into a public beta, and now everyone on GitHub.com has access to the new project tables and boards. 🎉 We've
October 27, 2021 Pull Request Merge Queue is now available in limited beta. Learn more about the feature and how to request early access. Why a merge queue? Maintaining high velocity and keeping your main branch green can be a challenge today. Many repositories try to do this by requiring all pull requests be up to date with the main branch before merging. This ensures the main branch is never upd
October 27, 2021 GitHub Actions now supports OpenID Connect (OIDC) for secure deployments to cloud, which uses short-lived tokens that are automatically rotated for each deployment. This enables: Seamless authentication between Cloud Providers and GitHub without the need for storing any long-lived cloud secrets in GitHub Cloud Admins can rely on the security mechanisms of their cloud provider to e
はじめに これらの横棒、コンピュータにとっては全て違うのですが 見分けがつくでしょうか? -˗ᅳ᭸‐‑‒–—―⁃⁻−▬─━➖ーㅡ﹘﹣-ー𐄐𐆑 郵便番号、住所、電話番号など、横棒が使われているデータを扱うとき、 人が入力したデータや購入したデータであると、同じ記号が使われていないことはよくあることです。 090-1234-5678 090᭸1234᭸5678 090‑1234‑5678 090−1234−5678 これらの電話番号の文字列も phone_no_list = ['090-1234-5678', '090᭸1234᭸5678', '090‑1234‑5678', '090−1234−5678'] # 文字をUnicodeコードポイントに変換 for n in phone_no_list: # 文字列の4番目の横棒の文字コードを見てみる print(n[3], ord(n[3]
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く