강2월드

158. Authorization

Why Authorization? 

권한을 지정하여 할 수있는 작업을 제한 해야한다. 

Authorization Mechanisms

인증 메카니즘으로 노드, abac, rbac, webhook 이 있다. 

Node

kubeapi서버에는 사용자도 접근하고 kubelet 도 접근한다. 

kubelet 이 정보를 요청할 때 kubeapi 에 인증을 했기 때문에 kube api 가 응답하는 것이다.

해당 승인을 하는 곳이 node Authorizer 이다. 

ABAC - 특성 기반 승인

사용자를 추가시켜서 권한을 부여한다. 

당연히 일일히 수동으로 추가하면 귀찮으니까 ...

RBAC - 역할 기반 인증

역할 기반으로 하면 좀 더 쉽게 권한 제어가 가능하다. 

Webhook 

외부에서 권한 제어를 하고 싶다면 ?

Open Policy Agent 가 권한을 체크해준다. 

Authorization Mode

AlwaysAllow, AlwaysDeny 이 두가지가 있다. 

kubeapiserver를 보면 authorization 을 확인할 수 있다.

default 는 always allow 이다. 

하나가 거부되면 다음 모드에서 확인하고 승인되면 넘겨준다. 

159. Role Based Access Control 

역할을 생성해보자! 

 rule을 여러개 추가할 수도 있다. 

RoleBinding Object

생성한 역할을 쓰기 위해 rolebinding 객체를 생성해야한다. 

View RBAC

해당 명령어로 role 확인

Check Access - can-i 

can i  명령어로 체크할 수 있다. 

--as user 옵션으로 해당 유저의 권한을 체크할 수 있다. 

Resource Names

리소스 이름으로 권한 제한을 할 수 있다. 

( 여기서 resourceNames 가 네임 스페이스 인가 확인해봐야겠다.) 

160. Practice Test - RBAC

1. Inspect the environment and identify the authorization modes configured on the cluster.

kube-apiserver.yaml 위치 

cat /etc/kubernetes/manifests/kube-apiserver.yaml 

Node, RBAC 이다. 

2. How many roles exist in the default namespace?

3. How many roles exist in all namespaces together?

12개

4.  What are the resources the kube-proxy role in the kube-system namespace is given access to?

configmaps

5. What actions can the kube-proxy role perform on configmaps?

get

6. Which of the following statements are true?

7. Which account is the kube-proxy role assigned to?

 Group 부분 

8. A user dev-user is created. User's details have been added to the kubeconfig file. Inspect the permissions granted to the user. Check if the user can list pods in the default namespace.

9.

10.  A set of new roles and role-bindings are created in the blue namespace for the dev-user. However, the dev-user is unable to get details of the dark-blue-app pod in the blue namespace.

We have created the required roles and rolebindings, but something seems to be wrong.

resourceNames 에 dark-blue-app 을 추가해준다. 

 

11. Add a new rule in the existing role developer to grant the dev-user permissions to create deployments in the blue namespace.

Remember to add api group "apps".

추가가해준다. 

162.  Cluster Roles and Role bindings

클러스터 롤과 클러스터롤바인딩에 대해 배워보자.

Namespace

네임스페이스로 걸러지는 리소스가 있고 그 외는 클러스터단의 리소스라고 보면된다. 

확인하고 싶으면 namespaced 옵션을 이용하면 된다. 

지난 시간에 만든 role 과 rolebinding은 네임스페이스에 영향을 받는 구간이다. 

만야 클러스터 단에서 클러스터롤과 바인딩 하고 싶다면?

Clusterroles

예시

clusterrolebinding

비슷하다! 

클러스터롤 로 파드에 접속하게 허락하면 클러스터내의 모든 파드에 접근할 수 있다. 

163. Practice Test - Cluster Roles and Role Bindings

1. For the first few questions of this lab, you would have to inspect the existing ClusterRoles and ClusterRoleBindings that have been created in this cluster.

2. How many ClusterRoles do you see defined in the cluster?

--no-headers | wc -l 옵션으로 갯수를 찾을 수 있다. 

3. How many ClusterRoleBindings exist on the cluster?

4. What namespace is the cluster-admin clusterrole part of?

5. What user/groups are the cluster-admin role bound to?

The ClusterRoleBinding for the role is with the same name.

6. What level of permission does the cluster-admin role grant?

Inspect the cluster-admin role's privileges.

