情報セキュリティ体制に関するまとめ
皆さんこんにちは！
今回はkubernetesを支える技術は一度置いておき、最近取引先から、「情報セキュリティ体制はどうなっているの？」と聞かれたことから少し調べました。
もちろん会社の規模や組織によって異なりますので、その辺りは参考程度に、、、
情報セキュリティ体制図について(例)
おそらく一般的な体制図はこの様になっていると思います。
おまけ(セキュリティ関連の法律)
おまけとして、セキュリティ関連で抑えとくべき法律とその正式名称について調べました。
・マイナンバー法→行政手続における特定の個人を識別するための番号の利用等に関する法律
・迷惑メール防止法→特定電子メールの送信の適正化等に関する法律
・e-文書法→民間事業者等が行う書面の保存等における情報通信の技術の利用に関する法律
・プロバイダ責任制限法→特定電気通信役務提供者の損害賠償責任の制限及び発信者情報の開示に関する法律
・電子帳簿保存法→電子計算機を使用して作成する国税関係帳簿書類の保存方法等の特例に関する法律
kubernetes紐解き講座～vol.2~
今回も前回に引き続き、kubernetesを支える技術について書いていこうと思います。
まずとりあえず思い限り、kubernetesに関連する技術、支える技術について書き並べてみます！
コンテナ
cgroup
名前空間
クラスタリング
Kubernetes Network Policy
CSIプラグイン
CNIプラグイン
pod、node、master
OSI参照モデル（主にL2～L4）
TCP・UDP、MSS、MTU
VXLAN、VTEP
BGP
calico
サブネットマスク
iptables
etcd
flannel
docker
FIB、RIB
DSR
ARPテーブル、macアドレス
ネットワークのカプセル化
IPIP
API
ストレージ
ロードバランシング
このなかで、自身でもあまり馴染み無く、かつ最近の技術であるVXLANについて記載します。
(1)VXLANについて
VXLANは正式にはVirtual eXtensible Local Area Networkといいます。
今日では仮想化による大規模なサーバーの集約を行う事が当たり前とされており、データセンタにおいては、複数のクライント（企業もしくはサービス単位）を収容する事ができるインフラ環境の構築が必須となりました。
ここで大事になってくるのは、複数の顧客を収容する場合、異なる顧客同士のシステム間で通信できないように、ネットワークは分離されている 必要があります。
(2)ネットワークを分離するための技術
L2の分離に用いられていた技術に、VLAN（Virtual Local Area Network）があります。
VLANでは 約4000個のネットワーク（サブネット） を作る事ができます。
が、これだと大規模な環境ですと4000ネットワークでは足りません。
ここでVLANの欠点を補うためにVXLANが登場しました。
VXLANでは VNI（VXLAN Network Identifier） というネットワークの空間を使うことにより、 約1670万個のネットワーク（サブネット） を作る事ができます。
作られたネットワークは、 VTEP（Virtual Tunnel End Point） と呼ばれるゲートウェイを利用して L2トンネリング機能 を実現し、 既存のL3の世界の上で、L2の仮想環境を構築する ことで通信が可能になります。
VXLANを使うことにより複数のデータセンタをまたがるL2ネットワークを構築できるので、大規模でかつ柔軟なネットワーク設計が可能になるわけです！
・VXLANを構成する特徴的な技術
- UDP パケットの中にイーサネットフレームをカプセル化する
- VXLAN Network Identifier（VNI）24 ビットの ID にて約 1600 万の VLAN-ID が利用可能になる
- Virtual Tunnel End Point（VTEP）間でトンネリングする
まあ、ここまでお話しましたが、昨今ではAWSなどで、手軽にコンテナ技術を利用することができ、この辺りの知識はあまり意識しないでも問題なく構築は行なえます。しかし、ネットワークの部分をブラックボックスのように考えてしまうと、障害発生時や、オンプレからクラウドへの移行などにおいて調べるだけで余計に時間を費やしてしまうことになります。
次回も少し、VLANとそこから派生するflannelを説明していこうと思います。
kubernetes紐解き講座～vol.1~
皆さんこんにちはー。4月になり新人エンジニアの教育係担当中の南です。
本日の話題は、kubernetes（k8s）です。長くレガシーな技術の塊になるので今から数回に分けて話そうと思います！
FargateやEKSを学習する上で、kubernetesの知識や考え方はとても大事になるので、聞いて損は無いです。
kubernetesを一言で説明すると コンテナが稼働する複数のサーバーを束ねつつ、コンテナ自体も管理することができるオーケストレーションツール です。
これだけではピンとこないので、一つ一つの用語を考えます。
（１）コンテナ技術とは
コンテナ技術とは 既存のOS上にて複数のアプリケーションを、分離した環境で動かす技術 です。コンテナ自体は10年以上前からある技術であり、決して最近のものではありません。
ただ、コンテナを導入しようと考えたとき、流行っているから、すべてが便利になる
の考えは危険です。
他の仮想環境と比べて、コンテナ型のメリットとしては下記の３点です。
- 仮想サーバと比べてコンテナは起動が非常に速く、わずかのメモリ使用量ですむ
- コンテナが起動できるサーバならば、どのサーバでコンテナを起動しても一貫性のある環境が利用できるようになる
- 開発環境とテスト環境で動作検証したコンテナを、そのまま本番サーバにコピーして起動させて運用することも可能
（２）コンテナの活用例
昨今のアプリケーション設計では機能別にモジュールを分けてアジャイル開発を用いて、モジュール単位でのリファクタリングや機能拡張を行うことが多いと聞きます。
これにより 他のモジュールで障害が発生しても、自分のモジュールは実行し続けることができ、アプリケーション全体の信頼性が高まる というメリットがあります。
機能別に分けたモジュール を コンテナという単位で動作 させて それぞれを連携させる ことで 大きな一つのサービスとして提供できる ようにします。
またこの段階で、最近に注目されるようになってきたある概念について触れようと思います。それがDevOpsという概念です。
（３）DevOpsという考え方
正直DevOpsの考え方は今回で説明しきれないくらい深いので、簡単に説明すると、
DevOpsとは 開発（Development）と運用（Operations）が、お互いに協力しながらサービスを作り上げるというものです。
（４）kubernetesの登場
コンテナ技術をスムーズかつ簡単に扱うために、整ったインフラ環境が必要になってきます。そこでいよいよ kubernetes の登場です。
最初にも触れましたが、 kubernetesはコンテナ技術のオーケストレーションツール です。オーケストレーションツールとは コンポーネントとの連携や、煩雑・複雑な設定管理を自動化するツール です。
昨今は多くの情報に溢れ、技術ページもたくさんあり、専門的な知識がなくてもkubernetesを構築することは可能です。
システム設計の最終的な目標は、顧客の要件を満たしたシステムを安定的に稼働させることです。作ったはいいが、運用上問題がある、頻繁に障害が発生しますではダメということです。
次回vol.2ではkubernetesを支える技術について考えていきましょう！
EC2でwindowsサーバ2019を構築するときの注意点
皆さんこんにちは。minami-engineerブログの南です。
本日はAWS環境でwindowsサーバを構築して、リモートデスクトップ接続するまでの段階で友人が40分近く少しハマってたのでその時の問題と解決法をここでも紹介したいと思います。
（※注意）
これはwindowsサーバというよりAWSの基本的な内容なのでご了承ください。
ポイント
インスタンスを接続するまでの大きな流れは多くの記事で紹介されたいるので、ここでは割愛して大事なポイントを紹介します。
1.自動割り当てパブリック IPは有効にする
2.セキュリティグループのインバウンドルールはRDP(ポート3389)を開ける
3.設定するサブネットグループはパブリックサブネットにする
これがハマっていた肝の部分。
ここをプライベートサブネットに設定してしまうと、通信はインターネットに出れないので、接続は出来ません。
※ちなみにパブリックとプライベートの見分け方は、ルートテーブルを確認して、
ターゲットがlocal以外にigw-xxxxxxのようについていたらこれはパブリックサブネットです。
ちょっとした補足
プライベートサブネットでも踏み台サーバを経由すれば接続は可能です。
要件的には検証では、踏み台を経由したほうが良い場合もあるので、ここはよく確認しましょう。
awspecでRDSリソースのテストでハマったこと～備忘録～
皆さんこんにちは。minami-engineerブログの南です。
本日はAWSのRDSのリソーステストで少しハマったことについて紹介させて頂きます。
awspecとは？
簡単に言うと、serverspecのAWSバージョンと考えて問題ないです。
エラーが出た箇所
簡単にいつものようにRDSのインスタンス(インスタンス名：tdd-testdb)
を作成し、テストを実行するとエラーが出た。
エラーの内容は”空いてるポートがコードのものと違う”というような内容のものだった。
参考した記事はこれです。↓
正直これでほとんどの書き方の雛形は揃っていると思うが、RDSのポート確認のテンプレートに関してはどれも試しても同様のエラーが出た。
解決方法
テストコードポートの確認はこれを行ったらエラーが出ず、成功した。
是非皆さんの参考にしていただきたいと思います。
require 'spec_helper'
db_date = {
name : 'tdd-testdb'
}
describe rds(db_date[:name]) do
it { is expected to exist }
it { is expected to be_available }
its ('endopoint.port') { is expected to eq 5432 }
end
一時間近くハマったのに結果この一行だったとは、、、
