linuxer-admin

k8s-Centos7-install

#!/bin/sh
setenforce 0
sed -i --follow-symlinks 's/SELINUX=enforcing/SELINUX=disabled/g' /etc/sysconfig/selinux
swapoff -a
modprobe br_netfilter
echo '1' > /proc/sys/net/bridge/bridge-nf-call-iptables
yum install -y yum-utils device-mapper-persistent-data lvm2
yum-config-manager --add-repo https://download.docker.com/linux/centos/docker-ce.repo
yum install -y docker-ce
cat <<EOF > /etc/yum.repos.d/kubernetes.repo
[kubernetes]
name=Kubernetes
baseurl=https://packages.cloud.google.com/yum/repos/kubernetes-el7-x86_64
enabled=1
gpgcheck=1
repo_gpgcheck=1
gpgkey=https://packages.cloud.google.com/yum/doc/yum-key.gpg https://packages.cloud.google.com/yum/doc/rpm-package-key.gpg
EOF

yum install -y kubelet kubeadm kubectl
systemctl enable docker
systemctl enable kubelet
sed -i 's/cgroup-driver=systemd/cgroup-driver=cgroupfs/g' /usr/lib/systemd/system/kubelet.service.d/10-kubeadm.conf

K8s centos7 base install

userdate 등에 넣고 쓸수있다.

#Master 에서 작업

kubeadm init --pod-network-cidr=사용하려는 pod cidr
mkdir -p $HOME/.kube
sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
sudo chown $(id -u):$(id -g) $HOME/.kube/config

kubeadm join token 이 나오면 cluster node 에서 join 해준다

2020년 10월 27일 by Kubernetes 0

AWS-CloudFront-custom-header-ALB-filter

https://www.notion.so/CloudFront-ALB-f0086dec48b64f0883e0c6de5fd9da4c

Noah.Seo 님의 이야기를 받아서 다른방법을 테스트하게 되었다.

4번째 방법이 번득 떠오른탓.

그럼 내가 생각하는 부분은 이렇다.

CloudFront -> ALB

끝...3번 방법은 WAF에서 X-Origin-Verify Custom Header 를 필터링 한다. ALB에서도 비슷한 기능이 있는바. 나는 이전부터 ALB에서 내 블로그 도메인이 아닌 ALB 도메인이나 IP로 접근하는것을 제한한 바가 있다.

이 규칙이 바로 그것이다. Host 조건에 따라 Host가 다르면 아무 대상이 없는 blackhole 로 전달하게 된다. 그렇다. Custom Header를 ALB에서 필터링 할거다.

CloudFront 에서 Origin 을 수정한다.

단점은 ALB의 부하가 올라간다는것. 규칙에 의해 LCU 사용량이 증가할수 있다는 점이다.

그럼 셋팅해 보자.

X-Origin-Verify 헤더 네임을 추가하고 Value 로 test를 추가한다.

그리고 ALB의 규칙을 추가한다. 도메인 기반하여 http 헤더가 일치하면 라우팅. 그렇지않으면 두번째 규칙에 의해 blackhole로 전달한다. 지금 현재 정상적으로 헤더가 일치하여 사이트가 뜨는 상태다.

https://www.linuxer.name/

로 접근해보면 503에러가 발생하는것을 볼수있다.

재미있는 테스트 거리를 주신 Noah.Seo 님께 감사를 드린다.

2020년 10월 23일 by AWS 0

Amazon CloudFront Origin Shield-Review

Origin Shield 가 출시 되었다.

Origin 에 전달되는 리퀘스트의 횟수를 줄여 관리비용을 줄인다고 한다.

먼저 캐싱율을 보자.

70%대다.

개판이다..이게 어떻게 변할까?

Origin Shield Region 으로 서울리전을 선택했다.

설정자체는 어려울게 하나도 없고 일단....

기다려 봐야겠다.

