kasei_sanのブログ

かせいさんのIT系のおぼえがきです。胡乱の方はnoteとtwitterへ

Red Hat系Linuxディストリビューションの歴史とCentOS Streamについて調べた

Linux

f:id:kasei_san:20201210081549j:plain

2020年LCLアドベントカレンダーの10日目です!

qiita.com

経緯

2020/12/08 に CentOS から「今後は CentOS Stream に開発リソースを集中し、CentOS 8 のEOLを2021年末とする」という発表がありました

news.mynavi.jp

twitterなどではいろいろな意見が出ていたのですが、私がそもそも RedHat系Linuxディストリビューションがこれまでどのように開発されていたのかキチンと把握していなかったので CentOS Stream と一緒に調べてみることにしました

そもそものはじまり Red Hat Linux

Red Hat Linux は 1995年にRed Hat社から配布されました。当時は企業がサポートするLinuxディストリビューションの草分け的存在だったそうです。また、サポートが限定された無償版も配布されていました

特徴は、パッケージ管理システムに RPM (RPM Package Manager) を使用していることです。RPM はもともとは Red Hat Package Managerという名前で、Red Hat社が開発したものでした

RPMは、Red Hat 系以外のディストリビューション (SUSE Linux や Vine Linux) にも採用されており、それらをまとめて、 RPM系ディストリビューション と呼ぶこともあるそうです

エンタープライズ専門の Red Hat Enterprise Linux(RHEL) と コミュニティ主導の Fedora

2003年、Red Hat社は Red Hat Linux の開発を中止し、今後はエンタープライズ専門の Red Hat Enterprise Linux を開発すると発表しました (当時、Red Hat Linux はマイナーアップデートでもカーネルやライブラリの互換性が失なわれるなど、商用利用には少々難があったそうです。そのための方針転換のようですね)

その際、無償版 Red Hat Linux は Red Hat社が支援するコミュニティ Fedora Project が提供するLinuxディストリビューション。 Fedora に引き継がれました

Fedoraが最新の技術を積極的に取り込み、その成果が RHEL に反映される という流れがここから生まれました

Fedora と RHELのリリースサイクルと保守期間

余談ですが、Fedora と RHEL のバージョンは直接対応していません

Fedoraは、半年に一度メジャーバージョンがupされ、おおよそ13ヶ月そのパッケージが保守されます

fedoraproject.org

RHELは、RHEL 8 以降、メジャーバージョンを3年毎にupし、マイナーバージョンを半年毎にupします

また、メジャーバージョンは5年間サポートされ、その後も5年間はメンテナンスサポート(新機能の追加が無い更新)されます。さらに、その後任意の数年間「延長ライフサポート」が行われます

サポートが長いのが、RHELのウリです

access.redhat.com

RHELの無償版クローン(と認識されている) CentOS

RHELはエンタープライズ向けのOSとなりましたが、ソースコード自体はOSSのため公開されていました。そこから 商標や商用パッケージを除いてビルドしたものが CentOS です

CentOS 自体はRed Hat社とは関係ないコミュニティ主導のプロジェクトでしたが、2014年にRed Hat社が支援を表明。CentOSのコアメンバーがRed Hat社に入社したそうです

CentOS は RHELの無償版クローンと認識されていますが、公式は「CentOS Linux is NOT a clone of Red Hat® Enterprise Linux」と否定しており、CentOSの独自機能repositoryもあります。ただし、RHEL由来のコードは変更されないようにしているらしいです

そういった経緯があるため、CentOS を使っていて Fedora や RHEL 由来の不具合があった場合、上流プロジェクトでの修正を待つ必要であります。そのため、CentOSには、 変更の反映が遅い という欠点があります。そして、これが CentOS Stream 誕生の伏線となります...

Fedora と RHEL の橋渡しをする CentOS Stream

ついに CentOS Stream です。2019年に CentOS Stream 8 が発表されました

wiki.centos.org

CentOS Stream は、これまでの RHEL のクローンではなく、RHELの開発サイクルに組み込まれ、 Fedora の内容を RHEL に組み込む前段階 としての役割を持っています

つまり、これまでは Fedora -> RHEL -> CentOS という流れだったものが、 Fedora -> CentOS Stream -> RHEL という流れになります

今後は、RHELのマイナーリリースは、CentOS Stream を噛ませて、OSSコミュニティの開発者やユーザの意見を取り入れて行われるとのことです

