Kubernetes の SYS_TIME ケーパビリティとは？— コンテナで時刻を変更する影響とリスク
コンテナの中で date --set コマンドを実行しようとして、「権限がありません」と怒られたことはありませんか？ それ、SYS_TIME というケーパビリティが関係しているかもしれません。
Kubernetes で SYS_TIME を付与すると、コンテナ内でシステムの時刻を変更できるようになります。でも、それって本当に安全？ 今回は SYS_TIME の仕組みとリスク、そして適用時の注意点について見ていきましょう。
1. そもそもコンテナの時刻はどう管理されているのか？
通常、コンテナ内では date --set のような システム時刻の変更 コマンドが使えません。それは、コンテナがホストのカーネルを共有している ためです。
コンテナのシステム時刻はホストと共有している
Docker や Kubernetes のコンテナは、独立した仮想マシンではなく、ホストの Linux カーネルを共有する軽量なプロセス です。そのため、コンテナ内で date --set などを実行すると ホストの時刻も変更されてしまう 可能性があります。
通常の Linux では、システムの時刻を変更できるのは root ユーザーだけですが、コンテナの場合は root ユーザーであってもデフォルトでは SYS_TIME ケーパビリティが削除されている ため、date --set は失敗します。
2. なぜ SYS_TIME はデフォルトで削除されているのか？
セキュリティやシステムの安定性を考えると、時刻変更がコンテナで制限されているのは合理的です。
(1) セキュリティリスク
もし悪意のあるコンテナが SYS_TIME ケーパビリティを持っていたら、ホストの時刻を勝手に変更して攻撃できる可能性があります。
ログの改ざん:
→ 攻撃者がホストの時刻を変更することで、ログのタイムスタンプを操作し、痕跡を隠す ことが可能。証明書の有効期限の問題:
→ ホストの時刻を変更すると、TLS 証明書の有効期限が狂い、通信が失敗する 可能性がある。
(2) システムの整合性
多くのシステムは 正しい時刻に依存 しています。
時刻同期 (NTP) の破壊:
→ ntpd や chronyd などの時刻同期プロセスと干渉し、他のアプリケーションの挙動に影響 を与える。分散システムの問題:
→ Kubernetes クラスターや AWS などの分散環境では、各ノードの時刻がずれてしまうと 正しく動作しなくなる ことがある。
3. SYS_TIME を付与するとどうなるのか？
Kubernetes の Pod に以下の設定を追加すると、
securityContext:
capabilities:
add: ["SYS_TIME"]
そのコンテナ内のプロセスが時刻を変更できるようになります。例えば、通常 root 権限が必要な以下のコマンドも、一般ユーザーで実行可能になります。
date --set "2025-01-01 12:00:00"
ただし、この設定を適用すると ホストの時刻も変更される可能性がある ため、影響をよく理解しておく必要があります。
4. SYS_TIME を使わずにコンテナの時刻を変更する方法
「でも、どうしてもコンテナ内で時刻を変更したいんだ！」という場合、以下のような対策を考えましょう。
(1) SYS_TIME ケーパビリティを付与する
Kubernetes なら securityContext.capabilities.add を設定：
securityContext:
capabilities:
add: ["SYS_TIME"]
Docker なら --cap-add SYS_TIME を指定：
docker run --cap-add SYS_TIME ubuntu:22.04
⚠ 注意: これを付与すると、ホストの時刻も変更されてしまう。
5. まとめ
通常、コンテナ内で date --set ができないのは、
コンテナがホストのカーネルを共有しているため、コンテナの時刻変更 = ホストの時刻変更になってしまう
時刻変更はセキュリティリスクが高く、分散システムや証明書の問題を引き起こす可能性がある
そのため、デフォルトでは SYS_TIME ケーパビリティが削除されている
もし SYS_TIME を付与するなら、セキュリティリスクを理解したうえで適用しよう。
今後 timens の正式サポートが進めば、コンテナごとに時刻を分離できるようになるかもしれないので、それを待つのもアリ。
システムの時刻は多くのアプリやサービスに影響を与えるもの。むやみに変えず、適切な方法で扱っていこう！