그리고 하루정도 지난상태로 포스팅 쓰는것을 이어간다.

먼저 어제의 히트율

21 ~ 22일의 히트율.

22 ~ 23일 오? 효과가 있다.

더 모니터링 이후 내용을 추가하겠다.

오후에 추가한 내용 오...히트율이 엄청올라간다. 만세! 유효한 효과가 있음을 확인하였다.

2020년 10월 22일 by AWS 0

DNS-spf-google

spf 레코드는 RFC 4408 의해서 255 characters으로 제한된다.

하나의 레코드가 255 characters 라는 이야기다.

그래서 255 characters 이상을 쓰려면 어떻게 해야할까? 그것을 구글의 사용 예를 들어서 설명하고자 한다.

google.com text = "v=spf1 include:_spf.google.com ~all"

_spf.google.com 도메인을 include 하고 _spf.google.com 도메인을 쿼리하면

_spf.google.com text = "v=spf1 include:_netblocks.google.com include:_netblocks2.google.com include:_netblocks3.google.com ~all"

_netblocks.google.com
_netblocks2.google.com
_netblocks3.google.com

세개의 도메인을 알려준다. 세개의 도메인은 각각의 역할에 따라 ipv4나 ipv6를 응답한다.

_netblocks.google.com text = "v=spf1 ip4:35.190.247.0/24 ip4:64.233.160.0/19 ip4:66.102.0.0/20 ip4:66.249.80.0/20 ip4:72.14.192.0/18 ip4:74.125.0.0/16 ip4:108.177.8.0/21 ip4:173.194.0.0/16 ip4:209.85.128.0/17 ip4:216.58.192.0/19 ip4:216.239.32.0/19 ~all"

_netblocks2.google.com text = "v=spf1 ip6:2001:4860:4000::/36 ip6:2404:6800:4000::/36 ip6:2607:f8b0:4000::/36 ip6:2800:3f0:4000::/36 ip6:2a00:1450:4000::/36 ip6:2c0f:fb50:4000::/36 ~all"

_netblocks3.google.com text = "v=spf1 ip4:172.217.0.0/19 ip4:172.217.32.0/20 ip4:172.217.128.0/19 ip4:172.217.160.0/20 ip4:172.217.192.0/19 ip4:172.253.56.0/21 ip4:172.253.112.0/20 ip4:108.177.96.0/19 ip4:35.191.0.0/16 ip4:130.211.0.0/22 ~all"

이렇게 2단계의 include를 거쳐서 255 characters 이상의 레코드를 구성한다.

그렇다면 A recode로 spf 를 관리하려면 어떻게해야 할까?

https://spam.kisa.or.kr/filemanager/download.do?path=spam/customer/archive/&filename=SPF%EA%B8%B0%EC%88%A0%EB%AC%B8%EC%84%9C.pdf

linuxer.name text = "v=spf1 a:_1.linuxer.name ~all"

바로 이런식이다 include: 부분을 a: 로 변경하는것이다.

그리고.. spf 레코드는 사용하는 대역이나 ip를 알려주는것 외에 정책을 정하는 역할을 하는데 다음과 같은 규칙이 적용된다.

Neutral (?) 출판된 데이터에 근거해 판단을 내릴 수 없음
Pass (+) 가 인가되어진 발송서버로 확인됨
Fail (-) 가 인가되어지지 않은 발송서버로 확인됨
Softfail (~) 는 인가되지 않은 발송서버이나 “Fail” 정책의 적용은 유보함.

linuxer.name text = "v=spf1 a:_1.linuxer.name +all"

이런식이면 _1.linuxer.name a 레코드로 등록된 IP는 인가된 발송서버로 확인된다는 의미다.

오랜만에 spf 레코드를 다시 복습하면서 정보진흥원의 문서를 보며 감탄 또 감탄했다.

위의 문서를 꼭 보시라!

2020년 10월 13일 by Linux 1