なお、CentOS Stream は開発者用プラットフォームという位置づけのため、本番環境での利用する性質のものではありません

そもそも CentOS の時点でも商用利用でしたら RHEL を使ったほうが良いとは思いますが...セキュリティアップデートとかもRHELの後になりますし...

CentOS Stream のメリット

開発方法の変更により、CentOSと比べて、以下のようなメリットが生まれました

Fedora由来の不具合やセキュリティfixの高速化

今までは、RHELの修正を待つ必要がありましたが、それを待つ必要がなくなりました

OSSのコミュニティがRHELのマイナーリリースに貢献できるようになった

これまでは、OSSコミュニティが CentOS の RHELのコードベース部分に手を入れたい場合は、Fedora を介する必要がありました。(そのための Fedora ELNというプロジェクトがあるそうです)

t.co

ただし、RHEL が Fedora のコードベースを持ってくるのは、メジャーバージョンアップの時だけなので、RHELのマイナーバージョンアップにOSSコミュニティが介入する方法はありませんでした

しかし、今後は RHEL のマイナーバージョンアップの前に CentOS Stream を介するため、このタイミングでOSSコミュニティが、RHELのマイナーバージョンアップに対して、PRや意見を出すことができるようになりました

これにより、RHELのマイナーバージョンアップに対して、意見が出せるようになったのですが、反面、RHELのベータテストをCentOSユーザにやらせるのか という意見も上がっているようです

👇 こちらのコメント欄で意見が色々出ています

t.co

Red Hat社のQAでは「CentOS Streamの方がRHELよりも先に変更が行われるため、RHELよりバグは少なく、機能は多い」と回答しています

👇 こちらの 「Q5: Does this mean that CentOS Stream is the RHEL BETA test platform now?」

t.co

CentOS と CentOS Stream の今後

CentOSは、 CentOS Stream に開発を注力するため、以下のようにするとのことです

  • CentOS 9: リリースしない。CentOS Stream 9 がリリースされる
  • CentOS 8: 2021年末でEOL。CentOS Stream 8 への移行を推奨
  • CentOS 7: 以前からの予定通り、2024/6末でEOL

まとめ

「無償版RHEL」という認識で、CentOS を本番環境で使用していたユーザからは大きく不安の声が出ているようですね...

私も前社のオンプレ環境で使用していました。ちょっとしたオンプレのプロジェクトや社内サーバはRHELではなく、CentOSという方も多いのでは無いでしょうか

このあたりが今後どこに移行されていくか注目ですね

おまけ

CentOSを本番環境で使う是非が議論されているフォーラム

(やはりセキュリティとサポートの有無について議論されていました)

forums.centos.org

「CentOSは死んだ」というやや過激な記事。こちらではCentOSの代替が議論されていました

  • Oracle Linux (こちらも RHELベースなんですね) や Ubuntu LTS という意見が出ていました

lwn.net

2020/12/16 追記

👇 Fedora、CentOS Stream、RHEL のデリバリーの流れについて分かりやすく説明してくれています

rheb.hatenablog.com

👇 CentOSのプロジェクトの創始者がCentOS代替プロジェクト、Rocky Linuxを立ち上げ

japan.zdnet.com

👇 RHELのソリューションアーキテクトの人のツイート「そもそもCentOSだって定期的にupdateしないといけないし、安定した問題がない状態なんて幻想」というお話

OpenSSLのリリースストラテジを調べた

OpenSSL

OpenSSLの最新バージョンはいくつ? 今サポートされているバージョンはどれ? いつまで? とかわからなかったのでまとめる

先に結論

2020/12/10 現在

  • 最新版: OpenSSL 1.1.1 (LTS)
  • サポートされているバージョン
    • 1.1.1 〜 2023/09/11
    • 1.0.2 サポート切れだが、セキュリティfix については有料サポートで対応
    • それ以外はサポート終了

リリースストラテジについて

詳しくは公式を読んでください

www.openssl.org

  • 最新は1.1.1(LTS)。次のリリース予定は3.0.0
  • 3.0.0 から、セマンティックバージョニング になる予定(MAJOR.MINOR.PATCH )
  • LTS(Long Term Support)は、最低5年サポート、4年に1回LTSが指定される
  • 通常バージョンは、最低2年サポート
  • サポート終了年は、セキュリティfixのみ提供
  • プレミアムサポート を受けることで、EOLになった最後のTLSのセキュリティfixを受けることができる