1. Perform any action on any resource in the cluster<- 
2. Pod level tasks only
3. Security related tasks only
4. Node level tasks only

7. A new user michelle joined the team. She will be focusing on the nodes in the cluster. Create the required ClusterRoles and ClusterRoleBindings so she gets access to the nodes.

8. michelle's responsibilities are growing and now she will be responsible for storage as well. Create the required ClusterRoles and ClusterRoleBindings to allow her access to Storage.

Get the API groups and resource names from command kubectl api-resources. Use the given spec:

clusterrole 생성

clusterrolebinding 생성

 165. Service Accounts

서비스 어카운트의 개념을 알아보자! 

account 종류

user 사람

service none 사람

프로메테우스나 젠킨스 같은거 

dash board 애플리케이션을 만든다면 kube-api에 수시로 요청을 날려야한다. 

당연히 인증이 필요하다.

이럴 때 서비스 계정을 써야한다. 

ServiceAccount 관련 명령

토큰의 내용은 암호화되고 해당 토큰으로 kubeapi 에 인증한다.

시크릿 객체이다. 

서비스 객체를 생성하면 토큰을 생성하고 해당 토큰을 시크릿 객체에 넣는다. 

그 후 시크릿 객체와 서비스 객체랑 연결된다. 

따로 시크릿 객체만 확인하는 것도 가능하다.

curl 에 토큰 데이터를 넣어서 api에 접속할 수도 있다. 

토큰 마운팅

토큰을 마운팅 하면 앱에서 쉽게 kubeapi 에 접속 가능하다.

default sa 는 기본으로 생성됨. 

자세히 보면 volumes 에 default 토큰이 마운트 된다. 

마운트 된 디렉터리를 확인하면 3가지 파일이 있다.

sa 지정해서 사용하기

파드 종료했다가 다시 켜야한다.

1.22/1.24 업데이트 사항

토큰을 복호화 했을때 자세히 보면 만기 기간이 없다.

TokenRequestAPI v1.22

토큰 관리를 위한 api 가 추가되었다.

pod를 생성하면 주기를 갖는 토큰이 마운트 된다. 

v1.24

예전엔 sa 만들면 토큰도 같이 생성됬지만 이젠 따로 생성해야한다.

이제 토큰에 만기 기간이 뜬다. 

secret 도 생성해야한다. 

166. Practice Test Service Accounts

1. 

How many Service Accounts exist in the default namespace?

2개

2.

What is the secret token used by the default service account?

none

3.

We just deployed the Dashboard application. Inspect the deployment. What is the image used by the deployment?

4. 

Wait for the deployment to be ready. Access the custom-dashboard by clicking on the link to dashboard portal.

연결되었다. 

5. What is the state of the dashboard? Have the pod details loaded successfully?

failed

6. What type of account does the Dashboard application use to query the Kubernetes API?

service account 에 연결된다. 

7. Which account does the Dashboard application use to query the Kubernetes API?

default 이다..

8. Inspect the Dashboard Application POD and identify the Service Account mounted on it.

yaml 열어서 확인

9.

At what location is the ServiceAccount credentials available within the pod?

10. The application needs a ServiceAccount with the Right permissions to be created to authenticate to Kubernetes. The default ServiceAccount has limited access. Create a new ServiceAccount named dashboard-sa.

11. We just added additional permissions for the newly created dashboard-sa account using RBAC.

Ok

 

12. Enter the access token in the UI of the dashboard application. Click Load Dashboard button to load Dashboard

Create an authorization token for the newly created service account, copy the generated token and paste it into the token field of the UI.

To do this, run kubectl create token dashboard-sa for the dashboard-sa service account, copy the token and paste it in the UI.

복붙하기

13.

sa 다시 붙이기

디플로이먼트에서 변경

14. Refresh the Dashboard application UI and you should now see the PODs listed automatically.

이제 토큰 기입 없이 사용가능하다. 

150. Certificates API 

사용자와 클러스터가 있는 상황이다. 

나는 인증서와 키를 가지고 있다. 

사용자를 추가해야한다면? 

b 사용자의 인증서를 관리자한테 주고 관리자가 클러스터에 넘겨 서명을 받는다. 

그리고 사용한다. 

쿠버네티스  CA 서버

마스터 노드에 ca 서버가 있다면 마스터 노드 또한 ca 서버이다 ? 

