■24/4/27 11:27PM
HELM
Helm Templateについて色々説明してみる #kubernetes - QiitaHighway to Helm (zenn.dev)Helmの概要とChart(チャート)の作り方 #Docker - QiitaHelm | 一般的な慣習
helmはコマンド一発だが生k8sはマニフェストファイルの数だけkubectl apply(delete)を繰り返す必要がある helm upgrade chart名 -f 環境毎yamlファイル
文法覚えるより繰り返した方がええんじゃないhelmはテンプレートフォルダ以下がマニフェスのようなもの ループ処理が記述可、関数が使える、関数を作れる
helm create <チャート名>templates/ マニフェスト (テンプレート)env/ 自分で作成するが環境毎に異なる値の入る変数を記述┣dev.yaml┣prd.yamlvalues.yaml 繰り返す値等 (dev/prd.yamlが優先され上書きされる) helm upgrade-install <release名> <Helmチャートの圧縮ファイル名>
●●helmテンプレートの文法 (.ファイル名.親.子で表す、.はルートオブジェクト、Valuesはvaluesオブジェクト、$変数:=値、ymlインデントはスペース2つ)●templates/deployment.yaml{{ $env := Values.environment }}{{ $serviceAccountName := Values.serviceAccountName }}image: {{ .Values.deployment.image }}:{{.Values deployment.imageTag }} //nginx:latestserviceAccountName: {{ $serviceAccountName }}-{{ $env }} //sample-sa-dev↑●values.yamdeployment: image: nginx imageTag: latestserviceAccountName: sample-sa●env/dev.yamlenvironment: dev●●helmテンプレートのループ (range～end)●templates/es.yamlspec: nodeSets: ((- range .Values.es.nodeSets }} name: {{ .name }} config: node.attr.zone: {{ .zone }} {{- end }}↑●values yamies: nodeSets: - name: node-a zone: asia-northeast1-a - name, node-b zone: asia-northeast1-b●●helmテンプレートのIF (if-end)●templates/ingress.yaml((- if .Values.ingress.enabled -))apiVension: networking k8s.io/v1kind: Ingress{(- end }}●env/prd.yamlingress: enabled: true●env/dev.yamlingress: enabled: false●●helmテンプレートの複数値 (toYaml、nindentは関数)●templates/ingress.yamlmetadata: annotations: {{- toYaml .Values.ingress.annotations | nindent 4 }}●values.yamlingress: annotations: kubernetes.io/ingress.global-static-ip-name: sample-ip-name kubernetes.io/ingress.class: "gce-internal"●●その他中括弧内側の前後にダッシュ {{--}} をつけることができ、前に付けた場合は前の半角スペースを、 後ろにつけた場合は改行コードを取り除くhoge: {{- $piyo := "aaa" -}} "fuga"/* */で囲まれた部分はコメント構文{{-/* a comment */ -}}●●_helpers.tpl https://qiita.com/showchan33/items/e95d3a6370e7c123962ahelm create [チャート名]で自動でtemplates ディレクトリに_helpers.tplが作成されるが、 partialsやhelpersと呼ばれる共通のコードブロック (defineアクションで定義されtemplateアクションで呼び出される)や、ヘルパー関数などが定義される。_アンスコ始まりのファイルは、他のテンプレートファイル内のどこからでも利用できるという共通部品。 これは内部にマニフェストがないものとみなされる。values.yamlが差し替え可能な変数、ローカル変数が定義したTemplateファイル内でのみ使える変数 _helpers.tplはチャート内で自由に使える変数●templates/_helpers.tpl{{- define "deployment" -}}apiVersion: apps/v1kind: Deploymentmetadata: labels: app: {{.name }} name: {{ .name }}-deploymentspec: replicas: {{ .replicas }} selector: matchLabels: app: {{ .name }} template: metadata: labels: app: {{.name}} spec: containers: - image: {{ .image }} name: {{ .name }}{{- end -}}●values.yamlnginx: replicas: "1" name: nginx image: docker.io/nginx:1.25.1httpd: replicas: "3" name: httpd image: docker.io/httpd:2.4.57●deployment-nginx.yami{{ include "deployment" .Values.nginx }}
GKEクラスタを作成しておく？kubectlでArgo adminとシークレット作成？brew install argocdArgo cd設定ファイルリポジトリのcloneargocd cluster add <context name>argocd repo add <repo url> --ssh-private-key-path ~/.ssh/id_rsaargocd-configuration に設定を追加argocd-insallation に設定を追加argo cd上からinstallationをsyncするargocd login --grpc-web --sso dev-argocd.dev.bb.com
＝＝＝ArgoはSettingsにリポジトリ、クラスター、プロジェクト、他にUserの設定 アプリ設定でhelmのパス等を指定（Argo内部でhelm upgradeでなくkubectrl applyに変換しでやってもらえるお作法：helmコマンドのインストール不要でArgoでhelm文法が使える）
総務省｜報道資料｜「クラウドの設定ミス対策ガイドブック」の公表 (soumu.go.jp)
Comment (0)
■23/10/31 10:57PM
GCP Network Connectivity
●共有 VPC
同組織のプロジェクトのホストプロジェクト(親)のVPCをサービスプロジェクト(子)に共有●VPC ネットワーク ピアリング
異なる組織間の接続（双方のVPCでコネクションを作成する、内部IPで通信する、サブネットは重複しないこと、2ホップ制限で1:1＝3つ以上の場合は古メッシュでコネクション作成要）、k8sサービスとPod ipをVPCピアリング経由する利用法もある
●ハイブリッド サブネット Cloud VPN/Interconnect等が必要、オンプレルータとCloud RouterをBGPでつなぐ、オンプレとGCPをつなぐ
●Cloud Interconnect
DCと専用線で閉域網接続、Cloud VPNより低レイテンシ/帯域安定●Cloud VPN オンプレとIPsec VPN接続、アドレス帯の重複だめ、Cloud VPN側でBGPIP設定やIKEキー生成をしオンプレルータ側でそれらを設定する
●内部範囲
VPCで使うIPをCIDRで定義しIP範囲の使用方法を事前に決定しておく、IPが勝手に使われたりしない等ができる
●限定公開の Google アクセス（Private Google Access）
外部IPを持たないGCE等はデフォルトのインターネットゲートウェイ0.0.0.0を経由してGoogle APIにアクセスする、VPC＞Routesで見れる
●オンプレミス ホスト用の限定公開の Google アクセス CloudVPNやInterconnectを経由してオンプレから内部IPを利用してGoogleAPIにアクセス、GCP側ではCloudDNSで特定のドメインのAレコードを入れる、選択したドメインのIPアドレス範囲を静的カスタムルートでVPC内のプライベートIPからルーティングできるように設定する、オンプレにはCloudRouterからドメインのIPアドレス範囲をBGPでルーティング広報する、VPNやInterconnectがないと0.0.0.0でGoogleAPIにアクセスするがこれだとRFC1918に準拠しない199.33.153.4/30などのIPを使う必要がありルーティングが複雑化したり、オンプレを通る場合があり通信は慎重に設計をすること●Private Service Connect 「限定公開の Google アクセス」の発展版、オンプレをNATでVPCに接続、内部IPでGoogleAPIにアクセスできる、PSCエンドポイントを介して内部IPで公開できる、NATされ内部IPの公開先での重複OK
●プライベート サービス アクセス
VPCペアリングを併用してサービスプロデューサをVPCに接続し内部IPで次のようなサービスに内部IPでアクセスできるようにする（Cloud VPNまたはInterconnectを付け足せばオンプレからも可）、Cloud SQL/AlloyDB for posgre/Memorystore for Redis/Memcached/Cloud build/Apigee等の限られたもの●サーバーレス VPC アクセス
サーバレスからVPC内リソースにアクセスするためのコネクタ（通常は外部IP通信になるがコレだと内部IPでVPCにルーティングされる、/28のサブネットを指定）、例えば既存のcloud runサービスを編集しても付けられず初期構築時のみ設定できる
●外部 IP アドレスを持つ VM から API にアクセスする
IPv6をVMに設定し限定公開DNSゾーン設定をすればトラフィックはGCP内にとどまりインターネットを通りません
●CDN Interconnect
Cloud CDNもあるが他社のCDNに接続する、Akamai/Cloud flare/fastly等々
●Network Connectivity Center
ハブとなりCloudVPN/InterconnectをメッシュしGCP/オンプレ含め通信させる、Googleのバックボーンでユーザ企業の拠点間を接続できる
●ダイレクト ピアリング
GoogleのエッジNWに直接ピアリング接続を確立し高スループット化、Google workspaceやGoogleAPI用だが普通は使わずInterconnectを使う●キャリア ピアリング
ダイレクトピアリングの高度な運用が自社対応できない等でサービスプロバイダ経由でGoogle workspaceなどのGoogleアプリに品質よくアクセスする
Google CloudのVPCを徹底解説！(応用編) - G-gen Tech Blog
●トンネル系の下記は色々権限が要りそうで候補
Compute OS login/IAP-secured tunnel user/Service account user/viewer/compute.instance*
■IAPトンネルexport http_proxy=http://localhost:3128export https_proxy=http://localhost:3128gcloud compute start-iap-tunnel --zone asia-northeast1-a gce-proxy001 3128 --local-host-port=localhost:3128 --project=gcp-proxy-prjでコマンドを打てばIAP踏み台トンネルを通って外部に通信できる
■踏み台コマンドgcloud compute ssh --projet gcp-prj-unco --zone asia-northeast1-a gce-step-svrでSSHログインしそこからcurl等で操作する
＝＝＝＝＝＝＝＝＝＝＝＝＝
なぜレッドオーシャン化する前にサービスを グロースできなかったのか？ - フリマアプリ編 - (フリル)サービスを急拡大させる意思決定が遅く競合に遅れ競合出現後も経営方針を大きく変えなかった勝利条件はユーザ数で機能差ではなかったパワープレーでいかにプロモーションばら撒いて認知広げて第一想起をとるかだった先行者優位で過ごせる期間は短いスタープレイヤーの採用、手数料無料化、TVCM等PLを超えた手法があった、BS経営すべきだった成長のキャップが創業者の能力になっていた有能な人材：耳の痛いことを言ってくれる人材を経営チームに採用しても良かったCTOが開発をし、組織運営の雑務をし、採用もやっていたCEOは机の組み立てをするな。CTOはPCの購入をするな役割の変化に素早く適用し権限移譲を行い、やるべきことをやれる状況を作るあるいは必要な組織を大きくすることに注力する、例えば開発組織を大きくする戦時のCEO、皆に戦時であることを伝える、企業文化に背く意思決定も行う研究や教育等、やった方が良さそうな耳障りの良いタスクも拒否するどうやったら市場で勝てるかの戦略↓
IPOとか目指さなければConfort zoneを見つけてじっくりまったりビジネスを継続させる手もある
メルカリやPay2をみた結果論、このやり方も古いというかアレ
視力回復の音
(16) HOKKORI 📽💫🐈🐢 on X: "視力回復してください❤️🩹😹 https://t.co/Zug4pEbvys" / X (twitter.com)
Comment (0)
■23/2/11 1:46AM
HSTS/CORS/CSPOAuth/OpenID/SAML/XSS/CSRF/JSOP/SSO/SSL/SVG/JWT
=========================
2023-02-11
フロントエンド開発のためのセキュリティ入門 - Speaker Deck
HTTPとHTTPSが混ざっているwebサイトはHSTS(http strict transport securityヘッダ)でHTTPS強制できる JSのfetch,xhr/iframe/canvas/WebStorage,IndexedDBでクロスオリジンは危険 Access-Control-Allow-OriginレスポンスヘッダでCORS(cross origin resource sharing)許可を判定できる CSP(Content-Security-Policy）レスポンスヘッダあるはmetaタグで許可するJSを判定できる
SVG
ChatGPTにSVGでお絵描きさせる｜temoki / Tomoki Kobayashi (note.com)
タグで図が書ける
JWT (JSON WEB TOKEN?)
JWTセキュリティ入門 - Speaker Deck
=========================
2022-04-06
SAML SSOのログイン状態を保持する認証プロバイダー(IdP)を使い各アプリ(ServiceProvider)でSSOを実現する SSOの仕組みにはエージェント方式、リバースプロキシ方式、代理認証方式など ユーザはWebサービスにアクセス WebサービスからSSO認証プロバイダーサーバにSAML認証要求をPostする SSO認証プロバイダーサーバでSAML認証を解析、ユーザに認証を転送 ユーザはそれでWebサービスにログインする
SAMLはログイン時にユーザー情報をチェック、OAuthはユーザーの情報を登録OAuthはアプリケーションを連動させるAPIで有効なアクセストークンかを見る アクセストークンには「いつ」「どこで」「なんのために」作られたのか分からないOpenIDはIDトークンを使い「いつ」「どこで」「なんのために」作られたのか分かる
OAuth 2.0、OpenID Connect、SAMLを比較OAuth 2.0：新しいアプリケーションに登録して、新しい連絡先をFacebookや携帯電話の連絡先から自動的に取得することに同意した場合は、おそらくOAuth 2.0が使われています。この標準は、安全な委任アクセスを提供します。つまり、ユーザーが認証情報を共有しなくても、アプリケーションがユーザーに代わってアクションを起こしたり、サーバーからリソースにアクセスしたりすることができます。これは、アイデンティティプロバイダー（IdP）がユーザーの承認を得て、サードパーティのアプリケーションにトークンを発行できるようにすることで実現されます。
OpenID Connect：Googleを使ってYouTubeなどのアプリケーションにサインインしたり、Facebookを使ってオンラインショッピングのカートにログインしたりする場合に使用されるのが、この認証オプションです。OpenID Connectは、組織がユーザーを認証するために使用するオープンスタンダードです。IdPはこれを利用して、ユーザーがIdPにサインインした後、他のWebサイトやアプリにアクセスする際に、ログインしたりサインイン情報を共有したりする必要がないようにします。
SAML：SAML認証は、多くの場合に仕事環境で使用されます。たとえば、企業のイントラネットやIdPにログインした後、Salesforce、Box、Workdayなどの多数の追加サービスに、認証情報を再入力せずにアクセスできるようになります。SAMLは、IdPとサービスプロバイダーの間で認証・認可データを交換するためのXMLベースの標準で、ユーザーのアイデンティティとアクセス許可を検証し、サービスへのアクセスの許可/拒否を決定します。OAuth、OpenID Connect、SAMLの違いとは？ | Okta
Oath: idpがトークンを発行、Webサイト間でユーザを認識し3rdからでも個人情報を使えるようになるOpenID(OIDC): idpとJWT(トークン)で認証するOauth系のSSO、Oauthの拡張でログインが3rdからもできるようになるSAML: idpで各アプリやAD間をXMLメッセージにより認証管理しSSOを実現 OpenIDとSAMLが同じような機能 SAMLはユーザ固有の傾向で大企業SSOが多い、OpenIDはアプリ固有の傾向でWebサイトやモバイルアプリが多い SAMLよりOIDCの方が新しくSPAやスマホと親和性が高い SaaSとしてOpenIDはOktaのidp、SAMLはPingFederateのidpがメジャー
=========================
2016-01-03
■XSS対策、CSRF対策、脆弱性チェック
情報処理推進機構にチェックリスト有
https://www.ipa.go.jp/security/vuln/websecurity.htmlXSS対策
フォーム送信後の確認画面ではHTMLエスケープ等でサニタイズされた内容の結果を表示
DBへのクエリについてはプレースホルダやエスケープ等でSQLインジェクションを防ぐ
target="_blank"はXSSになるので危ない、rel="noopener noreferrer"を付ける
https://b.hatena.ne.jp/entry/s/webtan.impress.co.jp/e/2020/03/13/35510
https://laboradian.com/test-window-opener/
CSRF対策
前ページでhidden値を入れる
他
クッキーに具体的なものは入れない、CookieにHttpOnly属性、HTTPS通信ではsecure属性
エラーメッセージを表示しない
不要なファイルは削除
XMLの外部実態参照は禁止、サーバ上でコードが実行される
→libxml_disable_entity_loader(true)で止める、xmlをアップロードさせない/使用しない、JSON使う
PDFからHTTPリクエストが発行される
→PDFをアップロードさせない
------
//SQLインジェクション対策
\ " ' を\エスケープ
$sql = "UPDATE users SET name='.mysql_real_escape_string($name).'WHERE id='.mysql_real_escape_string ($id).'";
//クロスサイトスクリプティング対策
表示時には<>&"をメタ文字へ変換
echo htmlspecialchars($_GET['username'], ENT_QUOTES);
$ent = htmlentities($ent, ENT_QUOTES, "UTF-8"); //100個の文字を変換
//クロスサイトスクリプティング対策
別サイトからのポストを弾く
refferを送信しないリクエストもある（別サイトのリファラを弾き、nullもしくは適切ページからを許可する）
セッションIDで判断する
//DOS対策
2重ポスト
IPと日付で2重ポストを防ぐ（同IPのポストがx秒以内を弾く）
========
■JSONP
scriptタグを使用してクロスドメインなデータを取得する仕組みのことである。
HTMLのscriptタグ、JavaScript（関数）、JSONを組み合わせて実現される
GoogleAnalyticsのクッキーは1stパーティでサイト側がオーナでありGoogleがオーナーではない
サイト側のJSでクッキーが作成されるようなっている
クッキーが送信される相手はどこか？が重要でGoogleでなくサイト側に送信される
アクセス履歴は別途データをGoogleに送信しており、クッキーはセッション管理に使用される
■SSO
色々な方法がある、SAMLや、サイトにエージェントを組み込み＋SSO認証サーバ等
ロジックを確認しないと詳しくは分からない
=========
■SSL【図解】よく分かるデジタル証明書(SSL証明書)の仕組み 〜https通信フロー,発行手順,CSR,自己署名(オレオレ)証明書,ルート証明書,中間証明書の必要性や扱いについて〜 | SEの道標 (nesuke.com)デジタル証明書の仕組み (infraexpert.com)
認証局とは | GMOグローバルサインカレッジ (globalsign.com)
サーバでRSA秘密鍵とCSRを生成し公開鍵を認証局(CA)登録CAはサーバに証明書(署名)を発行＝＝＝＝クライアントが接続要求サーバが証明書(署名とRSA公開鍵を含む)を送るクライアントが証明書を検証(
どっち？
１）署名をルート証明書のチェーン(RSA公開鍵)で複合化しドメインを確認
該当のルート証明書(RSA公開鍵)がブラウザにないと該当CAに要求？
CRLやOCSPで失効について問合せができるようだがRSA公開鍵の要求は出来なさそう （ルート証明書はブラウザにある結局オレオレ証明書に違いない：厳密な審査の上で組込まれている）
２）クライアントが公開鍵をサーバに送りRSA秘密鍵で暗号化し送り返すとクライアントが複合化してRSA秘密鍵が正しい事を確認
)クライアントが共通鍵（セッションキー）を生成し公開鍵で暗号化し送るサーバが秘密鍵で共通鍵を複合
以降共通鍵暗号で通信 ※ホンマか？？
＝＝＝＝
ホスト（ドメイン）を持って接続要求をし、暗号化通信後にパスやクエリパラメータを送るので、詳細は暗号化され守られている
Comment (0)
Navi: 1 | 2 | 3 | 4 >
-Home
-Column [126]
-Europe [9]
-Gadget [76]
-Web [123]
-Bike [4]
@/// BANGBOO BLOG ///