root権限を持たないユーザで 80番ポートを開放しようとすると怒られる理由

docker linux

Dockerfileをベストプラクティスに沿って作るとそうなりがち

docs.docker.com

理由

0〜1023 までのポートは well known port と呼ばれ、開放にroot権限が必要なため

そういう場合に8080を選ぶ理由

8080は、非rootユーザがwebサーバを立てる時の使うポートと、IANAで定義されているため

www.iana.org

ローカルでAWS Lambda ランタイムと(ほぼ)同様の環境でserverlessを動作確認する方法

docker serverless AWS lambda

先に結論

--docker オプションを使う

serverless invoke local --docker --function hoge

解説

--docker オプションを使うと、AWS lambda が公式に配信しているDocker でシミュレートされた Lambda 環境 ( lambci/lambda ) をつかって、serverlessをローカルで実行してくれる

オプションの解説

www.serverless.com

lambci/lambda の解説

aws.amazon.com

この lambci/lambda イメージは Lambda 環境の完全なコピーではなく、一部のファイルが欠落している可能性があることにご注意ください。

lambci/lambda の docker hub

hub.docker.com

cookieのSameSite属性 おぼえがき

cookie ブラウザ

f:id:kasei_san:20201029124833p:plain
same

経緯

cookieにはSameSiteという属性があって、これがChrome80からデフォルトの扱いが変わった

  • 正確には変わる予定だったが、コロナの影響で変更は先延ばしにされて、2020/07/14 のChrome84から変更されるようになった。なお、83, 81, 80 にも適時適用されたらしいです(なお、82は欠番)

何が変わったの?

SameSite属性が未指定の場合のデフォルト値が、None から、Lax に変更になった

そもそも、SameSite属性ってどういう属性なの?

ドメインAでset-cookieされた時に、ドメインBからドメインAにアクセスした時に、リクエストヘッダにそのcookieを入れるかどうかを決める属性

どういう振る舞いがあるの?

Strict、Lax、Noneの3つの値がある

  • Strict: いかなる場合もcookieをリクエストに含めない
  • Lax: POST、画像読み込み、XHR、iframeでのリクエストは、cookieをリクエストに含めない。通常のGETならば含める
  • None: すべてのリクエストに含める。ただし、Chrome80からはSecure属性も必須

Secure属性って?

HTTPSの場合のみcookieの送信を許可するという設定

これは、通信経路上で、cookieを盗み見 & 書き換えが行われないための施策らしいです

なんでデフォルト値が、None から、Lax に変更になったの?

CSRF対策

CSRFってなんだっけ?

CSRF (クロスサイト・リクエスト・フォージェリ)。異なるドメインから偽装リンク等を通じて、ユーザに意図としない動作をさせる攻撃手法

インターネット古老勢だと知っているぼくはまちちゃん攻撃が有名

www.atmarkit.co.jp

mixiにPOSTするURLを偽装して掲示板などに貼る -> mixiにログインしているユーザがそのURLを踏むと、POSTが行われて、意図しない書き込みが行われる。という攻撃

で、SameSite属性のデフォルトをLaxに変えることで、他ドメインからのPOSTを規制して、CSRF攻撃を潰すのが今回のアップデートの目的(らしいです)

他のブラウザの動向はどうなの?

Firefox

検討中

bugzilla.mozilla.org

safari

2020 年 3 月に 3rd Party Cookie (ドメインをまたぐcookieのリクエスト)を完全にブロックするとアナウンス

webkit.org

SameSite属性をNoneにした場合は、設定によって挙動が変わるらしい

blog.cybozu.io

safari: MacOS 10.14とiOS 12の SameSiteバグ

SameSite=Noneを誤って、SameSite=Strictとするバグがあるので注意

t.co

これのために、Chrome80移行対応で SameSite=None に変更したい場合、サーバなりの設定でUAを見てiOSかMacOSの特定のバージョンの場合「 SameSite=None を設定しない」という処理を入れる必要がある

まだ、MacOS 10.14とiOS 12のユーザはそこそこいるはずなので...

古いブラウザでは SameSite=None が実装されていない