매번 인증서를 넘기고 서명 받는 작업을 하는 것은 귀찮다. 

Certificates API 가 하는일

인증서를 건낸후 바로 서명 받고 돌려받는 것이 아니라 CSR객체를 만든다 .

객체가 생성되면 모든 유저들이 요청을 검토하고 확인할 수 있다.

1. openssl genrsa - 키생성

2. openssl req - 관리자에게 요청

3. 관리자는 서명 요청 객체 생성

요청은 베이스 64 명령어로 암호화 해야한다.

그 후 인코딩된 텍스트를 요청 필드로 옮기고 요청을 제출한다.

 CSR 이 생성된다. 

csr 확인하기 

인증서 서명하기 

csr yaml 파일을 확인하면 cert 부분은 base 64 로 암호화되어있다. 

ca는 controlplane 어느부분에서 담당할까 ?

컨트롤러 매니저에서 담당한다. 

controller manager 안에 csr-approving, csr-sigining 이 존재한다.

누구든 인증서에 서명하려면 CA 서버의 root 인증서와 개인키 

151. Practice Test - Certificates API 

1.

csr과 key 가 있다. 

2.

Certificate Signing Requests | Kubernetes

Create CertificateSigningRequest

Create a CertificateSigningRequest and submit it to a Kubernetes Cluster via kubectl. Below is a script to generate the CertificateSigningRequest.

cat <<EOF | kubectl apply -f -
apiVersion: certificates.k8s.io/v1
kind: CertificateSigningRequest
metadata:
  name: myuser
spec:
  request: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURSBSRVFVRVNULS0tLS0KTUlJQ1ZqQ0NBVDRDQVFBd0VURVBNQTBHQTFVRUF3d0dZVzVuWld4aE1JSUJJakFOQmdrcWhraUc5dzBCQVFFRgpBQU9DQVE4QU1JSUJDZ0tDQVFFQTByczhJTHRHdTYxakx2dHhWTTJSVlRWMDNHWlJTWWw0dWluVWo4RElaWjBOCnR2MUZtRVFSd3VoaUZsOFEzcWl0Qm0wMUFSMkNJVXBGd2ZzSjZ4MXF3ckJzVkhZbGlBNVhwRVpZM3ExcGswSDQKM3Z3aGJlK1o2MVNrVHF5SVBYUUwrTWM5T1Nsbm0xb0R2N0NtSkZNMUlMRVI3QTVGZnZKOEdFRjJ6dHBoaUlFMwpub1dtdHNZb3JuT2wzc2lHQ2ZGZzR4Zmd4eW8ybmlneFNVekl1bXNnVm9PM2ttT0x1RVF6cXpkakJ3TFJXbWlECklmMXBMWnoyalVnald4UkhCM1gyWnVVV1d1T09PZnpXM01LaE8ybHEvZi9DdS8wYk83c0x0MCt3U2ZMSU91TFcKcW90blZtRmxMMytqTy82WDNDKzBERHk5aUtwbXJjVDBnWGZLemE1dHJRSURBUUFCb0FBd0RRWUpLb1pJaHZjTgpBUUVMQlFBRGdnRUJBR05WdmVIOGR4ZzNvK21VeVRkbmFjVmQ1N24zSkExdnZEU1JWREkyQTZ1eXN3ZFp1L1BVCkkwZXpZWFV0RVNnSk1IRmQycVVNMjNuNVJsSXJ3R0xuUXFISUh5VStWWHhsdnZsRnpNOVpEWllSTmU3QlJvYXgKQVlEdUI5STZXT3FYbkFvczFqRmxNUG5NbFpqdU5kSGxpT1BjTU1oNndLaTZzZFhpVStHYTJ2RUVLY01jSVUyRgpvU2djUWdMYTk0aEpacGk3ZnNMdm1OQUxoT045UHdNMGM1dVJVejV4T0dGMUtCbWRSeEgvbUNOS2JKYjFRQm1HCkkwYitEUEdaTktXTU0xMzhIQXdoV0tkNjVoVHdYOWl4V3ZHMkh4TG1WQzg0L1BHT0tWQW9FNkpsYWFHdTlQVmkKdjlOSjVaZlZrcXdCd0hKbzZXdk9xVlA3SVFjZmg3d0drWm89Ci0tLS0tRU5EIENFUlRJRklDQVRFIFJFUVVFU1QtLS0tLQo=
  signerName: kubernetes.io/kube-apiserver-client
  expirationSeconds: 86400  # one day
  usages:
  - client auth
