소개
AWS 인프라 리소스를 다양한 SQL 쿼리로 조회 할 수 있도록한 steampipe 오픈소스를 평소에 많이 사용하고 있습니다.
steampipe 는 Turbot 에서 만든 오픈소스인데요. Turbot 에서 만든 또 다른 유용한 오픈소스가 몇가지 더 있습니다.
steampipe
: 클라우드 리소스를 SQL 쿼리로 조회 가능토록 해주는 오픈소스powerpipe
: steampipe 데이터 기반의 시각화 대시보드 제공flowpipe
: 코드 기반 자동화된 워크플로우 구현가능한 오픈소스
다른 오픈소스도 있지만 위 3가지가 서로간에 연계되어 사용할 수 있도록 설계되어있습니다.
이 중에서 flowpipe 에 대해 알아보고 간단히 사용해보려 합니다.
Flowpipe 란?
flowpipe 는 코드로 자동화된 워크플로우를 구현 가능하게 해주는 오픈소스입니다.
flowpipe 를 이용하면 ChatOps, Scheduled Jobs, Trigger 등을 이용하여 다양한 이벤트에 대한 대응을 할 수있습니다. 그리고 여러 소스들을 이용한 반복적인 작업이 있다면 이또한 코드를 이용한 워크플로우를 구축하여 자동화 할 수 있습니다.
워크플로우를 만드는데 사용할 소스들 중 Public Cloud, Mail, Slack, Jira, PagerDuty, Github, Okta 등등 많은 서비스들에 대한 플러그인을 제공해 주고 있어 쉽게 연동이 가능합니다. 플러그인에 없는 소스라도 flowpipe 에서는 API HTTP Request 를 별도로 지원하고 있기 때문에 API 지원만 된다면 얼마든지 연동이 가능합니다.
Terraform 의 HCL 언어를 기반으로 하고 있기 때문에 Terraform 을 사용해 보신 분이라면 문법 측면에서는 러닝커브가 높지 않을 것 같습니다. 그리고 steampipe 의 sql 쿼리를 이용하여서도 워크플로우 작성이 가능합니다.
Terraform 문법을 아신다면 Docs 에서 첫번째 learning 페이지의 예제만 보더라도 작성 구조와 방법을 금방 파악할 수 있으실 듯합니다.
그리고 sample 코드도 제공을 해주고 있는데요. sample 코드를 보면서 시나리오와 작성 코드를 보는 것도 flowpipe 를 이해하는데 도움이 되실듯합니다.
Flowpipe 활용 방안
위에서 언급한 sample 코드 링크를 통해서 flowpipe 에서 제공해주는 활용 샘플을 여러개 볼수 있는데요.
flowpipe 를 이용하여 할 수 있는 작업을 예로 들면 아래와 같은 작업들도 가능합니다.
- AWS 에서 Security Group 을 Any 오픈하는 정책을 만드는 이벤트를 trigger 하여 PagerDuty 로 인시던트를 생성하고, Slack 으로 메시지를 남기고, Approve 하면 Security Group 에 오픈 정책 삭제 (Server 모드로)
- 로컬에서 IP 를 flowpipe cli argument 로 전달하면 IP 정보와 requtation 정보등을 여러 온라인 서비스 API 를 통해 결과를 한번에 받아 확인 (CLI 모드로)
Flowpipe 는 기본적으로 CLI 모드와, Server 모드로 사용을 할 수 있는데요.
CLI 모드로 사용을 한다면, 평소에 하던 반복적인 작업을 flowpipe 로 작성하여 실행하면 한번의 실행으로 여러 작업을 하는 자동화가 가능합니다. 명령어를 alias 로 설정하면 간단한 명령어처럼도 사용할 수 있겠죠.
Server 모드로 사용을 한다면, hook 을 통해 trigger 를 받을 수 있고, 스케줄링 작업도 할수 있게 되어 더욱 복작합 워크플로우 구성도 가능합니다.
보안 측면에서도 여러가지 시나리오를 만들어 수동으로 하던 작업들을 flowpipe 로 구현을 한다면 침해 대응을 보다 빠르게 할 수 있을 듯합니다.
인프라나 SaaS 서비스들에 대한 규정 준수(Compliance) 모니터링 및 강제 준수에도 사용이 가능 할 듯합니다. 더불어 번거로운 정보 수집(indicator)단계도 하나의 워크플로우 작업으로 만들면 한 명령어로 여러 단계별 작업을 구현할 수 있을 듯합니다.
Flowpipe 장점
자동화된 워크플로우는 Flowpipe 를 이용하지 않더라도 직접 Python 이나 Go 나 Node.js 로 API 연동 개발을 통해 사실 얼마든지 구현할 수 있습니다.
하지만 HCL 문법을 따르는 Flowpipe 를 통해 구현한다면 선언적 코드로 작성이 되어 가시성이 훨씬 높아지는 장점을 가질 수 있을 것 같습니다. 그리고 구현 속도도 훨씬 빠르게 구현이 가능하고, 워크플로우 유지보수 측면에서도 많은 이점을 주지 않을까 합니다.
Flowpipe 사용
Flowpipe 설치는 docs 를 통해서 쉽게 설치가 가능하고, 사용 모드는 위에서 언급하였듯이 2가지가 있습니다.
CLI 모드
: CLI 명령어를 통해 워크플로우 실행Server 모드
: API Server 모드로서 trigger, scheduled 작업도 받을 수 있도록 실행
이중 먼저 CLI 모드
를 먼저 사용해보았습니다.
Flowpipe CLI 활용
간단한 워크플로우로 만들어 보았습니다.
CLI 모드를 먼저 활용해 보면,
먼저 실행 명령의 args 로 IP 를 전달하면 abuseIPdb
, virus total
두 서비스의 API 로 부터 IP 관련 정보(country, abuse confidence score, virustotal analysis result, score 등)를 한번에 받아보는 워크플로우입니다.
워크플로우 사용을 안한다면 각각의 서비스에 접속하여 IP 를 입력하고 결과를 각각 확인해야하는 번거로움이 있었겠지요.
flowpipe 설치되어있는 상태에서 폴더를 만들고 초기화를 합니다.
mkdir ip-checker
cd ip-checker
flowpipe mod init
flowpipe Hub 를 참고하여 abuseIPdb
, virus total
플러그인을 설치하고 API Key 를 config 로 설정하여 각각 서비스의 API 를 이용할 수 있도록 합니다.
완료되면 ipchecker.fp
파일을 만들어 아래 코드를 입력해봅니다.
pipeline "ipchecker" {
# CLI --arg ip='' 로 받을 param 정의
param "ip" {
type = string
default = "1.1.1.1"
}
# abuseipdb 서비스로부터 ip check
step "pipeline" "check_ip_address" {
pipeline = abuseipdb.pipeline.check_ip_address
args = {
ip_address = "${param.ip}"
}
}
# virustotal 서비스로부터 ip check
step "pipeline" "get_ip_address_report" {
pipeline = virustotal.pipeline.get_ip_address_report
args = {
ip_address = "${param.ip}"
}
}
# 결과 출력
output "abuseipdb" {
value = step.pipeline.check_ip_address.output
}
output "virustotal_last_analysis_stats" {
value = step.pipeline.get_ip_address_report.output.ip_report.data.attributes.last_analysis_stats
}
output "virustotal_reputation" {
value = step.pipeline.get_ip_address_report.output.ip_report.data.attributes.reputation
}
}
그리고 pipeline 을 실행합니다. (alias 를 이용하면 짧은 명령어로 사용도 가능합니다.)
flowpipe pipeline run ipchecker --arg ip='15.165.18.184'
실행 결과 아래와 같이 abuseIPdb
, virus total
조회 결과를 output 으로 한번에 확인할 수 있습니다.
결론
CLI 모드를 이용하여 정말 간단한 워크플로우를 한번 만들어 테스트를 해보았는데요. 플러그인이 없더라도 HTTP 요청도 지원하니 다양한 API 를 이용하여 여러 단계의 파이프라인도 만들 수 있을 듯하였습니다.
보안적으로도 ChatOps 를 이용하여 Interactive 한 파이프라인도 만들 수 있을 듯하니, 잘 활용할 수 있는 시나리오들을 생각해보려 합니다.
시간이 될때 Server 모드도 한번 테스트를 해봐야겠네요.