AWS S3 에서 직접 다운로드 금지하기

AWS S3 의 객체를 직접 다운로드를 보안상 금지해야 하는 경우가 있다. 이를 위해서 AWS S3 에 정책을 다음과 같이 하면 된다.

AWS S3 객체 직접 다운로드 금
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
{
    "Sid": "Deny get requests from Download Files",
    "Effect": "Deny",
    "Principal": "*",
    "Action": "s3:GetObject",
    "Resource": "arn:aws:s3:::DOC-EXAMPLE-BUCKET/*",
    "Condition": {
        "StringLike": {
            "aws:Referer": [
                "https://ap-northeast-2.console.aws.amazon.com/*",
                "https://s3.console.aws.amazon.com/s3/buckets/*",
                "https://s3.console.aws.amazon.com/s3/object/*",
                "https://DOC-EXAMPLE-BUCKET*"
            ]
        }
    }
}

s3:GetObject 액션에 대해서 거부 정책을 적용하고 Referer 를 이용해서 특정 URL 을 지정해주면 된다.

AWS S3 HTTPS 강제

AWS S3 와 통신을 하는 방법으로 HTTP, HTTPS 두가지 방법이 있다. 하지만 HTTPS 만으로 통신을 하기 위해서는 다음과 같이 정책을 지정해 줘야 한다.

AWS S3 정책
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
{
    "Sid": "AllowSSLRequestsOnly",
    "Effect": "Deny",
    "Principal": "*",
    "Action": "s3:*",
    "Resource": [
        "arn:aws:s3:::DOC-EXAMPLE-BUCKET",
        "arn:aws:s3:::DOC-EXAMPLE-BUCKET/*"
    ],
    "Condition": {
        "Bool": {
            "aws:SecureTransport": "false"
        }
    }
}

참고: AWS Config 규칙 s3-bucket-ssl-requests-only를 준수하려면 어떤 S3 버킷 정책을 사용해야 합니까?

AWS ATHENA 로 VPC FLOW LOG 분석하기 – 2

이전 글에서 AWS 의 Athena 를 이용한 VPC Flow Log 를 어떻게 분석하는지에 대해서 이야기 했다. VPC Flow Log 생성부터, S3 버킷 생성, Athena 데이터베이스와 테이블 그리고 Lambda 를 이용한 파티션 추가까지 비교적 많은 부분을 손봐야 했다.

이 방법은 파티션 작업을 Lambda 를 이용하는 방법으로 하루에 한번 실행시키도록 하고 있다. 하지만, AWS 에서는 이마져도 필요 없는 방법을 제공하는데, 그것이 바로 파티션 프로젝션(Partition Projection) 이다.

AWS 메뉴얼 주의사항

파티션 프로젝션을 하기 위해서 AWS 메뉴얼을 보고 따라했는데 되지 않는다. 정확히는 테이블 생성이 되지만 Athena 에서는 보이지 않는다.

Athena 의 데이터베이스는 Glue 를 이용한다. AWS Glue 가 가보면 Athena 의 테이블을 볼 수 있는데, AWS 메뉴얼대로 파티션 프로젝션을 생성하면 Glue 에는 나오지만 Athena 에는 안나온다. 이는 Glue 에서 S3 저장소를 인식하지 못해 나오는 문제다.

다음의 메뉴얼에는 문제가 있다.

일단 위 메뉴얼에는 파티션 프로젝션이 무엇인지를 설명하고 있다.

파티션 프로젝션 생성
PgSQL
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
CREATE EXTERNAL TABLE my_ingested_data (
...
)
...
PARTITIONED BY (
datehour STRING
)
LOCATION "s3://DOC-EXAMPLE-BUCKET/prefix/"
TBLPROPERTIES (
"projection.enabled" = "true",
"projection.datehour.type" = "date",
"projection.datehour.format" = "yyyy/MM/dd/HH",
"projection.datehour.range" = "2021/01/01/00,NOW",
"projection.datehour.interval" = "1",
"projection.datehour.interval.unit" = "HOURS",
"storage.location.template" = "s3://DOC-EXAMPLE-BUCKET/prefix/${datehour}/"
)

위 내용을 요약하면 버킷의 구조가 다음과 같다는 것이다.

1
2
3
s3://DOC-EXAMPLE-BUCKET/prefix/2021/01/01/00/
s3://DOC-EXAMPLE-BUCKET/prefix/2021/01/01/01/
s3://DOC-EXAMPLE-BUCKET/prefix/2021/01/01/02/

이런 구조에서 파티션 프로젝션을 걸어주면 자동으로 날짜시간으로 파티션이 형성된다.

VPC Flow Log 의 파티션 프로젝션

그렇다면 이제 VPC Flow Log 에 파티션 프로젝션을 걸어 테이블 생성해 보자.

VPC Flow Log 파티션 프로젝션 생성
PgSQL
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
CREATE EXTERNAL TABLE IF NOT EXISTS `vpc_flow_logs_prj`(
    `version` int,
    `account_id` string,
    `interface_id` string,
    `srcaddr` string,
    `dstaddr` string,
    `srcport` int,
    `dstport` int,
    `protocol` bigint,
    `packets` bigint,
    `bytes` bigint,
    `start` bigint,
    `end` bigint,
    `action` string,
    `log_status` string
)
PARTITIONED BY (`day` string) -- 파티셔닝 컬럼 지정
ROW FORMAT DELIMITED FIELDS TERMINATED BY ' '
LOCATION 's3://flow-log-buckets/AWSLogs/111111222222333333/vpcflowlogs/ap-northeast-2/'
TBLPROPERTIES
(
'projection.enabled' = 'true',
'projection.day.type' = 'date',
'projection.day.range' = '2022/08/23,NOW',
'projection.day.format' = 'yyyy/MM/dd',
'projection.day.interval' = '1',
'projection.day.interval.unit' = 'DAYS'
'storage.location.template' = 's3://flow-log-buckets/AWSLogs/1111112222222333333/vpcflowlogs/ap-northeast-2/${day}/'
)

위 쿼리문으로 테이블을 생성하면 AWS Glue 에서는 테이블이 생성되지만 Athena 에는 나오지 않는다. 그리고 AWS Clue 에서 테이블 속성을 보면 S3 저장소와 연결되어 있지 않다.

왜 그럴까?

파티션 프로젝션을 연결할때에는 S3 저장소에 저장된 위치는 물론이고 S3 에 저장된 값의 속성도 지정해 줘야 한다. 대표적인 것이 다음과 같은 것이다.

  • Row format delimited
  • Stored as inputformat
  • outputformat

파티션 프로젝션 없이 테이블을 생성할때에는 이 옵션을 지정해 주지 않았다. 그러면 Default 값이 지정되는데, 대부분 잘 맞는 것이였다.

하지만, 파티션 프로젝션을 할 경우에 속성들을 지정해주지 않으면 아무것도 안된다. 다음과 같이 파티션 프로젝션 테이블을 생성해준다.

VPC Flow Log 파티션 프로젝션 생성
PgSQL
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
CREATE EXTERNAL TABLE `vpc_flow_logs_prj`(
  `version` int,
  `account_id` string,
  `interface_id` string,
  `srcaddr` string,
  `dstaddr` string,
  `srcport` int,
  `dstport` int,
  `protocol` bigint,
  `packets` bigint,
  `bytes` bigint,
  `start` bigint,
  `end` bigint,
  `action` string,
  `log_status` string)
PARTITIONED BY (
  `day` string)
ROW FORMAT DELIMITED
  FIELDS TERMINATED BY ' '
STORED AS INPUTFORMAT
  'org.apache.hadoop.mapred.TextInputFormat'
OUTPUTFORMAT
  'org.apache.hadoop.hive.ql.io.HiveIgnoreKeyTextOutputFormat'
LOCATION
  's3://flow-log-buckets/AWSLogs/111112222223333/vpcflowlogs/ap-northeast-2'
TBLPROPERTIES (
  'skip.header.line.count'='1',
  'projection.enabled'='true',
    'projection.day.type' = 'date',
    'projection.day.range' = '2022/08/23,NOW',
    'projection.day.format' = 'yyyy/MM/dd',
    'projection.day.interval' = '1',
    'projection.day.interval.unit' = 'DAYS',
  'storage.location.template'='s3://flow-log-buckets/AWSLogs/111111222222333333/vpcflowlogs/ap-northeast-2/${day}/'
  )

위와같이 할 경우에 파티션 프로젝션 테이블이 잘 생성된다. 이렇게 생성하고 난 후에 AWS Glue 에서 테이블의 속성을 보게 되면 정상적으로 S3 버킷과 연결이 되어 있고 각종 속성들이 설정되어 있는 것을 볼 수 있다.

AWS Athena 로 VPC Flow Log 분석하기 – 1

AWS Athena 는 로그 분석 서비스로 Hive 와 같다. 가장 많이 쓰이는 부분이 VPC Flow Log 를 분석하는데에 Athena 를 이용하는 방법이다. 이 글에서는 어떻게 VPC Flow Log 를 Athena 를 통해서 분석하는 알아 본다.

VPC Flow Log 설정

VPC Flow Log 설정은 간단하다. VPC 에서 Flow logs 탭에서 설정하면 그만인데, 다음과 같은 파라메터를 필요로 한다.

  • Destination Type: S3
  • Destination Name: S3 로 지정했을 시에 S3 Bucket 이름.
  • Log record format: AWS default format
  • Log file format: Text (default)
  • Partition logs by time: Every 24 hours (default)

여기서 중요한 것은 밑에서 3가지 정도다. Log record format 을 바꿀 경우에 Athena 테이블 생성시에 맞춰야 한다. Partition logs by time 을 24 시간으로 하면 S3 버킷 안에서 2022/08/29 형식으로 폴더가 생성되면서 VPC 로그가 전송 된다. 하루에 한번 폴더를 생성하면서 로그가 쌓인다는 뜻이다. 만일 Every 1 hours (60 minutes) 으로 할 경우에 2022/08/29/09 폴더가 생성되면서 로그가 쌓인다. 이 폴더의 구조는 나중에 Athena 에서 파티션 프포젝션(Partition Projection) 을 설정할때에 참고하게 된다.

