aws bucket ls | xargs -L1 % aws s3api put-bucket-encryption \
--bucket % \
--server-side-encryption-configuration '{"Rules": [{"ApplyServerSideEncryptionByDefault": {"SSEAlgorithm": "AES256"}}]}'
s3 api 이용한 모든버킷 AES-256 암호화.
aws
AWS-VPC-rfc1918
요즘 ANS 공부를 하고 있다. 그러던 와중에 알게된 부분이다.
AWS에선 VPC 를 생성할때 RFC1918을 권장한다.
10.0.0.0 - 10.255.255.255 (10/8 prefix)
172.16.0.0 - 172.31.255.255 (172.16/12 prefix)
192.168.0.0 - 192.168.255.255 (192.168/16 prefix)
이 대역이다. 그러던중 IPv4 블록 연결제한 부분을 보게되었다.
https://docs.aws.amazon.com/ko_kr/vpc/latest/userguide/VPC_Subnets.html#VPC_Sizing
| IPv4 CIDR 블록 연결 제한 | ||
|---|---|---|
| 기본 VPC CIDR 블록이 상주하는 IP 주소 범위 | 제한되는 CIDR 블록 연결 | 허용되는 CIDR 블록 연결 |
| 10.0.0.0/8 | 다른 RFC 1918* 범위(172.16.0.0/12 및 192.168.0.0/16)의 CIDR 블록입니다.기본 CIDR이 10.0.0.0/15 범위에 해당되면 10.0.0.0/16 범위의 CIDR 블록을 추가할 수 없습니다.198.19.0.0/16 범위의 CIDR 블록입니다. | 제한되지 않는 10.0.0.0/8 r범위의 기타 모든 CIDR입니다.공개적으로 라우팅이 가능한 모든 IPv4 CIDR 블록(비-RFC 1918) 또는 100.64.0.0/10 범위의 CIDR 블록. |
| 172.16.0.0/12 | 다른 RFC 1918* 범위(10.0.0.0/8 및 192.168.0.0/16)의 CIDR 블록입니다.172.31.0.0/16 범위의 CIDR 블록입니다.198.19.0.0/16 범위의 CIDR 블록입니다. | 제한되지 않는 172.16.0.0/12 r범위의 기타 모든 CIDR입니다.공개적으로 라우팅이 가능한 모든 IPv4 CIDR 블록(비-RFC 1918) 또는 100.64.0.0/10 범위의 CIDR 블록. |
| 192.168.0.0/16 | 다른 RFC 1918* 범위(172.16.0.0/12 및 10.0.0.0/8)의 CIDR 블록입니다.198.19.0.0/16 범위의 CIDR 블록입니다. | 192.168.0.0/16 범위의 기타 모든 CIDR입니다.공개적으로 라우팅이 가능한 모든 IPv4 CIDR 블록(비-RFC 1918) 또는 100.64.0.0/10 범위의 CIDR 블록. |
| 198.19.0.0/16 | RFC 1918* 범위의 CIDR 블록입니다. | 공개적으로 라우팅이 가능한 모든 IPv4 CIDR 블록(비-RFC 1918) 또는 100.64.0.0/10 범위의 CIDR 블록. |
| 공개적으로 라우팅이 가능한 CIDR 블록(비-RFC 1918) 또는 100.64.0.0/10 범위의 CIDR 블록. | RFC 1918* 범위의 CIDR 블록입니다.198.19.0.0/16 범위의 CIDR 블록입니다. | 공개적으로 라우팅이 가능한 모든 다른 IPv4 CIDR 블록(비-RFC 1918) 또는 100.64.0.0/10 범위의 CIDR 블록. |
간단히 정리하면 해당 RFC1918중 하나의 대역을 사용하면 다른 대역을 사용할수 없는것이다.
예로..
이런식이다..
왜이렇게 AWS에서는 RFC1918에 대한 제한을 두었는지는 알수없다.
non-RFC1918 은또 사용할수 있기 때문이다.
추측을 하자면 어제 조언을해주신..여러분들의 의견을 종합해보자면..
관리상의 측면때문일거라 생각은 드는데..
결론은 나지 않았다.
간단하게 정리한 스샷..
긴밤에 같이 고민해 주신 김용대님 신승광님 서노아님께 감사를 드립니다!
읽어주셔서 감사하다!
AWS-auto-assign IP settings
기본 VPC의 경우에는 EC2를 생성할때 자동으로 인스턴스에 Public IP가 자동으로 붙는다.
이퍼블릭 IP는 생성되면 뗄수도없고 인스턴스를 종료후 재생성 해야지만 된다.
Private subnet 에서도 Public IP가 생성되는것이므로 보안상의 취약점을 초래한다.
따라서 인스턴스를 생성할때는
이렇게 퍼블릭 IP가 비활성화로 생성해야하는데 매번 일일이 신경써서 하기엔 불편하다.
VPC-서브넷 에서 자동 할당 IP 설정 수정 옵션을 해제해주면 된다.
해제하고 저장후 인스턴스를 생성해보면 아래와 같이 확인된다.
스샷에서 보이듯 서브넷의 기본설정을 수정하여 자동으로 비활성화 할수있다.
이미붙은 Public IP는 뗄수 없다.
명심하자. 모든 EC2는 Public IP 없이 생성해야한다.
읽어주셔서 감사하다!
좋은하루 되시라!
AWS-GCP-Azure-network-none-rfc1918
VPC를 생성하는 경우, 다음과 같이 /16RFC 1918:규격에 따라 프라이빗(비공개적으로 라우팅 가능) IPv4 주소 범위에 속하는 CIDR 블록( 또는 이하)을 지정하는 것이 좋습니다.
-_-;공인IP를 쓸수있는건 아니지만 걍 아무대역 가져다 써도 VPC는 생성 가능하다.
갑자기 궁금해져서 퍼블릭클라우드는 비RFC1918을 지원하는지 모두 테스트 해보았고 모두 지원한다~
DOCS에서 명확하게 적혀있는것은 AWS 뿐이었다.
Azure
VNet 내에서 사용할 수 있는 주소 범위는 무엇입니까?
RFC 1918에 정의되어 있는 모든 IP 주소 범위를 사용할 수 있습니다. 예를 들어 10.0.0.0/16을 사용할 수 있습니다. 다음 주소 범위는 추가할 수 없습니다.
- 224.0.0.0/4(멀티캐스트)
- 255.255.255.255/32(브로드캐스트)
- 127.0.0.0/8(루프백)
- 169.254.0.0/16(링크-로컬)
- 168.63.129.16/32(내부 DNS)
GCP
서브넷 및 IP 범위
서브넷을 만들 때 기본 IP 주소 범위를 정의해야 합니다. 선택사항으로 보조 IP 주소 범위를 정의할 수 있습니다.
- 기본 IP 주소 범위: 서브넷의 기본 IP 주소 범위에 대한 비공개 RFC 1918 CIDR 블록을 선택할 수 있습니다. 이러한 IP 주소는 VM 기본 내부 IP 주소, VM 별칭 IP 주소, 내부 부하 분산기의 IP 주소에 사용할 수 있습니다.
뭐야.. 애매하잖아 다되는데
AWS-Security-Group-Tip
지금까지는 대량의 IP를 컨트롤 할땐..CLI를 이용하거나..
한줄씩 넣었다.
그도 그럴게..
(구)인터페이스 를 보면 한번에 하나의 IP만 넣을수 있게 되어있어 보이는 것이다.
그래서 지금까지의 나는 여러개의 IP에 동일한 프로토콜일 경우 여러개의 규칙을 추가했었다.
그런데 오늘 대량의 IP를 추가하려고 보니 CLI를 쓰기 너무 귀찮았다.
그래서..설마 구분자가 먹는거아냐? 싶어서 콤마를 써봤다.
ex) 192.168.1.1/32,192.168.2.1/32,192.168.3.1/32,192.168.4.1/32,192.168.5.1/32
다섯개의 32bit IP를 ,로 구분하고 이건 소스 IP에 넣는다
이런식으로..그리고 저장
한꺼번에 추가가 된게 보인다. 그럼 새로운 인터페이스에선?
이렇게 추가된다...하...왜이걸 몰랐지..?
나만 몰랐던걸로 하자.
하..씁슬
읽어주셔서 감사하다!