EOF

 

 

csr 파일의 형식과 다르다. 

csr 파일을 -> base 64 로 암호화한뒤 akshay.yaml 파일의 req 부분에 복붙한다. 

실행하기

3. What is the Condition of the newly created Certificate Signing Request object?

pending

4. Approve the CSR Request

요청 승인하기 

5. How many CSR requests are available on the cluster?

2개

6.

During a routine check you realized that there is a new CSR request in place. What is the name of this request?

agent smith

7.

Check the details about the request. Preferebly in YAML.

masters 그룹에서 요청

8. That doesn't look very right. Reject that request.

k certificate deny agent-smith 로 요청 거부할 수 있다. 

9. Let's get rid of it. Delete the new CSR object

153. KubeConfig

사용자가 my-kube-playground   클러스터로 인증서 요청을 날린다면 

아래는 kubectl 을 이용한 요청 

키, 인증서, ca

매번하면 귀찮기 때문에 kubeconfig 를 만들어서 쉽게 사용

kubeconfig file 의 경로는 $HOME/.kube/config 이다. 

기본으로 설정되어있기 때문에 이때까지 생략하고 잘 쓴거

 KubeConfigFile의 구성

Clusters, Contexts, Users 

이 세가지 context는 어떤 유저가 어떤 클러스터에 접근할 수 있는지 명시한다. 

mykubeplayground, certificate-authority 는 클러스터로 간다. 

키, 인증서는 users 로 간다. 

두개를 조합해서 컨텍스트를 만든다. 

yaml 파일에서 확인 

clusters, user, context 이렇게 되어있다. 

파일은 그대로 두고 kubectl 로 실행 

kubectl 은 어떤 컨텍스트를 골라야할까 ? 

currentcontext를 사용해 기본 컨텍스트 정의 

kubectl config

클러스터 확인 가능

현재 컨텍스트 변경하기 

use context 로 컨텍스트를 변경한다. 

네임스페이스 관련

네임스페이스는 클러스터 단위에서 생성된다.

컨텍스트 부분에 네임스페이스도 명시한다. 

Certificates in kubeConfig

인증서 파일의 경우 전체 경로를 쓰는 것이 좋다.

ca 파일의 경우 그냥 crt 내용을 암호화해서 복붙할 수도 있다. 

154. Practice Test - KubeConfig

1.  Where is the default kubeconfig file located in the current environment? 

Find the current home directory by looking at the HOME environment variable.

실행해보고 확인가능 

/root/.kube/config

 

2. How many clusters are defined in the default kubeconfig file?

 

1개

 

3. How many Users are defined in the default kubeconfig file?

1개

4. How many contexts are defined in the default kubeconfig file?

1개

5. What is the user configured in the current context?

6. What is the name of the cluster configured in the default kubeconfig file?

kubernetes

7. A new kubeconfig file named my-kube-config is created. It is placed in the /root directory. How many clusters are defined in that kubeconfig file?

4개

8. How many contexts are configured in the my-kube-config file?

4개

9. What user is configured in the research context?

dev-user

10. What is the name of the client-certificate file configured for the aws-user?

11. What is the current context set to in the my-kube-config file?

12.

Once the right context is identified, use the kubectl config use-context command.

 

my-kubeconfig 가 기본 config 파일이 아니기 때문에 --kubeconfig 옵션이 필요하다. 

 

13. We don't want to have to specify the kubeconfig file option on each command. Make the my-kube-config file the default kubeconfig.

 

파일을 기본 디렉터리로 옮긴다. 

14.

Try running the kubectl get pods command and look for the error. All users certificates are stored at /etc/kubernetes/pki/users.

 

developer.crt. 가 아니라 dev-user.crt 로 되어있다. 

/root/.kube/config 파일을 수정하자. 

157. API Groups

api 버전을 확인하고 싶다면? 

master 노드 포트에 접속해서 확인가능하다. 

이렇게도 접속가능하다. 

api 포드에 대해 집중해보자 

쿠버네티스api 는 여러종류로 나눠진다. 

core api 에는 우리가 아는 중요한거 다 들어있다. 

naemd api 에는 다양한 기능들이 있다. 

마스터 노드 포트로 바로 접속하면 사용 가능한 api 그룹 리스트가 나온다. 

