生涯未熟

生涯未熟

プログラミングをちょこちょこと。

【PostCSS】ts⇔css間で値を共有する

プロジェクトの依存ライブラリをアップデートする苦行をやっているのですが、その最中で遭遇し解決した事象の話をば。
PostCSSを使っているのですが、その中で postcss-custom-media をv8からv10に上げた時にそれは起きました。

まず、以下のようなPostCSS設定ファイルがあり、

これがv8 -> v9でのbreaking changesにて importFrom が削除されたので、修正する必要がありました。
これについては、以下の内容を参考に postcss-global-data を使う形で解決しました。

github.com

各ComponentにCSSファイルが配置されていて、そこで @custom-media を利用しているのですが、 postcss-global-data を使って別途作成した media-queries.css を読み込ませて解決。
しかしここでふと気付いたわけです。「tsと共有している 100px をどうしよう・・・」と。

tsからはこのような形で呼び出していたのです。困った・・・

この問題を解決するためにいろいろ試しました。
最初に postcss-css-variables を使って media-queries.css に設定している @custom-media で指定しているピクセル数をcss variablesに置き換えていけるかな？と思ったらmedia queryでcss variablesが使えないことでダメでした。（知らなかった・・・）

次に、 postcss-extract で atrule として custom-media を抜き出してexportしたものをts側で利用しようとしたけどなんかダメだった。
どういう風にダメだったかというと atrule[name="custom-media"] といった形式で抜き出そうとしたものの、取得結果を見ると空となってしまいどうしてもここを解決することができませんでした🤔

で、最後に試したのが postcss-design-tokens で、これが見事に刺さりました。これを使ってCSS内でデザイントークンを利用すればcss variablesではないのでいけないか？と思い、使ってみた経緯です。
利用例としては以下のような感じ。

これで具合が良かったのはts側からは design-tokens.json を読み込むだけでOKなのでめっちゃ楽ってとこでしたね。で、 @custom-media も @media で使う際にcss variablesで怒れることがなく、万事解決しました！

まとめ

蓋を開けてみればPlugin知ってるか知らないかの話だったんですが、PostCSSのPlugin多すぎ問題があるのでなかなか難しいところではあります。
あとはmedia queryでcss variables使えないのは純粋に知らなかったので、これは大反省です・・・

chaika.hatenablog.com

この記事見かけてなかったら一生彷徨ってたかもしれないので感謝🙏

GKEアップグレードの時にいつもやっていること

GKE使っていると定期的にアップグレードの圧がやってきますね。
エイヤッと不用意にクラスタのアップグレードを行うと、deprecatedとなるapiVersionを使ってしまい最悪サービスが不通になる可能性もあります。

本記事ではアップグレード時にいつもやっていることをまとめていますが、暫定のものになるので変遷とともに各々改善していってください。

やっていること

まずは上げたいバージョンにアップグレードしても大丈夫かを調査するところから開始します。 確認することは以下の２つ。

  • 上げるバージョンに対して非推奨APIを使っていないかを確認
  • k8s Change Logを確認

上げるバージョンに対して非推奨APIを使っていないかを確認

Cloud Loggingを使うことで対象バージョンでの非推奨APIを使っていないかどうかをチェックすることができます。 以下のクエリを実行して非推奨APIを使っていないかを確認してみましょう。

resource.type="k8s_cluster"
labels."k8s.io/removed-release"="[上げるバージョンを指定]"
protoPayload.authenticationInfo.principalEmail:("system:serviceaccount" OR "@")
protoPayload.authenticationInfo.principalEmail!~("system:serviceaccount:kube-system:")

[上げるバージョンを指定] は対象が仮に1.26であれば1.26とそのまま入れてください。

もし非推奨APIが存在する場合はGKEのドキュメント内にアップグレードガイドがあると思うので、そちらを参考に対応を進めるのが良いです。

cloud.google.com

k8s Change Logを確認

基本的には非推奨APIの指定だけで問題ないと思いますが、念の為k8sのChange Logにも目を通し、 Upgrade Notes などアップグレードに関する情報を読むことをオススメします。

k8s Change Log：https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/README.md

以上が、私がGKEのアップグレード時にやっていることになります。最近ではコンソール上でも非推奨APIを使っていないか？などを出してくれるのですが、上記のようなやり方もありますよというご紹介でした。

メモリ使用率によってk8sのPodをevictさせる君を作った

サービスを運用している中で緩やかにメモリ使用率が上がっていく問題があり、それが解決されるまで一時的になんとかするために掲題のを作りました。

github.com

中身自体はZapierが作っていたpreoomkiller-controllerが元になっております。

github.com

このコントローラーを導入すれば済む話じゃない？ってなりそうですが、こちらは「メモリ使用量」を閾値としており、更に更新も止まっていたのでせっかくなら勉強がてら作り直すかーとなった結果こうなりました。

この手のk8sに関するツールを今まで全く作ったことがなかったので、勉強に以下の本を読ませていただきました。

