見ているサイト上に露出している機密情報(APIトークン、IPアドレスなど)を見つけるブラウザ拡張を作りました SecretlintというAPIトークンなどの機密情報がファイル内に含まれているかをチェックできるツールを書いています。 Secretlintはコマンドラインツールとして動くので、主にCIやGitのpre-commit hookを利用して、リポジトリに機密情報が入るのを防止できます。 SecretlintでAPIトークンや秘密鍵などのコミットを防止する | Web Scratch 一方で、実際のウェブサービスなどは機密情報がファイルにハードコードされているわけではなく(Secrelint自体がこういうハードコードを防ぐツールです)、環境変数やDatabaseに保存していると思います。 このような場合にも、コードのミスなどによって公開するべきではない情報(秘密鍵、APIトークン、Sl
悩みに悩んだ Kubernetes Secrets の管理方法、External Secrets を選んだ理由 | PLAID engineer blog
悩みに悩んだ Kubernetes Secrets の管理方法、External Secrets を選んだ理由#ops#Kubernetes#k8s#gitops#secret
本記事ではDockerにおける秘密情報を (I) コンテナを起動する際に使用する秘密情報 と (II) イメージをビルドする際に必要となる秘密情報 に分類して考え、特に後者を安全に取り扱うための方法について整理します。 コンテナ起動時の秘密情報とイメージビルド時の秘密情報 (I) コンテナを起動する際に使用する秘密情報としては、例えば mysql イメージ の環境変数 MYSQL_ROOT_PASSWORD があります。コンテナの起動時にこの環境変数を与えると MySQL の root ユーザーのパスワードがその値になるというものです。 あるいは、例えば Laravel などのWebアプリケーションで、バックエンドDBへの接続情報を含んだ設定ファイルを Docker ホスト側に用意しておき、コンテナ起動時にその設定ファイルをマウントするというようなケースも考えられます。 いずれにしても、こ
GitHub Actions + google-github-actions/auth で GCP keyless CI/CD
GitHub Actions + google-github-actions/auth で GCP keyless CI/CD 追記 2021/10/08 v0.3.1 にすると aud 周りの設定変更が必要 ソース 追記 2021/10/07 OIDCトークン発行元のURLが変更になったようです ソース 要約： GitHub ActionsでCI/CD的なことやろうとしたとき、SecretsとかにGCPのService AccountのKeyとか置かなくてもデプロイとかできるようになったらしいのでやったらできた。 経緯 AWS federation comes to GitHub Actions という記事が出て。 GitHub ActionsのOIDC id tokenでGCPにアクセスしてみた といってGCPでもやれるか確かめた人が出て。 Use gcloud with creden
GitHub - tellerops/teller: Cloud native secrets management for developers - never leave your command line for secrets.
You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert
はじめに KubernetesではWebアプリケーションから業務用のワークフロー（バッチ処理とか）に至るまで様々なアプリケーションを動かすことができるが、現実世界において苦労するポイントの1つは、ワークロードに秘匿情報を渡すための方法である。 例えば、アプリケーションの上でデータベースに接続するために必要なエンドポイントの情報やパスワードなどの認証情報は、アプリケーションのソースコードに直接書くことはご法度だし、コンテナ化する際に内包することも原則タブーである。また環境変数として注入する場合でも、その情報が物理ディスクに残ってしまう場合などを考え最新の注意を払う必要がある。 ここではKubernetes上のワークロードに秘匿情報をできるだけ安全にわたすための方法を運用者・開発者の目線で考える。 Kubernetesが持つ外部情報注入の仕組み Kubernetesの場合、アプリケーションに情
Google Colab上で秘匿情報を安全に使うために、Google Cloud Secret Managerを使う
やりたいこと kaggleなどのコンペ参加時にColabで計算して、wandbなどの実験管理ツールを使いたい。 現状wandbなどのAPI keyが生のままColabに貼っているので、そのままgithubにpushできない。 driveにtxtやyamlファイルを置いて管理すると、自分の性格上散らかすと分かっているので、GCPのサービスを使ってバージョンを含めて一括管理したい。 やったこと GCPのSecret Managerを使ってAPI keyを秘匿化して、Colabで呼び出した。 やりかた GCP上の設定 自分のGCPのコンソールを立ち上げて、Secret Manager APIを有効化する。 そのままUI上で作成する。 有効化されているのを確認する。 これで設定は終わり。 Colab上の設定 参考googleの公式レポジトリ
CX事業本部Delivery部のアベシです。 この記事ではgit-secrets使用してAWSアクセスキーのコミットを防止する仕組みの導入方法について紹介します。 弊社の以下のブログにあるような実際の出来事では、アクセスキーが流出してから10分程度でマイニングに不正利用されてます。※ 弊社作業による流出ではありません。 【実録】アクセスキー流出、攻撃者のとった行動とその対策 このように、アクセスキーは流出するとすぐに利用されてしまうほど狙われやすい認証情報となっています。 このような被害を無くすために、AWSを使う方には是非今回のような対策をしていただけたらなと思います。 git-secretsについて git-secretsに登録したパターンに合致するシークレット情報が、コードに含まれていないかチェックできます。 GitHub - awslabs/git-secrets 実装方法の概要
初めに IAMのアクセスキーが漏洩してしまった際に、漏洩を検知して対象のIAMアクセスキーを削除する仕組みを作る必要があったのでその内容について記載します。 構成 Trusted Adviserのルールを利用してEventBridegeで検知し、SNSを利用して通知し、Step FunctionsとLambdaで検知したIAMアクセスキーを削除します。 構成としては以下のようになります。 ※この構成はTrusted Adviserがバージニア北部リージョンでしか情報を取得できない関係で、バージニア北部リージョンで作成する必要があります。 今回は以下のTrusted Advisor toolsを参考にしました。 Trusted Adviser Trusted Adviserでは有効化しておけば特に設定しておくことはないです。 「漏洩したアクセスキー」のルールを使用してIAMアクセスキーの漏洩
GitOpsでも秘匿情報をバッチリ扱う方法、SealedSecretとは？ / How to manage credentials on GitOps
GitOpsでも秘匿情報をバッチリ扱う方法、SealedSecretとは？ / How to manage credentials on GitOps GitOpsで秘匿情報を扱う方法を紹介する資料です。SealedSecretというツールを中心に紹介しますが、それ以外のkamus, Hashicorp Vault, kubesealといった多くのツールも紹介します。 @Kubernetes Meetup Tokyo #21 - Cloud Native CI/CD
SecretlintはAPIトークンや秘密鍵のようなリポジトリにコミットしてはいけないデータを含んだファイルがないかをチェックするツールです。 Secretlintが見つけられるCredentials(秘匿情報)はプラグインで拡張できるようになっていて、npm、AWS、GCP、Slack、SSH秘密鍵、ベーシック認証などの検知に対応しています。 Gitのpre-commit hookやCIサービス上でSecretlintを使ってファイルの中身をチェックすることで、 リポジトリにうっかりCredentialsをコミットしてしまうことを防止する目的のLintツールです。 Credentials(秘匿情報)のチェックに特化したESLintやtextlintのようなLintツールです。 まずチェックしてみよう SecretlintはDockerかNode.jsが入っている環境なら次のコマンドで、現
リポジトリに載せたくない秘匿情報をチェックする Secretlint を触った - 継続は力なり
タダです. リポジトリに AWS のアクセスキー,シークレットアクセスキーを載せてしまって情報の漏洩といったことが起こりうるので,その予防策としてSecretlintを触る機会があったためこの記事に備忘録をまとめます. Secretlint とは Secretlint 導入 Secretlint のルール Secretlint を実行する まとめ 参考情報 Secretlint とは Secretlint は azu さんが開発されている秘匿情報のコミットを防ぐツールです. github.com Secretlint 導入 Docker イメージも提供されていますが,今回は npm で導入し,npx secretlint --initで Secretlint の設定ファイルを生成します. $ npm install secretlint @secretlint/secretlint-rul
https://about.codecov.io/security-update/ 2021/04/15、コードカバレッジの記録サービスであるCodecovから上記のようなアナウンスが有った 端的に言うと、CodecovがCI上で使っているカバレッジファイルのアップロードスクリプトであるBashスクリプトが何者かに書き換えられ、それが３ヶ月（01/31~）気が付かなかったらしい Bash Scriptは以下のようにCurl経由で直接形で実行する形式だった code:bash bash <(curl -s xxxxx/xxx.sh) で、今回このリモートにあるbashファイルがまるごと書き換えられたとのこと その結果、これを使っている各種プロジェクトのCIマシン上の機密データがぶっこ抜かれたらしい 何がどこからどの程度抜かれたのかは不明なのですが、上記レポートによればそういったデータが外部の
GitHub - aws/aws-secretsmanager-agent: The AWS Secrets Manager Agent is a local HTTP service that you can install and use in your compute environments to read secrets from Secrets Manager and cache them in memory.
The AWS Secrets Manager Agent is a client-side HTTP service that you can use to standardize consumption of secrets from Secrets Manager across environments such as AWS Lambda, Amazon Elastic Container Service, Amazon Elastic Kubernetes Service, and Amazon Elastic Compute Cloud. The Secrets Manager Agent can retrieve and cache secrets in memory so that your applications can consume secrets directly
Pod が使用できる Secret を制限する方法 Kubrenetes では、ServiceAccount リソースに kubernetes.io/enforce-mountable-secrets アノテーションを true で設定することで、その ServiceAccount で実行する Pod が secrets フィールドで指定された同一 Namespace の Secret しか使用できない (マウントできない) ように制限する機能 1 が提供されています。 apiVersion: v1 kind: ServiceAccount metadata: name: test-sa annotations: kubernetes.io/enforce-mountable-secrets: "true" secrets: - name: mountable-secret-1 - nam
シークレットについて シークレットは、組織、リポジトリ、またはリポジトリ環境内に作成する変数です。 作成したシークレットは、GitHub Actionsワークフローで利用できます。 GitHub Actions でシークレットを読み取ることができるのは、シークレットをワークフローに明示的に含める場合のみです。 Organizationレベルで保存されたシークレットについては、アクセスポリシーを使ってどのリポジトリがOrganizationのシークレットを利用できる化を制御できます。 Organizationレベルのシークレットを利用すると、複数のリポジトリ間でシークレットを共有できるので、重複してシークレットを作成する必要が軽減されます。 一カ所でOrganizationシークレットを更新すれば、そのシークレットを使うすべてのリポジトリワークフローにその変更が有効になることを保証できます。
Vault Secrets Operator と HCP Vault で Kubernetes のシークレットを管理しよう - APC 技術ブログ
はじめまして、ACS 事業部の埜下です。 みなさんは Kubernetes のシークレットはどのように管理されていますか？ 先日、HashiCorp 社から「Vault Secrets Operator」がプレビュー公開されました。 また、2023/2 には HCP Vault on Azure が GA しました。 そこで、今回はシークレット管理についてお伝えしつつ、Vault Secrets Operator と HCP Vault on Azure を組み合わせたシークレット管理の動作確認の内容についてもお伝えします。 はじめに シークレット管理の必要性 Vault Secrets Operator について HCP Vault on Azure について 今回の目的 前提条件 環境構築 HashiCorp Virtual Network 作成 Azure VNet ピアリング HV
Securing Terraform monorepo CI | Mercari Engineering
This article is a part of Developer Productivity Engineering Camp blog series, brought to you by Daisuke FUJITA (@dtan4) from the Platform Infra Team. At Mercari, one of the core platform tenets is to manage all cloud infrastructure in declarative configurations. Our main cloud provider is Google Cloud Platform (GCP) and we use HashiCorp Terraform to manage infrastructure as code. The Platform Inf
ヤフー株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。LINEヤフー Tech Blog ヤフー社内のKubernetes環境における、シークレットデータの扱いに関して紹介します。 ヤフーでは、Secrets Store CSI Driver（以下、SSCD）というプロジェクトを、社内のKubernetesプラットフォーム向けにエコシステムとして導入しました。なぜ私たちがSSCDをエコシステムとして導入する必要があったのかを説明します。 社内データ保護の一環として、ヤフーでは自社開発のSecrets Managerを運用しています。各シークレットデータの保護に加え、RevokeやバージョンコントロールなどパブリッククラウドにあるSecrets Managerと同様の機能を有しています。ストアしているシークレットデータは
Infisical is an open-source end-to-end platform to manage secrets and configuration across your team and infrastructure.
All-in-one platform to securely manage application configuration and secrets across your team and infrastructure.
Developer Tools | 1Password
Create, manage, and enforce policies to govern how and where employees use 1Password.
GitHub - liamg/gitjacker: 🔪 Leak git repositories from misconfigured websites
You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert
Vault Secrets Operator: A new method for Kubernetes integration
TerraformInfrastructure as code provisioning
Managing API keys, database passwords, and other secret variables in CI has always been a tiny bit painful and often a massive security loophole in most organisations. Let’s try to see how we can improve the situation with AWS Secrets Manager, this simple wrapper, and your favorite CI provider (in our case, Gitlab CI — but it should work relatively similarly with most providers). The problemBy def
Kubernetes(EKS)で秘密情報をどう扱うか
まとめ 秘密情報をEKS上で楽に管理したい。 これまでは秘密情報を暗号化したファイルを使って注入してた 変数ごとに何が変更されたかを確認するのが面倒 AWS KMSで暗号化してたのでAWS CLIのインストールのためにPythonを入れるのが微妙 KubernetesのSecretをそのまま使うのは避けたい Base64してるだけで暗号化してない k8sの権限の強い人からは見えてしまう 環境変数の値だけを暗号化してPod内で複合 リポジトリに読める形でコミットできる 追加・変更されたか否かのレベルでなら確認できる Pod以外は複合できないためマルチテナントなk8sだと権限管理が楽 shushならバイナリ一個入れるだけですむ GKEに移っても実装できそうな規模なのでなんとかなりそう。 欠点もある バイナリを一個置く必要がある entrypoint/commandの変更が必須 起動時に暗号化し
English article is here. 要約以下の条件を満たすときにDockerイメージ内に残留する.gitフォルダーから機密情報が流出する恐れがあります。 過去に機密情報をcommitしたが消していない.gitフォルダーとDockerfileが同じ階層のディレクトリにあるDockerfileでCOPYやADD命令でカレントディレクトリを指定してファイルを移している(例 : COPY . /app)Dockerイメージを誰でもダウンロードできる場所にアップロードするDockerfileを変更せずにできる対策としては .dockerignoreファイルで.gitフォルダーを指定するが挙げられます。 WaniCTF'21-spring 「Git Master」4/30 ~ 5/2に大阪大学CTFサークルWani Hackaseが開催した初心者向けのCTF大会WaniCTF'21-sp
Kubernetes Service Account As Multi-Cloud Identity / Cloud Native Security Conference 2022 / #CNSec2022
Kubernetes Service Account As Multi-Cloud Identity / Cloud Native Security Conference 2022 / #CNSec2022
Secret
このページに記載されている情報は古い可能性があります このページの更新日は英語版よりも古いため、記載されている情報が古い可能性があります。最新の情報をご覧になりたい方は英語版のページをご覧ください: Secrets Secretとは、パスワードやトークン、キーなどの少量の機密データを含むオブジェクトのことです。 このような情報は、Secretを用いないとPodの定義やコンテナイメージに直接記載することになってしまうかもしれません。 Secretを使用すれば、アプリケーションコードに機密データを含める必要がなくなります。 なぜなら、Secretは、それを使用するPodとは独立して作成することができ、 Podの作成、閲覧、編集といったワークフローの中でSecret(およびそのデータ)が漏洩する危険性が低くなるためです。 また、Kubernetesやクラスター内で動作するアプリケーションは、不揮
secret_key_baseがどういうふうに扱われているか 2019-06-23 06:14 Railsアプリを本番デプロイしたらsecret_key_baseが未定義っておこられたので、どういう扱いになってるのか確認してみた。 確認したRailsのバージョンは6.0.0.rc1。 はじめにまとめ secret_key_baseの設定場所は4箇所ある: 環境変数: ENV["SECRET_KEY_BASE"] credencials: config/credentials.yml.enc secrets: config/secrets.yml （Encrypted secretsが有効ならconfig/secrets.yml.enc） tmp/development_secret.txt 環境ごとの評価順: developmentかtestなら、secrets、tmp/developme
【git】GnuPG x git-secretでcredentialなどの秘匿情報を含むファイルを暗号化して安全にcommitする - その2: 複数人で扱う場合 - tweeeetyのぶろぐ的めも
はじめに gitやgithubでcredentialやtokenなどの秘匿情報を含むファイルを暗号化してcommitするメモを書きました。 【git】GnuPG x git-secretでcredentialなどの秘匿情報を含むファイルを暗号化して安全にcommitする - その1 今回は、それを複数人であつかう場合のメモです。 アジェンダ はじめに アジェンダ 1. ながれのイメージ 2. [Aさん] 秘匿情報をgit secret管理化にする gpgでkeyの生成 リポジトリを用意する git-secret管理化にする git push する 3. [Bさん] gpg keyの作成＆エクスポート gpg keyの作成＆エクスポート この時点で復号化を試してみる 4. [Aさん] GPGとgit-secretにBさん情報を設定 GPGにB -san鍵をインポート git-secretにB
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
見ているサイト上に露出している機密情報(APIトークン、IPアドレスなど)を見つけるブラウザ拡張を作りました
Dockerイメージビルド時の秘密情報の扱い方に関するまとめ | terashim.com
Kubernetesにおける秘匿情報の扱い方を考える - inductor's blog
git-secretsを使用してAWSアクセスキーのコミットを防ぐ方法の紹介 | DevelopersIO
AWSでアクセスキーが漏洩した時に検知・削除する仕組みを実装する - Qiita
SecretlintでAPIトークンや秘密鍵などのコミットを防止する
CodecovのBash Uploaderが書き換えられた件 - keroxpのScrapbox
Kubernetes で Pod が使用できる Secret を制限する方法 - Qiita
GitHub Actions でのシークレットの使用 - GitHub Docs
より安全なKubernetes Secrets管理のためのエコシステムの開発
Managing secrets in CI/CD with AWS Secrets Manager
外部公開するDockerイメージを作るときは COPY . に気をつけよう
secret_key_baseがどういうふうに扱われているか | oknm.jp