인증서 없이 클러스터 api 에 접속할 수 없다. 

키,인증서, ca 를 넘겨야한다. 

Kubectl Proxy 로 접속하기

프록시로 접속한후 8001 포트를 통해 api 리스트를 가져올 수 있다. ( 인증서 필요 없음) 

Kube proxy ≠ kubectl proxy

엄연히 다른거다. 

144. TLS in Kubernetes

쿠버네티스에서 TLS 를 이용하여 보안해보자 

세가지 종류의 인증서

서버 , 클라이언트, ca 의 인증서 세가지 

호스트와 워커노드 사이에 통신할때 보안

관리자가 호스트에 접속할때도 보안

kube-apiserver가 다른 컴포넌트랑 통신할때도 보안 

Server Certifiactes for Servers

서버도 마찬가지로 공용키와 사설키를 가진다. 

Client Certifiacates for Clients

kubeapiserver 입장에서 모두 클라이언트이다. 

etcd server 입장에서는 kube api server는 클라이언트다. 

증명서 종류가 너무 많다. 

145. TLS in Kubernetes - Certificate Creation

인증서를 생성하는 것에 대해 배워보자

open ssl 을 이용하여 생성

1. 프라이빗 키 생성

2. CSR 요청

3. 서명하기 

admin 도 마찬가지 

다른것도 다 비슷하다. 

잘모르겟다.. 

148. Practice Test - View Certificates

1. Identify the certificate file used for the kube-api server.

cat /etc/kubernetes/manifests/kube-apiserver.yaml 

해당 경로에서 kube-apiserver.yaml 파일을 확인하다. 

command 부분을 확인하면 

tls-cert-file 경로를 보면 된다. 

2. Identify the Certificate file used to authenticate kube-apiserver as a client to ETCD Server.

인증하는 파일이므로 

/etc/kubernetes/pki/apiserver-etcd-client.crt

3. Identify the key used to authenticate kubeapi-server to the kubelet server.

key 니까 

4. Identify the ETCD Server Certificate used to host ETCD server.

Etcd.yaml 파일로 이동한다. 

해당 cert file 이다 .

5.

trusted-ca-file 이다 .

6. What is the Common Name (CN) configured on the Kube API Server Certificate?

OpenSSL Syntax: openssl x509 -in file-path.crt -text -noout

common name은 tls-cert-file 을 통해서 확인할 수 있다. 

열기 

cn 

kube-apiserver.이다. 

7. What is the name of the CA who issued the Kube API Server Certificate?

Issuer 이다. 

kubernetes

8. Which of the below alternate names is not configured on the Kube API Server Certificate?

dns 를 통해서 대체 이름을 확인할 수 있다. 

9. What is the Common Name (CN) configured on the ETCD Server certificate? 

etcd

10. 

How long, from the issued date, is the Kube-API Server Certificate valid for?

File: /etc/kubernetes/pki/apiserver.crt

 

기간은 1년이다. 

 

11.

How long, from the issued date, is the Root CA Certificate valid for?

File: /etc/kubernetes/pki/ca.crt

10년이다. 

12.

파드에 커넥션 에러가 뜬다. 

경로 수정

13.

This indicates an issue with the ETCD CA certificate used by the kube-apiserver. Correct it to use the file /etc/kubernetes/pki/etcd/ca.crt.

Once the YAML file has been saved, wait for the kube-apiserver pod to be Ready. This can take a couple of minutes.

kube-apiserver.yaml 파일 수정하자

323. NAT 인스턴스

NAT Instance

• NAT= Network Address Translation
• 사설 서브넷의 EC2 인스턴스가 인터넷에 연결되게 한다. ( 배스천 서버랑 비슷한 듯 다르다.) 
• 공용 서브넷에 NAT 을 설치해야한다. 
• EC2 설정에서 : Source / destination Check 옵션을 비활성화 해야한다.
• EIP 가 부착되어야한다.
• 라우팅 테이블에 사설 서브넷이 NAT 인스턴스로 연결되도록 구성해야한다. 

사설 서브넷의 ec2가 외부의 server 와 통신할려면 .공용 서브넷의 NAT 인스턴스에 연결하고 여기서 라우팅을 변경한다. 

server 입장에서 패킷을 받았을때 10.0.0.20 소스가 아니라 12.34.56.78 소스이다. 

이런 식으로 구성해 볼 것이다. 

Comment 