実践入門 Kubernetesカスタムコントローラーへの道 技術の泉シリーズ (技術の泉シリーズ（NextPublishing）)

実践入門 Kubernetesカスタムコントローラーへの道 技術の泉シリーズ (技術の泉シリーズ（NextPublishing）)

Amazon

preoomkiller-controllerでclient-goを使っていたこともあり、かなり勉強になりました！

で、この本とpreoomkiller-controllerを読んでちょろちょろ書き直した結果、以下のように修正しました。

  • メモリ使用量からメモリ使用率の閾値に変更
  • Go1.13からGo1.20に対応
  • helm installでインストール出来るようにした
  • その他、動かなくなっていたところをチマチマ修正

他にも色々直したいところはあるんですが、そこは追々手を入れていこうかなと思ってます。

もし、要望やアイデアがあれば大歓迎なので是非issueにおねがいします🙏

Cloud ArmorのOWASPルールセットによるGraphQLリクエストでの誤検出

たまたま遭遇したけど誤検出のあるあるっぽいなと思ったので調べてメモしとく。

前提としてCloud Armorの事前構成 WAF ルールであるOWASP TOP 10のルールを有効化して運用しておりました。

cloud.google.com

運用自体は特に問題なかったのですが、ある日GraphQLの機能実装をしていたメンバーから特定のリクエストが403で弾かれますと報告を受け調べることに。

Cloud Armorのログを確認する

Cloud Loggingで jsonPayload.enforcedSecurityPolicy.outcome="DENY" なログを調べたところ、特定のルールが原因で弾かれていました。

それが、 lfi-v33-stable の owasp-crs-v030301-id930120-lfi で弾かれていて、どうやら .profile がヒットしている様子。
たしかに、特定のリクエストにはfragmentとして profile といった文字列を含んでいて、それがルールに抵触して弾かれているようなのですが正直何で？といったお気持ちになったので少し調べてみることに。

ルールを確認してみよう

Cloud ArmorのOWASP TOP 10のルールはこのリポジトリで管理されているコアルールセットを元に構成されています。

github.com

で、今回引っかかっていたのはこの OS File Access に関するルールでした。

github.com

#
# -=[ OS File Access ]=-
#
# Ref: https://github.com/lightos/Panoptic/blob/master/cases.xml
#
SecRule REQUEST_COOKIES|!REQUEST_COOKIES:/__utm/|REQUEST_COOKIES_NAMES|ARGS_NAMES|ARGS|XML:/* "@pmFromFile lfi-os-files.data" \
    "id:930120,\
    phase:2,\
    block,\
    capture,\
    t:none,t:utf8toUnicode,t:urlDecodeUni,t:normalizePathWin,t:lowercase,\
    msg:'OS File Access Attempt',\
    logdata:'Matched Data: %{TX.0} found within %{MATCHED_VAR_NAME}: %{MATCHED_VAR}',\
    tag:'application-multi',\
    tag:'language-multi',\
    tag:'platform-multi',\
    tag:'attack-lfi',\
    tag:'paranoia-level/1',\
    tag:'OWASP_CRS',\
    tag:'capec/1000/255/153/126',\
    tag:'PCI/6.5.4',\
    ver:'OWASP_CRS/3.3.1',\
    severity:'CRITICAL',\
    setvar:'tx.lfi_score=+%{tx.critical_anomaly_score}',\
    setvar:'tx.anomaly_score_pl1=+%{tx.critical_anomaly_score}'"

たしかに、 owasp-crs-v030301-id930120-lfi で検索をかけるとOSファイルアクセス試行とあったので間違ってなさそうですね。
ここで参照している lfi-os-files.data を見てみると・・・ .profile がありました！間違いなくここですね。

github.com

こりゃめちゃくちゃ引っ掛かりそうだなーと思いながら調べていると、別のリポジトリでこの .profile を含めていることに憤っている方もいました。

github.com

対応として合致パターンを ^.profile とかにすればいいと思うとのこと。しかし、Cloud Armorで用意されているルールに手を加えることも出来んし困るなー・・・

困ってる人多そうとか思ったが、調べた限りあまりいなかったのでモヤモヤしつつも OS File Access のルールをオプトアウトルールにする対応を取りましたというお話でした。

隔週で動くGitHub Actionsを作ろう

必要に迫られて掲題のように「第２・４週の水曜日に動く」GitHub Actionsを作らなくてはいかん状況になったものの、ちと手間だったのでメモ。

GitHub Actionsにはschedule triggerがあり、cron式を書くことによって定期的に動作するActionは作成できます。

ただ、これだと毎週水曜日に動くのでここから隔週にしたいです。
しかしながら、schedule triggerだと隔週にするような方法がないため、steps内で第２・４週かどうかをチェックしていきましょう。

こんな感じになりますかね。もしかしたら同じことを実現するworkflowがMarketplaceにあったりするかもしれないけども動いてるのでヨシ！