古いChromeやAndroidのUC Browserの古いバージョンでも、 SameSite=None が実装されていないため、正しく動かないという問題もある

これもiOSやMacOSのように、UAを見て SameSite=None を入れない。という方法を取る必要がある

この辺の対応をしないと困ることって何?

自前でコンバージョントラッキングをしていて、お客様のコンバージョンページにcookieトラッキングするようなタグを埋め込んでるサイトだと、 SameSite=None にしないと挙動しなくなる

トラッキング関係以外だとなにかあるのかな...?

TLSおぼえがき

セキュリティ AWS

TLSってなに?

Transport Layer Security（トランスポート・レイヤー・セキュリティ、TLS）は、インターネットなどのコンピュータネットワークにおいてセキュリティを要求される通信を行うためのプロトコルである。主な機能として、通信相手の認証、通信内容の暗号化、改竄の検出を提供する

Transport Layer Security - Wikipedia

SSLとどう違うの?

以前はSSLと呼ばれていた。SSL3.0の後に、TLS1.0と名前が変わった

  • SSL3.0は、使用上の脆弱性(POODLE) が発見されてTLS1.0への移行が推奨。2015/06 には、RFC 7568 で使用が禁止されている

HTTPSとどう違うの?

HTTPをTLSで通信をセキュアにしたものがHTTPS

  • HTTP+TLS=HTTPS

TLSは複数のバージョンがあるみたいだけど?

2020/10/12 現在、TLS 1.0/1.1/1.2/1.3 がある。サーバもブラウザも複数のバージョンのTLSを取り扱うことができる

サーバ管理しているのだけど、どのバージョンまで許可すればよいの?

TLS1.0/1.1は無効化して、TLS 1.2/1.3のみを許可するのが良さそう

TLS1.0/1.1 は、暗号鍵の長さなどによって通信内容が漏洩するなどの脆弱性があり、主要ブラウザはすでにTLS1.0/1.1を無効化している

www.cybertrust.co.jp

IPAもTLS1.0/1.1 を「非推奨」としている

www.claris.com

だけど、それなりに古いブラウザのユーザはいるので、その辺はどれくらい売上に影響があるかと、リスクのバランスを取って決めたら良いのかな...? って思ってる(できる限り対応すべきではあるけど

他の会社はどうしてるの? ビジネス側を説得するのに知りたい

楽天やYahoo! は2018年にTLS1.0/1.1をすでに無効化している

個人情報扱ってないから問題ないかな?

通信内容が漏洩すると「中間者攻撃」のリスクもあるので、できるだけ対応した方が良いと思っている

中間者攻撃?

サーバとブラウザの間で通信を読み取って、改ざんしたり、情報を詐取する攻撃のこと

実際にTSL1.2以前のバージョンにおいて、中間者攻撃が可能な脆弱性が発見されている

www.security-next.com

AWSのELBで TLS1.0/1.1 を無効化するにはどうしたらよいの?

リスナーの SSL Policy を ELBSecurityPolicy-TLS-1-2-Ext-2018-06 にすれば、TLS 1.2 以上のみ許可するようになる

デフォルトの ELBSecurityPolicy-2016-08 は TLS 1.0/1.1 も許可するので注意

docs.aws.amazon.com

Terraform でランダムなパスワードを設定する方法

Terraform AWS

方法

モジュール random_password を使う

ほぼ同じ random_string もある。 random_password は生成結果を標準出力に出さないため、 random_string よりセキュア

使い方

resource "random_password" "master_password" {
  length  = 10
  special = false
}

パラメータ

  • length: 文字列長

他はオプション

よく使うのは、 special (!@#$%&*()-_=+[]{}<>:? の使用可否 ) くらいか (大体 false にする )

使いみち

AWS Systems Manager パラメータストアをterraformで定義したいけど、パスワードの値はterraformに持たせたくないので、仮のパスワードをひとまず入れておきたい場合などに使う

resource "random_password" "db_password" {
  length  = 10
  special = false
}

resource "aws_ssm_parameter" "db_password" {
  name = "/hoge/db/passowrd"
  type = "SecureString"
  value = random_password.db_password.result

  lifecycle {
    ignore_changes = [value]
  }
}
  • lifecycle ignore_changes = [value] を設定することで、terraform上では、value は上書きされなくなる
  • terraform apply 実行後、管理コンソールなどから本当のパスワードを手入力する