사실 NAT 인스턴스는 이제 NatGateway로 구현할 수 있다. 

가용성도 낮고 대역폭도 작다. 

그래도 실습해보자! 

324. NAT 인스턴스 실습

인스턴스 설치

아마존에서 지원 하지 않기 때문에 커뮤니티 이미지를 설치해야한다. 

x86_64

네트워크 설정

지난 시간에 만든 PrivateInstance가 NAT 인스턴스로 접속하게 한다. 

중지로 저장

BastionHost 에서 privateInstance 접속하기 

ssh 명령어로 로그인

핑을 쏴도 보내지지 않는다. ?

프라이빗 서브넷에 접속은 가능하지만 인터넷에 연결이 되어있지는 않다. 

프라이빗 라우팅 테이블 수정하기 

0.0.0.0/0 외부 ip 로 갈려면 nat 인스턴스를 통해 가야하도록 정했다. 

하지만 여전히 인터넷 접속 불가능하다. 

Nat 인스턴스의 보안그룹 편집 

모든 ICMP - IPv4 허용

이제 핑이 된다. 

Nat 인스턴스 삭제하기 

324. NAT Gateway

NAT Gateway 

• AWS 에서 제공하는 NAT, 높은 광대역, 가용성 , 완전관리형
• 사용한 만큼 비용청구 
• 특별한 가용존에 사용되고 EIP를 사용한다. 
• ec2 와 같은 서브넷에서 사용될 수 없다.
• IGW 가 필요하다 private subnet -> NATGW -> IGW
• 5~45Gbps 광대역
• 보안그룹 관리할 필요 없음.

NAT GW 를 통해서 인터넷에 연결한다. 

NAT GW 의 고가용성

NAT GW은 az에 국한된다. 

여러개의 NAT GW를 구성해서 내결함성을 가질 수 있다. 

AZ를 가로질러 갈 수 없다. 

NAT GW 와 NAT instance 와 비교

결론은 NAT GW 가 좋다. 

보안그룹 x , 배스천 호스트 쓸 필요도 없다. 

326. NAT Gateway 실습

Nat Instance 삭제

위에서 Nat instance를 삭제하고 나면

privateRouteTable에서 라우팅 에러가 뜬다 .

0.0.0.0/0 의 대상은 nat instance 였기 때문

NAT Gateway 생성

EIP 를 할당해서 생성해보자!

라우팅 테이블 편집

privateRoubeTable 에서 0.0.0.0/0 은 NatGW 로 가게 한다. 

privateinstance 가 인터넷에 연결 가능해졌다

327. NACL 및 보안그룹

NACL 은 stateless 라서 들어오고 나가는거 다 확인하지만 

SG는 stateful 이라서 한번이라도 확인하면 그후에는 검사안하고 허용해준다. 

• NACL 은 서브넷 단의 방화벽 역할 
• 한 서브넷당 하나의 NACL 을 가지고 처음에는 기본 NACL 을 가진다. 
• NACL 규칙 
  • 1~32766 의 번호를 가지고 낮은 숫자일 수록 우선 순위가 높다. 
  • 100 단위로 하는 것을 권장 
• 초기에 NACL 은 모든 접속을 거부할 것이다. 
• NACL은 특정 IP 주소의 접근을 차단하는 훌륭한 방법이다. 

기본 NACL

기본 NACL 은 모든 인/아웃바운드를 허용한다.

임시 포트

• 클라이언트가 연결할려면 포트를 지정해야한다. 하지만 응답 받을때 특정한 포트로 받을 수 있다.
• OS 에 따라 포트 범위가 다르다. 

접속할때 443 포트를 지정했지만 응답시 50105 임의의 포트로 응답받게 했다. 

NACL 과 임시포트

웹서버에서 db로 접속할때 3306 을 명시한다.

응답 받을 때는 임시 포트로 응답받기 때문에 다른 범위의 포트로 받게 되면 못 받기 때문에 조심해야한다.

각각의 연결 조합을 고려해야한다.

Security Group vs. NACLs  

sg 는 인스턴스  NACL 은 서브넷 단 

sg는 허용 규칙 NACL 은 허용, 거부 규칙 가능 -> 특정 ip 거부 가능

328. NACL 및 보안 그룹 실습

인바운드 규칙에 모두 허용이다. 100 숫자가 낮기 때문에 

HTTPD 서버 설치

배스천 호스트로 이동 