또, S3 버킷으로 전송할 경우에 S3 의 암호화를 SSE_S3 로 할 것을 권장한다. CMK 로 할 경우에 로그가 쌓이지 않을 가능성이 있다. 또, 향후에 권한지정에서 CMK 권한을 함께 줘야하는 복잡함이 있을 수 있다.

S3 버킷 확인

필자의 VPC Log 설정으로 인해서 S3 에는 다음과 같은 형태로 S3 에 로그가 쌓이고 있다.

버킷 이름만 지정해주면 그 안에 AWSLogs/계정ID/vpclfowlogs/ap-northeast-2/ 가 자동으로 생성되며 그 안으로 year/month/day 순으로 생성된다.

앞에서 VPC Flow Logs 설정할때에 Partition logs by time 에서 Every 24 hours (default) 로 지정했기 때문에 날짜별로 생성된다.

Athena 작업

작업그룹(Workgroups) 생성

먼저 Athena 에서 필요한 것이 작업그룹(Workgroups) 이다. 기본적으로 Primary 가 기본 생성되어 있지만 하나 생성한다. 생성할때에 필요한 것은 다음과 같다.

쿼리 결과를 받을 S3 를 지정해야 한다. 만일 암호화가 필요하다면 SSE_S3 를 권장한다. CMK 도 가능하지만 Role 설정을 잘 해줘야 한다.

데이터 사용량을 적절하게 조절해 주길 권장한다. 덮어놓고 좋다고 No limit 로 하는 순간 돈이 술술 나갈 것이다. 이 데이터 사용량은 얼마든지 설정을 변경할 수 있다.

Database 생성

Query Editor 로 이동해 화면 오른쪽 상단에서 앞에서 생성한 작업그룹(Workgroup) 으로 변경해 준다.

그러면 Workgroup 이 변경 된다. 이제 다음과 같이 Database 를 생성해 준다.

Create Database vpcflowlogs
PgSQL
1
CREATE DATABASE vpcflowlogs

위 쿼리문은 화면안에 쿼리입력창에 입력하고 ‘Run’ 을 클릭해주면 된다.

이렇게 하면 데이터베이스가 생성이 된다. 그리고 왼쪽에 Database 부분에서 새로 생성한 데이터베이스를 선택해 준다.

위와같은 상태가 된다면 이제 테이블을 생성해야 한다.

Table 생성

이제 Table 을 생성해야 한다. 테이블을 생성할때에 중요한 것이 VPC Flow Log 의 S3 저장소와 데이터 컬럼들이다. 다음과 같다.

Create Table
PgSQL
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
CREATE EXTERNAL TABLE IF NOT EXISTS `vpc_flow_logs`(
    `version` int,
    `account_id` string,
    `interface_id` string,
    `srcaddr` string,
    `dstaddr` string,
    `srcport` int,
    `dstport` int,
    `protocol` bigint,
    `packets` bigint,
    `bytes` bigint,
    `start` bigint,
    `end` bigint,
    `action` string,
    `log_status` string
)
PARTITIONED BY (`date` date)
ROW FORMAT DELIMITED
FIELDS TERMINATED BY ' '
LOCATION 's3://flow-log-buckets/AWSLogs/1111122222233333/vpcflowlogs/ap-northeast-2/'
TBLPROPERTIES("skip.header.line.count"="1")

테이블을 생성할때에 컬럼을 지정해 줘야 하는데, VPC Flow Log 설정할때에 record format 을 AWS Default Format 을 지정했는데, 그 포맷은 위와 같다. 이 컬럼들은 S3 에 저장된 파일을 열었을 때에 맨 처음 나오는 행에 컬럼헤더 값들이다. 정확히는 ‘_’ 가 ‘-‘ 로 보면 정확하다. Athena 테이블은 ‘-‘ 를 ‘_’ 로 변환된다.

중요한 것은 Partitioned BY 부분에 date 부분이다. 테이블을 파티셔닝을 하기 위한 기준이 되는 컬럼을 추가하는 것이다. 이 파티션 컬럼은 S3 에 저장되는 VPC Flow Log 에는 없는데 파티셔닝 테이블을 생성할때에 이름처럼 생성된다.

위 쿼리문을 실행해 테이블을 생성한다.

파티션 생성

만일 파티션이 없다면 쿼리 시간이 길어진다. VPC Flow Log 의 경우 날짜로별로(yyyy/MM/dd) 쌓이는 것에 창안해 파티션을 날짜별로 생성하도록 할 것이다. 다음과 같이 파티션을 생성해준다.

Create Partition
PgSQL
1
2
3
ALTER TABLE vpc_flow_logs
ADD PARTITION (`date`='2022-08-29')
LOCATION 's3://flow-log-buckets/AWSLogs/1111122222233333/vpcflowlogs/ap-northeast-2/2022/08/29';

이렇게 하면 2022/08/29 에 해당하는 버킷에 내용이 파티션으로 입력 된다.

파티션을 이용하면 데이터 조회시에 그 범위가 줄어든다. 정확하게는 데이터 스캔(Data Scan) 범위를 줄일 수 있어서 쿼리 속도를 높여줄 뿐만 아니라 스캔 범위가 줄어들기 때문에 데이터를 긁어오는 양도 줄게되어서 비용을 아낄 수 있다.

앞에서 만든 테이블의 경우 date 컬럼은 date 테이터 타입임으로 다음과 같은 쿼리가 가능하다.

date 범위 쿼리
PgSQL
1
SELECT * FROM vpc_flow_logs WHERE 'date' > DATE('2022-08-28') - interval 1 day and 'date' < DATE('2022-08-28') ORDER BY start DESC LIMIT 10

date 타입이기 때문에 문자열을 date 타입으로 해줘야 한다.

파티션 생성 문제

파티션을 생성하면 문제가 하나 있다. 날짜별로 하나하나 다 생성해 줘야 한다. 시간은 흐르고 날짜는 변경될 것이다. 내일이 되면 다른 날짜로 S3 에 폴더가 만들어지고 거기에 데이터가 쌓일 것이다. 그러면 Athena 에서 그 날짜에 맞는 S3 저장소의 파티션을 생성해줘야 한다.

매일매일 하루에 한번 이것을 해야 한다고 생각하면 힘들다.

이것을 자동으로 하는 방법은 존재한다. Lambda 를 이용하는 것이다.

Lambda 작성하기

Lambda 실행을 위한 Role 생성

Lambda 를 작성해 자동으로 매일매일 하루에 한번 파티션을 생성하도록 해보자. Lambda 를 실행하기 위해서는 먼저 Lambda 실행을 위한 Role 이 필요하다.

Create Roles
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
## Role Name: ServiceRoleForVPCFlowLogsAthenaIntegrated
# Trust Relationships
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "Service": "lambda.amazonaws.com"
            },
            "Action": "sts:AssumeRole"
        }
    ]
}
# Inline Policy: VPCFlowLogsAthenaIntegrationLambdaExecutorPolicy
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "VisualEditor0",
            "Effect": "Allow",
            "Action": [
                "s3:GetObject",
                "s3:PutObject",
                "s3:ListBucketMultipartUploads",
                "s3:PutBucketPublicAccessBlock",
                "s3:AbortMultipartUpload",
                "s3:CreateBucket",
                "s3:GetBucketLocation",
                "s3:ListMultipartUploadParts"
            ],
            "Resource": [
                "arn:aws:s3:::athena-query-result/*",
                "arn:aws:s3:::athena-query-result"
            ]
        },
        {
            "Sid": "VisualEditor1",
            "Effect": "Allow",
            "Action": [
                "s3:GetObject"
            ],
            "Resource": [
                "arn:aws:s3:::flow-log-buckets/*",
                "arn:aws:s3:::flow-log-buckets"
            ]
        },
        {
            "Sid": "VisualEditor2",
            "Effect": "Allow",
            "Action": [
                "athena:StartQueryExecution",
                "athena:GetQueryExecution",
                "athena:GetQueryResults"
            ],
            "Resource": [
                "arn:aws:athena:ap-northeast-2:111111222222333333:workgroup/*"
            ]
        },
        {
            "Sid": "VisualEditor3",
            "Effect": "Allow",
            "Action": [
                "logs:CreateLogStream",
                "glue:GetPartition",
                "s3:ListAllMyBuckets",
                "s3:ListBucket",
                "glue:CreatePartition",
                "s3:GetBucketLocation",
                "logs:CreateLogGroup",
                "logs:PutLogEvents",
                "glue:UpdatePartition",
                "glue:GetTable",
                "glue:GetDatabase",
                "glue:BatchCreatePartition"
            ],
            "Resource": "*"
        }
    ]
}

Lambda 실행을 위한 Role 을 위와같이 생성해 준다.

Lambda 생성

Lambda 는 여러가지 언어로 작성될 수 있는데, 여기서는 Python 을 이용했다.

python 람다 함수
Python
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
# Lambda Name: aws-athena-vpc-flow-log-Partitioner
import boto3
import datetime
import logging
import time
import re
 
# setup simple logging for INFO
logger = logging.getLogger()
logger.setLevel(logging.INFO)
 
# setup variables
athena_workgroup = "athena-vpc-flow-log"
catalog_database = "vpcflowlogs"
flowlog_bucket="flow-log-buckets"
account_id = "111112222233333"
flowlog_table = "vpc_flow_logs"
 
# define the connection
athena = boto3.client('athena','ap-northeast-2')
 
def lambda_handler(event, context):
 
    today = datetime.datetime.utcnow()
    #today += datetime.timedelta(hours=10) # Convert KST
    logger.info('Today: {}'.format(today))
 
    year = today.strftime("%Y")
    month = today.strftime("%m")
    day  = today.strftime("%d")
 
    ############################################################################
    #  VPC Flow Log Catalog 테이블 파티션 갱신
    ############################################################################
    query = """
                ALTER TABLE {}
                ADD PARTITION (`date`='{}-{}-{}')
                LOCATION 's3://{}/AWSLogs/{}/vpcflowlogs/ap-northeast-2/{}/{}/{}'
            """.format(flowlog_table, year, month, day, flowlog_bucket, account_id, year, month, day)
    logger.info("Query: {}".format(query))
 
    response = athena.start_query_execution( QueryString=query,
                                             QueryExecutionContext={
                                                 'Catalog': 'AwsDataCatalog',
                                                 'Database': catalog_database
                                             },
                                             WorkGroup=athena_workgroup,
                                             ResultConfiguration={
                                                 'OutputLocation': 's3://aws-athena-query-result/',
                                                 'EncryptionConfiguration': {
                                                     'EncryptionOption': 'SSE_S3'
                                                 }
 
                                             }
                                        )
    query_execution_id = response['QueryExecutionId']
    logger.info('CodeIssue PRD Execution ID: {}'.format(query_execution_id))
 
    time.sleep(10)
 
    state = 'RUNNING'
    max_execution = 5
    while (max_execution > 0 and state in ['RUNNING', 'QUEUED']):
        max_execution = max_execution -1
 
        results = athena.get_query_execution(QueryExecutionId = query_execution_id)
        if 'QueryExecution' in results and \
                'Status' in results['QueryExecution'] and \
                'State' in results['QueryExecution']['Status']:
            state = results['QueryExecution']['Status']['State']
            if state == 'FAILED':
                logger.info("Query Result Failed: {}".format(results))
            elif state == 'SUCCEEDED':
                s3_path = results['QueryExecution']['ResultConfiguration']['OutputLocation']
                filename = re.findall('.*\/(.*)', s3_path)[0]
                logger.info("Query Result S3: {}".format(filename))
                break
 
        time.sleep(1)

Lambda 를 실행하는 Roles 는 앞에서 작성한 Roles 를 지정해 준다.

EventBridge Rule 생성

EventBridge 에서 Rule 를 생성해 매일 자정 0시 0분에 람다를 실행하도록 설정해 준다.

KST 를 위한 Athena 테이블 View 생성

Athena 에 vpc_flow_logs 테이블에 start, end 컬럼은 unixtime 이지만 UTC 기반이다. 이것을 KST 기반으로 보기 위해서는 연산이 필요한데, 그것을 아예 View 만들어 놓으면 좋다.

vpc_flow_logs View 생성
PgSQL
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
CREATE VIEW vpc_flow_logs_kst AS
SELECT
  "version"
, "account_id"
, "interface_id"
, "srcaddr"
, "dstaddr"
, "srcport"
, "dstport"
, "protocol"
, "packets"
, "bytes"
, ("from_unixtime"("start") + INTERVAL  '9' HOUR) "start"
, ("from_unixtime"("end") + INTERVAL  '9' HOUR) "end"
, "action"
, "log_status"
, "date"
FROM
  vpc_flow_logs

이제는 vpc_flow_logs_kst 뷰(view) 에 질의를 하면 start, end 컬럼의 데이터가 KST 시간으로 표신된다.

결론

지금까지 VPC Flow Log 생성에서부터 Athena 를 이용하는 방법, 더 나가 자동으로 파티션을 생성하도록 Lambda 까지 작성해봤다.

하지만, Lambda 작성도 필요없는 방법이 있다. 파티션 프로젝션(Partition Projection) 이라고 불리는 방법인데, 이것은 처음 테이블을 생성할때에 S3 의 날짜 폴더 구조를 기반으로 자동으로 파티션을 인식시키는 방법이다. 이렇게 하면 Lambda 를 이용해 파티션을 수동으로 생성해줄 필요가 없게된다.

Spring Boot, error: constructor … in class .. cannot be applied to given types 오류

Spring Boot 로 프로그램을 작성하고 난 후에 Compile 단계에서 다음과 같은 오류를 만날 수 있다.

Spring Boot 오류
ZSH
1
2
3
4
5
6
EmployeeServiceImpl.java:13: error: constructor Employee in class Employee cannot be applied to given types;
                return Mono.just(new Employee(empId, "emp1", "manager", 3000));
                                 ^
  required: no arguments
  found: Long,String,String,int
  reason: actual and formal argument lists differ in length

에러 코드를 보면 new 연산자를 이용해 Employee 객체를 생성하는 부분인데, 이부분이 문제가 된다는 것이다. required: no arguments 라고 나오지만 Employee 는 다음과 같이 되어 있다.

Employee 클래스
Java
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
package local.systemv.springboot.test.apps.model;
 
import lombok.AllArgsConstructor;
import lombok.Getter;
import lombok.Setter;
 
@AllArgsConstructor
@Getter
@Setter
public class Employee {
 
private Long empId;
private String name;
private String description;
private double salary;
}

@AllArgsConstructor 어노테이션을 줘서 자동으로 모든 객첵 멤버변수를 인자로 받는 컨스트럭터를 생성하도록 하고 했다. 이것은 Lombok 을 이용한 것으로 다음과 같이 gradle 에서 의존성을 줬다.

gradle 상태
INI
1
compileOnly group: 'org.projectlombok', name: 'lombok', version: '1.18.16'

문제는 Eclipse 나 IDE 툴에서는 SpringBoot 애플리케이션이 잘만 실행되지만 정작 컴파일을 할려고 하면 위와같은 오류가 나오는다는 것이다. 아무리 봐도 소스코드상에서는 아무런 문제가 없는데도 이런다면 다음과 같이 gradle 에서 annotationProcessor 를 추가해주면 된다.

gradle 상태
INI
1
2
compileOnly group: 'org.projectlombok', name: 'lombok', version: '1.18.16'
annotationProcessor 'org.projectlombok:lombok'

Maven 을 사용할 경우에는 아무런 문제가 없었지만, Gradle 을 사용하면서 Lombok 을 사용한다면 반드시 annotationProcessor 를 추가해줘야 한다.

IntelliJ 에서는 설정에서 “Enabling Annotation Processing” 체크하면 된다.

컨테이너에서 Java 힙 덤프 뜨기

Kubernetes 에서 Java 애플리케이션을 운영할때에, Java 힙 덤프를 떠야하는 경우가 있다. 하지만 다음과 같이 덤프를 떠지지 않는다.

Kubernetes 에서 Java 힙 덤프
ZSH
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
$ kubectl exec -it employee-consumer-68cfc9864-kgx4w -- sh
/ # ps aux
PID   USER     TIME  COMMAND
    1 root      3:01 java -XX:+UseG1GC -XX:+UseStringDeduplication -XX:MetaspaceSize=128M -XX:MaxMetaspaceSize=128M -Djava.security.egd=file:/dev/./urandom -jar /app/employee-consumer.jar --spring.active.profile=${SPRING_PROFILES_ACTIVE}
   57 root      0:00 sh
   63 root      0:00 ps aux
/ # jcmd 1 VM.flags
1:
com.sun.tools.attach.AttachNotSupportedException: Unable to get pid of LinuxThreads manager thread
        at sun.tools.attach.LinuxVirtualMachine.<init>(LinuxVirtualMachine.java:86)
        at sun.tools.attach.LinuxAttachProvider.attachVirtualMachine(LinuxAttachProvider.java:63)
        at com.sun.tools.attach.VirtualMachine.attach(VirtualMachine.java:208)
        at sun.tools.jcmd.JCmd.executeCommandForPid(JCmd.java:147)
        at sun.tools.jcmd.JCmd.main(JCmd.java:131)
/ #
</init>

“Unable to get pid of LinuxThread manager thread” 오류가 발생한다.

이 오류가 나오는 이유는 Java 애플리케이션의 Pid 값이 1이기 때문이다. 이를 해결하는 방법을 소개한다.

Container 이미지에 tini 설치, 배포

먼저 Openjdk 의 컨테이너 이미지에 tini 프로그램을 설치해야 한다. 이 tini 라는 프로그램은 인자값을 받은 프로그램을 실행 시켜 준다. 이렇게 하면 tini 는 Pid 1을 가지지만 tini 가 실행시킨 프로그램은 1보다 큰 Pid 값을 가지게 된다.

문제는 Openjdk 에 tini 라는 프로그램이 없다. 더군다나 아무 컨테이너 이미지에 이것을 설치할 수 있는게 아니라 Alpine 기반 이미지에서 쉽게 설치가 가능하다. Alpine 에서는 패키지로 제공하기 때문에 명령어로 간단하게 설치할 수 있다.

Dockerfile 을 다음과 같이 수정한다.