sudo yum install -y httpd

sudo systemctl enable httpd

sudo systemctl start httpd

sudo su

echo "hello world" > /var/www/html/index.html

bastion 호스트의 sg 인바운드 규칙 편집

배스천 호스트에 접속할 수 있다. 

NACL 수정해보기 

80 번으로 http 접속을 거부하는 규칙을 추가해보자 

-> 무한로딩에 걸린다 .

80을 140 으로 하면 100이 우선시 되서 접속이 잘된다. 

329. VPC 피어링 

VPC Peering

서로다른 aws 네트워크를 연결하는 기술 

같은 네트워크에 있는 것처럼한다. 

CIDR를 중복시키지 말것 

전이 되지 않는다. ( a와 b 연결, b와 c 연결 했다고해서 a~c 연결되는 것은 아니다. ) 

Good to know 

다른 계정, 다른 리전의 VPC 와 연결할 수 있다. 

보안 그룹도 공유할 수 있다. 

VPC 피어링을 해보자! 

330. VPC 피어링 실습 

DdfaultVPC 와 DemoVPC 를 연결해보자! 

Default Instance 만들기 

DefaultVPC 로 지정한다 .

해당 인스턴스로 접속

bastion 호스트에도 접속

지난 시간에 만들었던거

여기서도 똑같이 뜨게 만들자.

피어링 연결 생성

요청 수락 작업을 한다. 

라우팅 테이블 수정하기

 Default 라우팅 테이블이랑 PublicRouteTable을 연결할 것이다. 

DefaultVPC 의 CIDR 172.31.0.0/16 으로 들어오는건 피어링 연결로 다 접속 시킨다. 

이번엔 DefaultRouteTable 수정

DemoVPC의 CIDR 10.0.0.0/16 으로는 피어링 연결로 보낸다. 

연결되었다.

결론 

vpc 피어링하고 서로 연결하게 할려면 routetable 두개다 수정해야한다. 

143. TLS Basis 

유저 데이터가 암호화되어야하는 이유

평문으로 보낸다면 해커한테 바로 노출됨.

키로 암호화 한 후 전송한다면...

해커는 봐도 모른다. 서버도 모른다.

그래서 복호화 키도 같이 보내야한다. 

그러면 해커도 이 키를 탈취하면 소용없는거 아니냐 

-> 대칭 키

복호화, 암호화 키 같음

해커가 키를 훔치면 위험함

비대칭 암호화 

private key 와 public key 를 사용한다. 

암호화 하기, 복호화 하기 기능이 분리되어있다.

비대칭 암호화 - SSH

공용키로 서버를 잠근다.  -> 프라이빗 키로만 들어갈 수 있게 한다. 

ssh 접속할때 프라이빗 키를 명시하고 접속한다. 

서버를 추가한다면? 

똑같이 공용키로 잠궈버린다. 

사용자를 추가한다면? 

공용키로 한번더 잠궈버린다. 

비대칭 암호화 - 예시 

서버에서 공용키와 프라이빗 키를 만든다 .

서버에서 만든 공용키를 받는다. 

나의 대칭키를 공용키로 잠근다. 

해커는 서버의 프라이빗 키가 없기 때문에 열수가 없다.

서버는 프라이빗키로 열고 사용자의 대칭키를 받는다. 

이후 사용자는 대칭키로 암호화한 정보만 전달할 수 있다. (복호화를 위한 대칭키는 서버에 이미 전달 했으니까)

해커가 피싱 사이트를 만든다면? 

해커가 작정하고 비슷하게 생긴 피싱 사이트를 만든다면 ?

인증서

위와 같은 사례를 방지하기 위해 서버에서 공용키만 보내는 것이 아닌 인증서도 같이 보낸다. 

인증서가 위조 라면?

요즘은 브라우저가 인증서의 위조 여부를 다 판별한다. 

CA Certificate authority 

이들이 등장한다! 

인증서의 유효성을 확인해준다. 

csr 요청을 하고 나면 인증서에 서명해서 다시 보내준다. 

브라우저는 유효한 CA를 어떻게 알까? 

가짜 CA 을 만들어서 서명할 수도 있잖아

마찬가지로 CA들도 개인키와 공용키가 있다. 

브라우저에 공용키를 내장한다 .

웹브라우저를 자세히 보면 키가 다 있는 것을 알 수 있다.

공용키와 프라이빗 키 확장자