Kubernetes 에서 Java 힙 덤프
diff
1
2
3
4
5
6
7
8
9
FROM openjdk:8-jdk-alpine
+ RUN apk add --no-cache tini
RUN mkdir -p /app
ARG JAR_FILE=target/*.jar
COPY ${JAR_FILE} /app/employee-consumer.jar
ENV SPRING_PROFILES_ACTIVE=kubernetes
 
- ENTRYPOINT ["java","-XX:+UseG1GC", "-XX:+UseStringDeduplication", "-XX:MetaspaceSize=128M", "-XX:MaxMetaspaceSize=128M", "-Djava.security.egd=file:/dev/./urandom","-jar","/app/employee-consumer.jar","--spring.active.profile=${SPRING_PROFILES_ACTIVE}"]
+ ENTRYPOINT ["/sbin/tini", "--", "java","-XX:+UseG1GC", "-XX:+UseStringDeduplication", "-XX:MetaspaceSize=128M", "-XX:MaxMetaspaceSize=128M", "-Djava.security.egd=file:/dev/./urandom","-jar","/app/employee-consumer.jar","--spring.active.profile=${SPRING_PROFILES_ACTIVE}"]

apk 명령어를 이용해 tini 를 설치해주고 ENTRYPOINT 에 실행 명령어에 tini 를 넣고 인자값으로 java 애플리케이션 명령어를 넣는다.

이렇게 컨테이너 이미지를 제작하고 배포를 한다.

tini 프로그램 이 후 Pid

tini 프로그램으로 Java 애플리케이션이 어떻게 실행되는 다음과 같이 확인 할 수 있다.

tini 로 실행되는 java 애플리케이션
ZSH
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
$ kubectl exec -it employee-consumer-cbfc7c94b-t65sz -- sh
/ # ps aux
PID   USER     TIME  COMMAND
    1 root      0:00 /sbin/tini -- java -XX:+UseG1GC -XX:+UseStringDeduplication -XX:MetaspaceSize=128M -XX:MaxMetaspaceSize=128M -Djava.security.egd=file:/dev/./urandom -jar /app/employee-consumer.jar --spring.active.profile=${SPRING_PROFILES_ACTIVE}
    7 root      1:04 java -XX:+UseG1GC -XX:+UseStringDeduplication -XX:MetaspaceSize=128M -XX:MaxMetaspaceSize=128M -Djava.security.egd=file:/dev/./urandom -jar /app/employee-consumer.jar --spring.active.profile=${SPRING_PROFILES_ACTIVE}
   56 root      0:00 sh
   63 root      0:00 ps aux
/ # jcmd 7 GC.heap_info
7:
garbage-first heap   total 162816K, used 62180K [0x00000000f0000000, 0x00000000f01004f8, 0x0000000100000000)
  region size 1024K, 11 young (11264K), 10 survivors (10240K)
Metaspace       used 53386K, capacity 56950K, committed 57216K, reserved 1099776K
  class space    used 6277K, capacity 6935K, committed 7040K, reserved 1048576K
/ # jcmd 7 VM.flags
7:
-XX:CICompilerCount=2 -XX:CompressedClassSpaceSize=125829120 -XX:ConcGCThreads=1 -XX:G1HeapRegionSize=1048576 -XX:InitialHeapSize=16777216 -XX:MarkStackSize=4194304 -XX:MaxHeapSize=268435456 -XX:MaxMetaspaceSize=134217728 -XX:MaxNewSize=160432128 -XX:MetaspaceSize=134217728 -XX:MinHeapDeltaBytes=1048576 -XX:+UseCompressedClassPointers -XX:+UseCompressedOops -XX:+UseG1GC -XX:+UseStringDeduplication

jcmd 뿐만 아니라 jstat, jmap 등 모든 명령어를 사용할 수 있다.

mod_jk, SEVERE: Invalid message received with signature 해결

Apache 2.4 에 mod_jk 를 설치하고 Tomcat 9 와 AJP 연결 설정을 했다. 그런데, 어찌된 영문인지 AJP 연결이 되지 않으면서 다음과 같은 에러 메시지만 나왔다.

mod_jk 에러 메시지
ZSH
1
invalid message received with signature

mod_jk 설정과 Tomcat 9 의 연결 설정은 아무런 문제가 없음에도 이런 오류가 발생하는 이유를 몰랐는데, 문제는 아주 단순했다.

address=”::1″

Tomcat 9 의 서버 설정인 server.xml 에 ajp 설정은 다음과 같다.

server.xml 에 ajp 설정 부분
XHTML
1
2
<connector protocol="AJP/1.3" address="::1" port="8009" redirectport="8443">
</connector>

기본 설정값으로, address 에 할당된 값이 문제가 된다. address 에 값을 “0.0.0.0” 으로 바꾸던지 아니면 서버 IP 주소로 변경해 주면 된다.

secret=””

Tomat 9 에서 AJP 연결에서 주의해야 할 것이 secret 이다. 변경사항이기도 한데, ‘secretRequired=true’ 가 기본값으로 설정되어 있어 secret 값을 줘야 한다. 이것은 AJP 연결을 하기 위한 일종의 키값으로 mod_jk 설정에서도 해줘야 한다.

mod_jk 설정과 server.xml 에 ajp 설정 부분
XHTML
1
2
3
4
5
# mod_jk 설정
worker.instance1.secret={e@xFFTt37)%({-;
# tomcat 9 설정
<connector protocol="AJP/1.3" address="192.168.96.19" port="8009" secret="{e@xFFTt37)%({-;" redirectport="8443">
</connector>

위와같이 secret 값이 일치해야지만 연결이 된다.

강남의 MSP 회사들이 IT를 망치고 있다

강남에 MSP 회사들이 많이 있다. Managed Service Provider 라고, 리셀러 개념이라고 하기에는 좀 애매하지만 그외 비슷한 회사들이라고 보면 된다.

아무래도 많은 회사들이 이 MSP 에 기술지원을 받기를 원한다. 왜냐하면 트렌드 자체가 그렇게 흘러가고 있고 이들에 대한 수요가 많다보니 MSP 에 대한 기대가 있는 것이다. 문제는 이러한 회사들이 썩 좋은 방법으로 사업을 영위하고 있지 않다는데 있다.

위험의 외주화.

우리 사회에서 지난 몇년간 나왔던 말들이 ‘위험의 외주화’ 이다. 원청이 위험성이 높은 일에 대해서 외주를 주어 그와 관련된 법망과 사회적, 도덕적 책임을 회피하는 수단으로서 계약을 하는 형태… 그래서 원청에 대한 처벌을 강화해야 한다는 것이 ‘중대재해보호법’ 의 요체다.

이 위험이라는 단어가 가지는 의미는 매우 다양하다. 제조업의 경우에, 특히나 뉴스에 보도되는 경우에는 대부분 제조업이 많이 나오는데 목숨일 잃는 경우이지만 IT 의 경우에는 그야말로 프로젝트의 위험요소를 말한다.

A 라는 회사가 Cloud 로 전환 작업을 위해서 MSP 에 프로젝트를 위임하게 된다. A 라는 회사는 당연히 전문적인 식견과 인력으로 전문스러운 뭔가를 기대할 게 당연한 것이다. 하지만 MSP 회사에서는 사람을 또 뽑는다.

니들의 PL 을 알아?

Project Leader. 많은 프로젝트를 경험하면서 느낀 거지만 PL 은 아무나 해서는 안된다. PM 의 경우에는 꼭 반드시 어떤 기술적인 능력을 기대하지는 않는다. 그냥 대충 IT 에 몸을 담았던 사람정도면 그만이다. 일종의 말이 통하는 사람 정도이면 그만이다. PM 의 경우에는 프로젝트 자체의 비지니스에 대한 처리를 많이 하기 때문에 실제로 구현되어지는 프로젝트의 기술적인 부분까지 신경쓰기는 사실상 힘들다. 고객과의 협상도 PM 이 하는 일이기 때문에 PM 이 사실상 피곤한 직위에 속한다.

하지만 PL 은 이야기가 달리진다. PL 은 프로젝트에 대한 기술적인 이해가 반드시 있어야 한다. 문제는 이 프로젝트에 대한 기술적인 이해라는 것이 반드시 ‘기술’ 만 이해한다고 되는게 아니다. 이 기술들이 전체적인 요구사항에 잘 조합되어지고 있는지에 대한 사항들을 주로 살펴야 하는게 PL 이다. 예를들어, 숲에 나무를 가지고 하트모양을 만든다고 할 경우에, 나무에 대해서 알 필요는 없지만 그렇다고 몰라서도 안되고 그 나무들이 하트모양이 되도록 잘 정리 정돈이 되고 있는지 조성하는 과정에서 잘 살펴야 한다.

기술적인 내용을 세세하게 알 필요는 없지만 큰 틀에서 숲을 볼 줄 알아야, 그 숲이라는게 숲을 구성하는 각 요소들이 있기 때문에 그걸 알고 있어야 한다, 프로젝트가 잘 굴러가게 되어 있다.

PM 도 프로젝트의 승부를 가르는 결정적인 인물이라면, PL 도 실체적인 프로젝트의 승패를 가르는 인물이기도 하다. 그만큼 책임이 매우 크다는 것이다. 프로젝트에 책임에서 벗어날 수 없는 인물들이 PM, PL 이다.

그런데, 강남에 MSP 회사들은 PL 을 프리랜서로 뽑고 있다. 프리랜서가 PL 을 못한다는 이야기가 아니다. 앞에서 이야기했듯이 프로젝트를 책임질 인물이기 때문에 어찌보면 고객사 A 에 대한 예의가 아닌 거다. 자본주의 사회에서 거래계약이란게 뭐든 못할까 만은 적어도 프로젝트를 책임질 회사가 직접 나서는게 아니라 PL 을 프리랜서에게 위임한다는게 과연 정당하다고 볼 수 있나…

마치 제조업에서 위험의 외주화 정도는 아닐지라도 도의적이나 도덕적으로 별로 바른 경우는 아니다.

내 손에 피는 안 묶힌다.

왜 PL 을 프리랜서들에게 맡길려고 하는 걸까? 그들이 보기에, 한눈에 봐도 프리랜서에게 PL 을 맡기는 건 문제가 있다는 인식은 다 깔려 있다. 그런데도 이렇게 하는 이유는 다음과 같다.

‘고상한 척’ 가면놀이

강남의 MSP 회사의 경우 외주 프리랜서들을 직접 뽑지 않는다. 2차 업체라고해서 그들이 프리랜서를 물고 온다. 대부분 잡코리아, 사람인에 공고를 내서 지원하는 사람들을 대리고 오는데, 면접을 MSP 에서 보게 된다.

MSP 에 협력 업체도 인맥이지만, MSP 에서 수주하는 많은 프로젝트들 또한 인맥인 경우도 많다. 그렇지 않은 경우도 있지만 워낙 강남의 이름있는 MSP 하면 몇개 없기 때문에 업계에서도 알아서 찾아오는 경우도 있지만 그런 경우는 많지 않다.

대부분 A 업체 프로젝트 담당자와 MSP 담당자들은 대부분 인맥이 있거나 한 경우이다 보니, 서로 얼굴을 붉히는 일은 피할려고 하는 경향이 있다. 회사 생활을 하다보면 직위가 높을수록 어떤 문제에 직접 나서는걸 회피하는 경향을 보이는데, 복잡하고 스트레스가 심한 어떤 문제에 그 사람이 노출될 경우에 들어나는 인성과 능력을 무서워하는 경우가 아주 많다. 직위가 높으면 고상해지는 인간들이 대부분인 이유라고 보면 된다.

이 MSP 회사들도 마찬가지다. 프로젝트에 직접 관여하는 경우에 그런 ‘고상한 인품’ 을 유지하기가 상당히 힘든 경우다. 프로젝트를 직접 관리할 경우에 어떻게든 A 회사에게 싫은 소리도 해야하는 경우가 있고 직접 거의 매일매일 그 사람들과 이야기를 해야하는데 A 회사 사람들이 마냥 MSP 회사에 듣기좋은 소리만 할 경우는 많지 않다.

더군다나 A 회사와 인맥이라도 있는 날에는…. 힘든 일이 한두가지 아니게 된다.

‘우리는 고객사 편’

PL 를 하다보면 고객의 요구사항을 변경해야 하는 경우가 생긴다. 잘 모르니까 고객들은 어디서 주워들은 이야기를 가지고 해달라고 하는 경우도 부지기수다. 이럴 경우에 프리랜서라면 한계가 있기 때문에 수행사 MSP 회사에서 적극적으로 중재를 해야한다.

하지만 MSP 회사가 적극적으로 중재를 할려고 할까? 대부분 ‘PL 프리랜서’ 를 교체하는 방향으로 가닥을 잡는다. 심각한 건 프리랜서를 ‘능력없는 인간’, ‘성격이 안된 인간’ 쯤으로 평가하면서 교체를 한다는 문제다.

면접한번 보고 현장에 투입시키고는 그 사람들 다신 얼굴 볼 일도 생기지 않는데, 어떻게 해서 프리랜서에 저런 낙인을 찍을 권리가 생기는지?

문제가 있다는 것을 알면서도 그것을 프리랜서에 문제로 귀속시키고 교체, 그렇게 함으로써 고객의 요구사항을 변경시키는 일들을 하는 곳이 MSP 다. 그들에게는 그렇게 하는 것이 훨씬 편하니까… 프리랜서가 고객의 잘못된 요구사항에 대해서 중재를 요구하면 그건 능력이 없는 것이거나 ‘사업이란게 원래 그런건 줄 몰랐냐?’, ‘세상 덜 살았네… PL 할 인물이 못되네’ 식의 결론을 내리게 훨씬 쉽다.

이렇게 쉽게 생각하는 건 그렇게 해는 것이 너무나도 쉽고, 두번째는 프리랜서에 대한 인식이 그렇기 때문이다. 프리랜서는 본인들이 돈주고 산 사람이라는 인식이 있기 때문에 뭐든 시키면 다해야 한다는 사고를 하게 된다. 하지만 그렇지가 않지…

프리랜서의 권리는 의외로 막강하다. 하지만 그것을 주장할 경우에 계약해지를 종용하는데, 사실 다 위법한 것이지… 정당한 사유 없이 계약해지를 할 경우에 배상의무가 있다. 하지만 그런 인식이 없는 곳이 강남의 MSP 다.

사회변화는 고상하고 IT 도 제대로 안 굴러간다.

뉴스를 보면 사내에 성폭행 사건을 다루는 뉴스가 나온다. 그럴때마다 너도나도 가해자를 비난하면서 정의로운 글들을 많이 본다. 더군다나 회사측의 대응에 대해서 맹비난을 하곤 한다. 피해자편에 서서 대응을 했어야 했는데 그렇지 않고 피해자에게 ‘조용히 있어라’ 식의 대응을 했기 때문이겠지.

하지만 대부분의 한국사회가 대부분 부당함에 대해서 뭉쓰고, 모르쇠로 일관하는 일이 비일비재하다는 것쯤은 알아야 한다. 뉴스에 나오면 분노하면서도 정작 자신에게 혹은 자신과 관계된 주변에서 그런일이 발생할 경우에, 성폭력 피해자의 회사처럼 행동게 한국 사회 아니겠나..

강남의 MSP 회사들이 요즘 벌이는 일들이 이와 유사하다. 위험의 외주화는 물론이거니와 고객에게는 적어도 고상한 이미지를 구축해야하고 그러다보니 고객과의 마찰에 있어서 적극적인 중재를 하려고하지 않는다.

본인들은 고상해야 하고 적어도 피는 뭍히지 말아야 한다는 얄팥한 사고로 사람들을 뽑아대고 있으니…

제대로 된 인간들이 없다. 그져 인맥…… 그러니까 프로젝트 투입되서 보면 MSP 가 요구하는 그 엄청난 스펙에 비해 초보급 만도 못한애 구축된 아키텍쳐를 보게된다. 더 웃긴건 본인들이 구축했으니 잘 구축했다고까지 자랑질… 제 정신들이 아닌거지..

VIM lightline 플러그인

vim 을 사용할때에 필요한 것이 상태바(Status Bar) 다. 보통은 airline 을 많이 쓰는데, 여러가지 의존성이 필요해서 사용하기에 쉽지가 않다.

lightline 은 의존성이 복잡하지 않고 간단하게 사용할 수 있다. 다음과 같이 .vimrc 에 설정을해주면 된다.

.vimrc 설정
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
syntax on
set nocompatible
set hls
set scs
set visualbell
set softtabstop=4
set tabstop=4
set shiftwidth=4
set scs
set ai
set si
set ignorecase
set showmatch
filetype off
 
set t_Co=256
set fileencodings=utf-8
set termencoding=utf-8
set encoding=utf-8
 
set rtp+=~/.vim/bundle/Vundle.vim
call vundle#begin()
 
Plugin 'VundleVim/Vundle.vim'
"Plugin 'vim-airline/vim-airline'
"Plugin 'vim-airline/vim-airline-themes'
Plugin 'itchyny/lightline.vim'
Plugin 'stephpy/vim-yaml'
"Plugin 'pearofducks/ansible-vim'
Plugin 'chr4/nginx.vim'
 
call vundle#end()
filetype plugin indent on     " required!
 
" for vim-airline
"let g:airline#extensions#tabline#left_sep = ' '
"let g:airline#extensions#tabline#left_alt_sep = '|'
"let g:airline_theme='molokai'
 
let g:lightline = {
      \ 'colorscheme': 'solarized',
      \ 'active': {
      \   'left': [ [ 'mode', 'paste' ],
      \             [ 'gitbranch', 'readonly', 'filename', 'modified' ] ]
      \ },
      \ 'component_function': {
      \   'gitbranch': 'FugitiveHead'
      \ },
      \ }
 
set laststatus=2 " turn on bottom bar

t_Co=256 설정과 아래 두가지 부분의 설정이 핵심으로 보면 된다.

Elasticsearch 보안 – 인증서

Elasticsearch 가 버전이 높아짐에 따라 인증서에 대한 이해가 필요하게 되었다. 사실 이 인증서가 필요한 이유가 Elastic 에서 배포하는 X-Pack 중에 Security 플러그인 때문인데, 이 Security 를 활성화 하게 되면 TCP, HTTP 통신을 TLS 통신을 하도록 강제하고 있다.

문제는 Elasticsearch 자바 기반이며, 따라서 생성하는 파일이 여느 다른 인증서와는 다른 면도 있다. ‘다른 면도 있다’ 라고 표현한 이유는 일반적인 PEM 형식의 보안키와 인증서를 모두 지원하지만 여전히 자바 세계에서만 통용되는 방법을 여전히 고수하고 있기 때문이다.

keystore 파일

최신 버전의 Elasticsearch 7 을 설치하게 되면 /etc/elasticsearch/elasticsearch.keystore 파일 하나만 생성되게 된다.

이 파일은 key/value 형식으로 계정 정보가 들어가 있다. 이 내용을 적는 이유는 Java Keystore 파일과는 다르다는 것을 말하기 위함이다. Elasticsearch 을 설치하고 나서 Security 를 활성한 후에 계정에 대한 패스워드를 작성하는 절차를 밟는다.

패스워드 설정
ZSH
1
2
3
4
5
6
7
8
9
10
]# cd /usr/share/elasticsearch/
]# ./bin/elasticsearch-setup-passwords auto
Changed password for user apm_system
PASSWORD apm_system = 1QzJrrJ5DPaRJj7BOPRz
 
Changed password for user kibana
PASSWORD kibana = 8HlolrAt0Xoh2HMjUGds
 
Changed password for user logstash_system
PASSWORD logstash_system = fS6R6b42i7gq0oWX4SaA

계정에 대한 패스워드를 자동 생성하도록 한 것인데, 이렇게 생성된 내용들은 elasticsearch.keystore 파일에 key/value 형식으로 저장된다.

이렇게 저장된 key 값들은 elasticsearch-keystore 명령어를 통해서 볼 수 있다.

PKCS#12(확장자 p12) 파일

확장자가 p12 파일을 보게 된다. 이 파일은 PKCS#12 형식의 파일인데, 인증서와 개인키를 포함한 형태의 데이터 파일이다. Elasticsearch 7 에서는 루트 인증서(CA 인증서) 와 서버 인증서를 다음과 같이 제작해 사용 한다.

패스워드 설정
ZSH
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
]# cd /usr/share/elasticsearch
]# ./bin/elasticsearch-certutil ca --days 3650
If you elect to generate PEM format certificates (the -pem option), then the output will
be a zip file containing individual files for the CA certificate and private key
Please enter the desired output file [elastic-stack-ca.p12]:
Enter password for elastic-stack-ca.p12 :
 
]# cd /usr/share/elasticsearch
]# ./bin/elasticsearch-certutil cert --ca elastic-stack-ca.p12
Enter password for CA (elastic-stack-ca.p12) :
Please enter the desired output file [elastic-certificates.p12]:
Enter password for elastic-certificates.p12 :
Certificates written to /usr/share/elasticsearch/elastic-certificates.p12

elastic-stack-ca.p12 은 CA 인증서 인데, openssl 을 이용해서 PKCS12 파일을 읽어볼 수 있다.

lastic-stack-ca.p12 파일 내용
ZSH
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
]# openssl pkcs12 -info -nodes -in elastic-stack-ca.p12
Enter Import Password:
MAC: sha256, Iteration 10000
MAC length: 32, salt length: 20
PKCS7 Data
Shrouded Keybag: PBES2, PBKDF2, AES-256-CBC, Iteration 10000, PRF hmacWithSHA256
Bag Attributes
    friendlyName: ca
    localKeyID: 54 69 6D 65 20 31 36 34 38 33 38 38 32 37 34 39 31 30
Key Attributes: <No Attributes>
-----BEGIN PRIVATE KEY-----
MIIEvQIBADANBgkqhkiG9w0BAQEFAASCBKcwggSjAgEAAoIBAQDXNp3BI1YX2qxz
6h7svLAkTlSMitpZzgV5Dlk2ZTKzKcTExVVLvL0zvO5JJfFwfWePfNhZyIRXsDR8
SmwrRqr3uysAL9zyqSwvGpRZlPml0a4t8eEYHN9ewV5p2Xzur22ShAetJ2sQ/As9
0lsMEKX3A7LgpOEWMbBrapdcNWt5QAnOOlXnrwCvPmWnd5friQatmggS2/dmfw5V
2EeOQimShRncohtcj9ez80WclATIfkZx1x+m8bpFQVpnt94Rw1a58k4uy6/edL6W
6RJjJYa39PVgjaqNZNGfIAl2STDfQOyHbp6/3BZDmJjt8e0gGHhGKMw1SmuJRvE6
CAsu687tAgMBAAECggEADyX8Aq0/ERzGSL5xAM7jQxr0XpQjfHDA991nsCl9YRkO
jZ8qOtOFKdAhoap3DSj2kiYCgIdZsWZou1rttDocLKXTCAdWcQoxXvtq98dBr0dM
EFXXN0BJBL1trNuvLInSl56Nf8WnhqGHFQnqeLXvSKzM+X0BjvNebKErGEV2VClp
tUvP+5E9SnfJf/QBSrsoCaZkCSc08WNQL1iqubC95593DXImLYCR0MOQHWqVg+hW
6VZJrJhSGUivd5g3TxhGCmEXeYqaT5Vv2xMhLkKVVD4+kLw3C7rfiDrL24KdNeb0
qq8ZL6a/nEnILiS53G4kT2VU0eOo8GqyDdQc/LJzLQKBgQD0VFJejw3D174vAYyd
6EC9IeDz0BRi3LfTyufmqqjkNL/D4qqSQR49VUdiBjbKY3ObEkbRuws61eVJoJSS
lbhRrDEpuQE1R6e+QJWDKRbcXa8ONcJI/DAolgJ0DIfuyOLVu5IlIGe/KBCYxvUX
U8WUJlbFfbQgLzS3ZSMsvOOBWwKBgQDhfkLoV2WIVOp9JEC0DD9rvd3yC6jGZT+C
wtS84WiRioj5lOYTT1iOlhcc3BVBI0mqq3hioLRY1QoAclvLYlD96gIUf3FcjkS8
Yez9az0/s0F5V9A4q5ILXh2+y62So1EEHUkymkwJPtwpORWV+EakG7vQ7g6P8JhG
yddWmnbbVwKBgQC/lndYiphin4QUXASltf89z5kT1nCF7UmAnDUoHV5+RBazRcQ3
FzTdJ0foR7MjFMUMLlK2FxOBOUSobXDTWO/Fq16JtvaJjvysJPyYctnoRtYEMId+
r7IbwTV/Rmw5A/FLY9//mN+Bd6s8AZciiZ/+wel8x0s9iYau4HGqnRtQzQKBgCQm
xP1Q/bM0wf9cL49uI0DXyNyEaAOeuebx6394t/YVes5gw942q2D4yS3UTwgJa0cU
hJFzaFaRmS/nJbZexdNfkAPPRtJq8LQvEvqyFbi/uXCF1pkvUJPH/AbZyrMmwddi
Bpk5SZV14YAuabqIenLXC258rBMBpLg8pex5iTKzAoGAefpjvdwex4c3UevW6fuP
W8NtSKLVs4iIhUp6JSzYMptRktiLgs+KEQcXVz1/c34DqwPmngDZQx8P7g7o0DiS
/rYvjR3oj+5FLZS8JCo+Dbb7L9IHKCrnEl9VVIK38UH41TNyOmJHefnT7NeEOJP+
/c0LvaSM8Dg0CtqZP4M0hUc=
-----END PRIVATE KEY-----
PKCS7 Encrypted data: PBES2, PBKDF2, AES-256-CBC, Iteration 10000, PRF hmacWithSHA256
Certificate bag
Bag Attributes
    friendlyName: ca
    localKeyID: 54 69 6D 65 20 31 36 34 38 33 38 38 32 37 34 39 31 30
subject=CN = Elastic Certificate Tool Autogenerated CA
 
issuer=CN = Elastic Certificate Tool Autogenerated CA
 
-----BEGIN CERTIFICATE-----
MIIDSTCCAjGgAwIBAgIUEFAezZP+HRGBy2mNE4hIWTa8Oq8wDQYJKoZIhvcNAQEL
BQAwNDEyMDAGA1UEAxMpRWxhc3RpYyBDZXJ0aWZpY2F0ZSBUb29sIEF1dG9nZW5l
cmF0ZWQgQ0EwHhcNMjIwMzI3MTMzNzUzWhcNMzIwMzI0MTMzNzUzWjA0MTIwMAYD
VQQDEylFbGFzdGljIENlcnRpZmljYXRlIFRvb2wgQXV0b2dlbmVyYXRlZCBDQTCC
ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANc2ncEjVhfarHPqHuy8sCRO
VIyK2lnOBXkOWTZlMrMpxMTFVUu8vTO87kkl8XB9Z4982FnIhFewNHxKbCtGqve7
KwAv3PKpLC8alFmU+aXRri3x4Rgc317BXmnZfO6vbZKEB60naxD8Cz3SWwwQpfcD
suCk4RYxsGtql1w1a3lACc46VeevAK8+Zad3l+uJBq2aCBLb92Z/DlXYR45CKZKF
GdyiG1yP17PzRZyUBMh+RnHXH6bxukVBWme33hHDVrnyTi7Lr950vpbpEmMlhrf0
9WCNqo1k0Z8gCXZJMN9A7Idunr/cFkOYmO3x7SAYeEYozDVKa4lG8ToICy7rzu0C
AwEAAaNTMFEwHQYDVR0OBBYEFEf8Qo2RRA4G+mtv1ZFwvGHFAT3zMB8GA1UdIwQY
MBaAFEf8Qo2RRA4G+mtv1ZFwvGHFAT3zMA8GA1UdEwEB/wQFMAMBAf8wDQYJKoZI
hvcNAQELBQADggEBAHGFaYHdSRtZnAujnU2EILin0uACtXsaLPJGpT/U42wZFcIQ
RA0RV2eDa5aVxRY/Ir1BSH9e9vQDRXmOkGAA/5hUytZPkttoYex+tS7fZVkS5qPv
tPIVVa93BkQ6Ml8aUcbyhGTgwFbeGU2TWyBZAlPA753SZzBjnmH3mX+suh4Hy3Fd
cLuUnWdaEqEAOBq4DqEITrxBQL07OXhkengyYGj7OzfDGvogdwuNgfTDJGSo+0NW
RaATvyG0DEFHrcDE78RNvqvSwvOr20L+cSrniWz+22/swDh1JhhPQiUYx0+us+7P
cssV3qzHu/7I87trfV56QnNNv4z2OUslz6dztPw=
-----END CERTIFICATE-----

패스워드를 입력하지 않았기 때문에 패스워드 입력 문구에서는 그냥 Enter 를 치면 된다. 그러면 위와같이 Private Key, Certificate 내용이 나온다. Certificate 부분을 따로 때어내서 파일로 저장하고 Openssl 명령어를 이용해 인증서를 읽으면 다음과 같다.

lastic-stack-ca.p12 인증서 내용
ZSH
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
]# openssl x509 -text -in a.crt -noout
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            10:50:1e:cd:93:fe:1d:11:81:cb:69:8d:13:88:48:59:36:bc:3a:af
        Signature Algorithm: sha256WithRSAEncryption
        Issuer: CN = Elastic Certificate Tool Autogenerated CA
        Validity
            Not Before: Mar 27 13:37:53 2022 GMT
            Not After : Mar 24 13:37:53 2032 GMT
        Subject: CN = Elastic Certificate Tool Autogenerated CA
.............
        X509v3 extensions:
            X509v3 Subject Key Identifier:
                47:FC:42:8D:91:44:0E:06:FA:6B:6F:D5:91:70:BC:61:C5:01:3D:F3
            X509v3 Authority Key Identifier:
                keyid:47:FC:42:8D:91:44:0E:06:FA:6B:6F:D5:91:70:BC:61:C5:01:3D:F3
 
            X509v3 Basic Constraints: critical
                CA:TRUE
    Signature Algorithm: sha256WithRSAEncryption

CA:TRUE 라고 명백하게 나오고 있다.

그러면 CA 인증서를 가지고 만들어진 /usr/share/elasticsearch/elastic-certificates.p12 파일도 내용을 확인해 보자.

elastic-certificates.p12 인증서 내용
ZSH
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
]# openssl pkcs12 -info -nodes -in elastic-certificates.p12
Enter Import Password:
MAC: sha256, Iteration 10000
MAC length: 32, salt length: 20
PKCS7 Data
Shrouded Keybag: PBES2, PBKDF2, AES-256-CBC, Iteration 10000, PRF hmacWithSHA256
Bag Attributes
    friendlyName: instance
    localKeyID: 54 69 6D 65 20 31 36 34 38 33 38 38 37 36 38 38 31 38
Key Attributes: <No Attributes>
-----BEGIN PRIVATE KEY-----
MIIEvQIBADANBgkqhkiG9w0BAQEFAASCBKcwggSjAgEAAoIBAQCW5PK+nx1yvbR+
zvmQLdx/XlVuQAXBKDhbedWtaxp3FRHUKi+VHEuD14fiNeJFuLdvlxB3xdVO5uZ4
VQW8Z0floUPc5g2z09tIxsbYtpQoIH0EwFt3HrVF3gMOgLnagDV+ulpIHVKSJo9J
tma65HCAM0dOJ06bFtKJKvjMa1SLp3BneluVAQBqyzIKOFR0jNBK20pW53qyv1cX
c51PdpLjoXLszAycUZt0dlyOFDb8jwg4TeneNeOsHeQ8+Dm/AtDvzfpZToM9K3Er
IUtXvGiCXBArk8jDVAxk7kosoVc19tDvMVT7alF1XeIQCXi0a2LCGzOaHqq1+iEk
De7AvX4pAgMBAAECggEAR+bDpsKSGTU9Nzmv4JyB161fPwBB3bcpF6m4AIErJLhE
/Ri3ALHxZ9sBdHChqABrZECTB8ecq5LKGmfFKm/6afjMqgtzVw+qC4Uwhl6FvZMx
j1yLmPjofujaAwSiyvPRydfJolhamqrGF2VTkVW+J9CHdz2yrqMS4mq4EExKhpqg
2zGGuON49a/IIxvfD5aMBOnE8C8EYpqhQgJlwQ5ZUJGpJJ6V9k8/kvIwjlyjdCFg
B6/DAyRvFjA0519Z/yaeKONFFwJoZRB1o/eZ7R0HByO57V6OkeR93zjYkD46mEft
0IVdwZ5NLNCqoHPnCD23LI5yRjlf9gIlIYPastjL0wKBgQDGi3MXmQHBhuT2HB77
H0+cq8nSWr9zy5GNDdXrerijtdZ/Kw9Kw7oMzm67RSfbIm/a/4wEjIVB0mYD8GCd
5bZ+mBe+/OnttuNmSD9isnO0mZSFcijJpKbi8ccO1b5ZVfPGYXwOcheeKKoga95g
vibMVfTbo1uRz5OvPrinK52P0wKBgQDCj3i5xuY7V+w0E9+pKGa0lkL4qvaUB00a
9qlqRSWqCE8snQKRUR/RwLo0Cu1RxmIeBMgvkvjpvRkQAkEBgfrjSgW5fdoCAyhC
M0/GQCy4DlGHMtIvUoamvaS2/vf8uBbUXQuhnMFM8Fc1qmTqcHbJWiesSqjdAUE4
7drNECN4kwKBgQCsfOn4Tk1gPDkeN0ATGxinG/eycHRzvR8uVB7M/Uj7sTYwNNCM
O46fIZjByUre7gQPVoPmT85VaNyH/4Vwp+jsAmZe3oq8om7cpVer/yzWcba+WHdm
90ylTTeKg9di9XFbn8WPJz+tf9aNZClGEuzSCLs5NaqP+q5rSSpS0WmJUQKBgBHk
ddrH4uZ0OIG1ji0VTRSweOo7dr+4SCwBoSTnxQX1C6rzqYfJqR52FemxU4/gqadP
E0Xkw0VjoYlqW6YS2QrMBOjBHSpwNeSYqW52+mXW00KWtuOpOD7fU+WMXyv7lgXj
pK0xKEm2FJ8X034H57SuuNVMbGkes2vT2/pd0JVHAoGAPYagEKewTvmGyeJmgKip
yiR9EkrUEDYojnhxmVlX5tmhKDGle7v3janSBzFhi9TmdxNTJgbgMpXwYbLNTmXr
bazP5iBnY92ewz0q2ZlseLacW+Nk0OiOW7F5oXQNpWsM5WhMtzVmv+ziXzcHsVEZ
7nO7ClRZphJgPHMYFgO4QCI=
-----END PRIVATE KEY-----
PKCS7 Encrypted data: PBES2, PBKDF2, AES-256-CBC, Iteration 10000, PRF hmacWithSHA256
Certificate bag
Bag Attributes
    friendlyName: instance
    localKeyID: 54 69 6D 65 20 31 36 34 38 33 38 38 37 36 38 38 31 38
subject=CN = instance
 
issuer=CN = Elastic Certificate Tool Autogenerated CA
 
-----BEGIN CERTIFICATE-----
MIIDIzCCAgugAwIBAgIVAINRWc0x/M3gJc+8nmj/vzjUw29CMA0GCSqGSIb3DQEB
CwUAMDQxMjAwBgNVBAMTKUVsYXN0aWMgQ2VydGlmaWNhdGUgVG9vbCBBdXRvZ2Vu
ZXJhdGVkIENBMB4XDTIyMDMyNzEzNDYwN1oXDTI1MDMyNjEzNDYwN1owEzERMA8G
A1UEAxMIaW5zdGFuY2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCW
5PK+nx1yvbR+zvmQLdx/XlVuQAXBKDhbedWtaxp3FRHUKi+VHEuD14fiNeJFuLdv
lxB3xdVO5uZ4VQW8Z0floUPc5g2z09tIxsbYtpQoIH0EwFt3HrVF3gMOgLnagDV+
ulpIHVKSJo9Jtma65HCAM0dOJ06bFtKJKvjMa1SLp3BneluVAQBqyzIKOFR0jNBK
20pW53qyv1cXc51PdpLjoXLszAycUZt0dlyOFDb8jwg4TeneNeOsHeQ8+Dm/AtDv
zfpZToM9K3ErIUtXvGiCXBArk8jDVAxk7kosoVc19tDvMVT7alF1XeIQCXi0a2LC
GzOaHqq1+iEkDe7AvX4pAgMBAAGjTTBLMB0GA1UdDgQWBBQYiUKf9pN3pVQTXyC/
JMFT3MTthTAfBgNVHSMEGDAWgBRH/EKNkUQOBvprb9WRcLxhxQE98zAJBgNVHRME
AjAAMA0GCSqGSIb3DQEBCwUAA4IBAQDSKsLkcTLwJYxeAOfbONzGUb5dipJBVRMH
L7YIRWtozi5vG8yNlug+ISPy5rwS9RpjDyDHq+DVEX2JqLhEym11sAbEJb0cyVr3
z3bve4ut3HubIfdI51cq2c2Fa3uTCaha30qKR7WCYF1DkFg4bCAd0gK29/M6NUD/
vWmLj83PIhqsuxwnlW25bBgTES8kdIykScdQqKs3C+rN8trzMdahjSya1qrhJh32
kDOjZYM9gQ76+VY41FMwd/7ZEuX0swzymWHPTsba2IH1frbR3QLE4YyVtgjHlfk7
Du/tN1cuUs32N1N+C2fdDtDKfZlWts4e2bdQiV+iFRnoyuMuU2JN
-----END CERTIFICATE-----
Certificate bag
Bag Attributes
    friendlyName: ca
    2.16.840.1.113894.746875.1.1: <Unsupported tag 6>
subject=CN = Elastic Certificate Tool Autogenerated CA
 
issuer=CN = Elastic Certificate Tool Autogenerated CA
 
-----BEGIN CERTIFICATE-----
MIIDSTCCAjGgAwIBAgIUEFAezZP+HRGBy2mNE4hIWTa8Oq8wDQYJKoZIhvcNAQEL
BQAwNDEyMDAGA1UEAxMpRWxhc3RpYyBDZXJ0aWZpY2F0ZSBUb29sIEF1dG9nZW5l
cmF0ZWQgQ0EwHhcNMjIwMzI3MTMzNzUzWhcNMzIwMzI0MTMzNzUzWjA0MTIwMAYD
VQQDEylFbGFzdGljIENlcnRpZmljYXRlIFRvb2wgQXV0b2dlbmVyYXRlZCBDQTCC
ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANc2ncEjVhfarHPqHuy8sCRO
VIyK2lnOBXkOWTZlMrMpxMTFVUu8vTO87kkl8XB9Z4982FnIhFewNHxKbCtGqve7
KwAv3PKpLC8alFmU+aXRri3x4Rgc317BXmnZfO6vbZKEB60naxD8Cz3SWwwQpfcD
suCk4RYxsGtql1w1a3lACc46VeevAK8+Zad3l+uJBq2aCBLb92Z/DlXYR45CKZKF
GdyiG1yP17PzRZyUBMh+RnHXH6bxukVBWme33hHDVrnyTi7Lr950vpbpEmMlhrf0
9WCNqo1k0Z8gCXZJMN9A7Idunr/cFkOYmO3x7SAYeEYozDVKa4lG8ToICy7rzu0C
AwEAAaNTMFEwHQYDVR0OBBYEFEf8Qo2RRA4G+mtv1ZFwvGHFAT3zMB8GA1UdIwQY
MBaAFEf8Qo2RRA4G+mtv1ZFwvGHFAT3zMA8GA1UdEwEB/wQFMAMBAf8wDQYJKoZI
hvcNAQELBQADggEBAHGFaYHdSRtZnAujnU2EILin0uACtXsaLPJGpT/U42wZFcIQ
RA0RV2eDa5aVxRY/Ir1BSH9e9vQDRXmOkGAA/5hUytZPkttoYex+tS7fZVkS5qPv
tPIVVa93BkQ6Ml8aUcbyhGTgwFbeGU2TWyBZAlPA753SZzBjnmH3mX+suh4Hy3Fd
cLuUnWdaEqEAOBq4DqEITrxBQL07OXhkengyYGj7OzfDGvogdwuNgfTDJGSo+0NW
RaATvyG0DEFHrcDE78RNvqvSwvOr20L+cSrniWz+22/swDh1JhhPQiUYx0+us+7P
cssV3qzHu/7I87trfV56QnNNv4z2OUslz6dztPw=
-----END CERTIFICATE-----

위 내용을 보면, Private Key 1개, Certificate 2개 로 나온다. 이건 인증서 체인 파일인게 분명하다. Certificate 부분만 따로 때어서 보면 다음과 같다.

elastic-certificates.p12 인증서 내용
ZSH
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
]# ]# openssl x509 -text -in a.crt -noout
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            83:51:59:cd:31:fc:cd:e0:25:cf:bc:9e:68:ff:bf:38:d4:c3:6f:42
        Signature Algorithm: sha256WithRSAEncryption
        Issuer: CN = Elastic Certificate Tool Autogenerated CA
        Validity
            Not Before: Mar 27 13:46:07 2022 GMT
            Not After : Mar 26 13:46:07 2025 GMT
        Subject: CN = instance
        Subject Public Key Info:
.........
        X509v3 extensions:
            X509v3 Subject Key Identifier:
                18:89:42:9F:F6:93:77:A5:54:13:5F:20:BF:24:C1:53:DC:C4:ED:85
            X509v3 Authority Key Identifier:
                keyid:47:FC:42:8D:91:44:0E:06:FA:6B:6F:D5:91:70:BC:61:C5:01:3D:F3
 
            X509v3 Basic Constraints:
                CA:FALSE
    Signature Algorithm: sha256WithRSAEncryption
 
]# ]# openssl x509 -text -in b.crt -noout
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            10:50:1e:cd:93:fe:1d:11:81:cb:69:8d:13:88:48:59:36:bc:3a:af
        Signature Algorithm: sha256WithRSAEncryption
        Issuer: CN = Elastic Certificate Tool Autogenerated CA
        Validity
            Not Before: Mar 27 13:37:53 2022 GMT
            Not After : Mar 24 13:37:53 2032 GMT
        Subject: CN = Elastic Certificate Tool Autogenerated CA
...
        X509v3 extensions:
            X509v3 Subject Key Identifier:
                47:FC:42:8D:91:44:0E:06:FA:6B:6F:D5:91:70:BC:61:C5:01:3D:F3
            X509v3 Authority Key Identifier:
                keyid:47:FC:42:8D:91:44:0E:06:FA:6B:6F:D5:91:70:BC:61:C5:01:3D:F3
 
            X509v3 Basic Constraints: critical
                CA:TRUE
    Signature Algorithm: sha256WithRSAEncryption

확인 결과, 하나는 인증서이고 하나는 CA 인증서인 것으로 확인된다. 그러니까 elastic-certificate.p12 파일은 Private Key, CA 인증서, 서버 인증서 이렇게 3가지를 모두 가지는 파일이다.

PEM 형식 파일

Elasticsearch 에서는 PEM 형식의 파일도 함께 지원 한다. PEM 형식은 가장 흔하게, 널리 사용되는 인증서 파일 포맷 형식이다. elasticsearch-certutil 명령어를 이용해서 작성할 수 있다.

PEM 형식의 인증서 작성
ZSH
1
2
3
]# cd /usr/share/elasticsearch
]# ./bin/elasticsearch-certutil ca --days 3650 --pem --pass ""
Please enter the desired output file [elastic-stack-ca.zip]:

위와같이 zip 파일 형태로 생성된다. 압축을 해제하면 다음과 같이 파일이 생성된다.

elastic-stack-ca 압축파일 해제
ZSH
1
2
3
4
5
]# unzip elastic-stack-ca.zip
Archive:  elastic-stack-ca.zip
   creating: ca/
  inflating: ca/ca.crt              
  inflating: ca/ca.key

ca 디렉토리가 생성되는데, 보면 Private Key 파일과 CA 파일이 별도로 생성된 것을 알 수 있다.

이렇게 작성된 파일을 가지고 서버 인증서를 다음과 같이 생성할 수 있다.

PEM 형식의 서버 인증서 작성
ZSH
1
2
3
4
]# ./bin/elasticsearch-certutil cert --ca-cert ca/ca.crt --ca-key ca/ca.key --pem ""
Please enter the desired output file [certificate-bundle.zip]:
 
Certificates written to /usr/share/elasticsearch/certificate-bundle.zip

역시나 압축된 형태의 파일로 출력이 된다. 압축을 해제해 보자.

서버인증서 압축 해제
ZSH
1
2
3
4
5
]# unzip certificate-bundle.zip
Archive:  certificate-bundle.zip
   creating: instance/
  inflating: instance/instance.crt  
  inflating: instance/instance.key

instance.crt 인증서 파일의 내용을 살펴보자

서버인증서 압축 해제
ZSH
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
]# ]# openssl x509 -text -in instance.crt -noout
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            1f:71:54:19:fd:db:46:08:5a:ea:6a:66:18:1f:1b:66:e1:b6:68:f9
        Signature Algorithm: sha256WithRSAEncryption
        Issuer: CN = Elastic Certificate Tool Autogenerated CA
        Validity
            Not Before: Mar 27 14:02:26 2022 GMT
            Not After : Mar 26 14:02:26 2025 GMT
        Subject: CN = instance
...
        X509v3 extensions:
            X509v3 Subject Key Identifier:
                33:F1:77:87:2A:CD:50:8A:77:01:A7:23:67:37:75:57:A5:F3:8A:3F
            X509v3 Authority Key Identifier:
                keyid:42:F7:D4:5A:70:8E:A5:99:ED:E1:3E:93:A4:F0:75:42:7D:7F:66:92
 
            X509v3 Basic Constraints:
                CA:FALSE

서버 인증서임을 알수 있다.

인증서 활용

PKCS#12 형식과 PEM 형식의 인증서를 활용하는 방법은 다르다.

PKCS#12 형식은 다음과 같이 설정 한다.

elasticsearch.yml 에서 PKCS#12 인증서 설정
ZSH
1
2
3
4
xpack.security.transport.ssl.enabled: true
xpack.security.transport.ssl.verification_mode: certificate
xpack.security.transport.ssl.keystore.path: /etc/elasticsearch/elastic-certificates.p12
xpack.security.transport.ssl.truststore.path: /etc/elasticsearch/elastic-certificates.p12

PEM 형식은 다음과 같다.

elasticsearch.yml 에서 PEM 인증서 설정
ZSH
1
2
3
4
5
xpack.security.transport.ssl.enabled: true
xpack.security.transport.ssl.verification_mode: certificate
xpack.security.transport.ssl.key: /etc/elasticsearch/certs/instance/instance.key
xpack.security.transport.ssl.certificate: /etc/elasticsearch/certs/instance/instance.crt
xpack.security.transport.ssl.certificate_authorities: [ "/etc/elasticsearch/certs/ca/ca.crt" ]

SAN 인증서

지금까지 설명한 방법으로 인증서를 작성할 경우에 한가지 문제가 있을 수 있다. 이 인증서들은 SAN 인증서가 아니기 때문에 모든 도메인에서 통용될 수 있다. 앞에 인증서 내용을 보면 SAN 이 없다. 하지만 SAN 인증서라야만 하는 보안성을 요구된다면 SAN 인증서를 만들어 사용해야 한다.

SAN 인증서를 작성할때에 주의 사항은 Elasticsearch Stack 에서 사용할 모든 도메인, 혹은 IP 주소를 기재해야 한다. 그렇지 않으면 절대로 통신을 할 수가 없게 된다.

먼저, CA 인증서가 필요하다. 이 CA 인증서는 앞에 PEM 형식의 CA 인증서를 만들고 압축을 해제해 놓는다. 그리고 다음과 같이 instance.yml 파일을 작성한다.

instance.yml 작성
ZSH
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
]# vim instance.yml
instances:
  - name: "Elastic"
    ip:
      - 192.168.97.32
    dns:
      - master.systemv.local
  - name: "kibana"
    ip:
      - 192.168.97.32
    dns:
      - kibana.systemv.local
  - name: "logstash"
    ip:
      - 192.168.97.32
    dns:
      - logstash.systemv.local

이 파일에서 ip, dns 항목이 보이는데, 둘 중 하나만 있어도 된다. 어짜피 인증서에서 SAN 항목에서 IP Address, DNS 둘중하나가 들어가 있고 매칭이되면 인증서를 쓸 수 있다.

이제 다음과 같이 인증서를 작성해 생성한다.

instance.yml 작성
ZSH
1
]# ./bin/elasticsearch-certutil cert --ca-cert ca/ca.crt --ca-key ca/ca.key --pem --in instance.yml --out certs.zip

정상적으로 생성이 되었을 것이다. 압축을 해제해 보자

certs.zip 압축 해제
ZSH
1
2
3
4
5
6
7
8
9
10
11
]# unzip certs.zip
Archive:  certs.zip
   creating: master/
  inflating: master/master.crt      
  inflating: master/master.key      
   creating: kibana/
  inflating: kibana/kibana.crt      
  inflating: kibana/kibana.key      
   creating: logstash/
  inflating: logstash/logstash.crt  
  inflating: logstash/logstash.key

instance.yml 파일에서 이름부분이 디렉토리로 생성되면서 각각 인증서와 key 값이 생성되어 있다. 이 인증서들은 SAN 부분이 instance.yml 에 따라서 하나의 IP, 하나의 DNS 만 들어가 있다.

SAN 이 뭔지를 안다면 굳이 이렇게 다 분리할 필요는 없다는 생각을 하게 된다. 멀티도메인 인증서를 사용하면 도메인에 *.systemv.local 처럼 생성하면 될 것이고, 그러면 하나의 인증서를 가지고 여러곳에서 함께 사용이 가능해 진다. 위 예제에서는 각각의 용도에 맞게 딱 1개의 도메인과 IP 에 한해서 허용하도록 작성되었을 뿐이다.

PEM 형식의 Key 는 PKCS#12 형식으로 사용해야할 때가 있다. 이때는 다음과 같이 openssl 명령어를 이용해서 변환할 수 있다.

PKCS#12 형식 변환
ZSH
1
]# openssl pkcs8 -in master.key -topk8 -nocrypt -out master.pkcs8.key