OT-14 chore setup terraform and cicd#238
Merged
Merged
Conversation
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Repository UI Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (1)
🚧 Files skipped from review as they are similar to previous changes (1)
Walkthrough네 개의 배포 워크플로우(AI, EC2-Docker, Monitoring, RabbitMQ)에서 GitHub Actions ChangesAWS 인증 및 비밀/대상 해석 통합
Estimated code review effort🎯 4 (Complex) | ⏱️ ~45 minutes Possibly related PRs
Suggested labels
Suggested reviewers
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Tip 💬 Introducing Slack Agent: The best way for teams to turn conversations into code.Slack Agent is built on CodeRabbit's deep understanding of your code, so your team can collaborate across the entire SDLC without losing context.
Built for teams:
One agent for your entire SDLC. Right inside Slack. Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 5
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (2)
.github/workflows/deploy-monitoring.yml (1)
138-145:⚠️ Potential issue | 🟠 Major | ⚡ Quick winGrafana 비밀번호를
GITHUB_ENV에 기록 시 마스킹이 필요합니다.AWS Secrets Manager에서 가져온 값은 GitHub Actions가 자동으로 마스킹하지 않습니다. 현재 코드는 138-145줄에서 비밀번호를 추출하여 마스킹 없이
$GITHUB_ENV에 기록하고, 이후 182줄의c9인자에서 SSMsend-command파라미터로 전달되어 워크플로우 로그와 CloudTrail에 평문으로 노출될 수 있습니다. 145줄 이전에::add-mask::워크플로우 명령으로 마스킹하거나, 보다 안전하게는 인스턴스에서 직접 AWS Secrets Manager에 접근하도록 변경하는 것을 권장합니다.🛡️ 최소 변경: 마스킹 추가
GRAFANA_PASSWORD=$(echo "$SECRET_JSON" | jq -r '.password') if [ -z "$GRAFANA_PASSWORD" ] || [ "$GRAFANA_PASSWORD" = "null" ]; then echo "Grafana admin password is empty in secret: $GRAFANA_ADMIN_SECRET_ID" >&2 exit 1 fi + echo "::add-mask::$GRAFANA_PASSWORD" echo "GRAFANA_PASSWORD=$GRAFANA_PASSWORD" >> "$GITHUB_ENV"🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In @.github/workflows/deploy-monitoring.yml around lines 138 - 145, The workflow writes the Grafana admin password (GRAFANA_PASSWORD derived from GRAFANA_ADMIN_SECRET_ID) directly into GITHUB_ENV which can expose plaintext in logs and CloudTrail when later used (e.g., in the c9 send-command); before echoing the password to GITHUB_ENV, call the GitHub Actions mask command (::add-mask::"$GRAFANA_PASSWORD") so the value is redacted in logs, or better yet avoid storing the secret in GITHUB_ENV and instead change the remote step that uses the c9 parameter to fetch the secret directly from AWS Secrets Manager on the instance..github/workflows/deploy-ec2-docker.yml (1)
165-176:⚠️ Potential issue | 🟡 Minor | ⚡ Quick win
NODE_EXPORTER_TARGET_SSM_PARAM블록을 제거하세요 - 더 이상 사용되지 않는 코드입니다.
deploy-monitoring.yml이 EC2 Name 태그 기반 직접 IP 해석으로 변경된 후, 이 SSM 파라미터(/oplust/monitoring/targets/node-exporter)는 쓰기만 하고 읽혀지지 않습니다. 모니터링 워크플로우에서NODE_EXPORTER_TARGETS_YAML을 직접 생성하므로 (라인 79), 이 파라미터에 값을 쓰는 행위(라인 165-172)와 환경 변수(라인 92)는 제거하는 것이 좋습니다.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In @.github/workflows/deploy-ec2-docker.yml around lines 165 - 176, Remove the unused NODE_EXPORTER_TARGET_SSM_PARAM flow: delete the entire conditional block that checks promtail_role == "user-api" and writes to SSM (the aws ssm put-parameter snippet that sets "${private_ip}:9100"), and also remove the NODE_EXPORTER_TARGET_SSM_PARAM environment variable definition/usage elsewhere (the export/variable at the top where NODE_EXPORTER_TARGET_SSM_PARAM is set). After removal, search for any remaining references to NODE_EXPORTER_TARGET_SSM_PARAM and NODE_EXPORTER_TARGET SSM usage and delete them so no dead SSM write occurs.
🧹 Nitpick comments (4)
.github/workflows/deploy-ec2-docker.yml (2)
496-501: 💤 Low value파일 끝의 빈 줄이 과도합니다.
마지막 의미 있는 라인(
deploy_transcoder_ecs) 이후 다수의 빈 줄이 추가되어 있습니다. 정리 권장합니다.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In @.github/workflows/deploy-ec2-docker.yml around lines 496 - 501, 파일 끝에 불필요하게 여러 개의 빈 줄이 들어가 있으니 마지막 의미 있는 블록인 deploy_transcoder_ecs 이후의 추가 빈 줄들을 모두 삭제하고 파일이 한 줄(또는 단일 개행)로 깔끔하게 끝나도록 정리해 주세요.
91-97: ⚡ Quick win
RDS_INSTANCE_IDENTIFIER하드코딩과ENV_NAME의 분리.
RDS_INSTANCE_IDENTIFIER: oplust-dev-db가 하드코딩되어 있으나, 다른 리소스명은${PROJECT_NAME}-${ENV_NAME}또는/oplust/${ENV_NAME}/...패턴으로 일반화되어 있습니다. 환경이 추가되거나 프로젝트가 변경될 때 동기화 누락 위험이 있습니다.${PROJECT_NAME}-${ENV_NAME}-db형태로 통일을 권장합니다.♻️ 제안 패치
- RDS_INSTANCE_IDENTIFIER: oplust-dev-db + RDS_INSTANCE_IDENTIFIER: ${PROJECT_NAME}-${ENV_NAME}-db위 변경은 env: 블록의 변수 상호 참조가 제한된다는 점을 고려해,
run:단계 내에서RDS_INSTANCE_IDENTIFIER="${PROJECT_NAME}-${ENV_NAME}-db"로 옮기는 형태도 고려하세요.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In @.github/workflows/deploy-ec2-docker.yml around lines 91 - 97, RDS_INSTANCE_IDENTIFIER is hardcoded as oplust-dev-db; change it to derive from PROJECT_NAME and ENV_NAME (e.g., set RDS_INSTANCE_IDENTIFIER="${PROJECT_NAME}-${ENV_NAME}-db") so it follows the same naming pattern as other vars, or if env-block interpolation is limited, move the assignment into the run: step and export/define RDS_INSTANCE_IDENTIFIER there using PROJECT_NAME and ENV_NAME; update references to the symbol RDS_INSTANCE_IDENTIFIER accordingly..github/workflows/deploy-rabbitmq.yml (2)
67-68: ⚡ Quick win패키지 관리자가
dnf로 가정되어 있어 OS 호환성이 제한됩니다.Amazon Linux 2(
yum), Ubuntu/Debian(apt-get) 환경에서는sudo dnf -y install이 실패합니다. 인스턴스 OS가 Amazon Linux 2023/Fedora로 고정되어 있다면 그대로도 무방하지만, RabbitMQ 박스의 OS가 바뀌면 동기화가 중단될 위험이 있습니다. 다중 패키지 매니저 폴백을 권장합니다.♻️ 제안 패치
- --arg c2 "command -v jq >/dev/null 2>&1 || sudo dnf -y install jq" \ - --arg c3 "command -v aws >/dev/null 2>&1 || sudo dnf -y install awscli" \ + --arg c2 "command -v jq >/dev/null 2>&1 || (command -v dnf >/dev/null 2>&1 && sudo dnf -y install jq) || (command -v yum >/dev/null 2>&1 && sudo yum -y install jq) || (command -v apt-get >/dev/null 2>&1 && sudo apt-get update && sudo apt-get -y install jq)" \ + --arg c3 "command -v aws >/dev/null 2>&1 || (command -v dnf >/dev/null 2>&1 && sudo dnf -y install awscli) || (command -v yum >/dev/null 2>&1 && sudo yum -y install awscli) || (command -v apt-get >/dev/null 2>&1 && sudo apt-get update && sudo apt-get -y install awscli)" \🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In @.github/workflows/deploy-rabbitmq.yml around lines 67 - 68, The workflow args c2 and c3 assume dnf which breaks on systems using yum/apt-get/apk; update the commands passed as --arg c2 and --arg c3 to perform a package-manager fallback (check for command -v jq/aws, then try installation with dnf || yum || apt-get || apk with appropriate sudo flags) or use a small shell helper that detects the distro (checking for command -v dnf, yum, apt-get, apk) and runs the corresponding install command so jq and awscli are installed reliably across Amazon Linux 2, Ubuntu/Debian, Alpine, and Fedora systems.
78-83: 💤 Low value
rabbitmqctl list_users헤더 라인 처리 개선 권장.
rabbitmqctl list_users출력은 버전에 따라 첫 줄에user와tags컬럼 헤더가 포함됩니다. 현재 코드의awk '{print $1}' | grep -qx는 사용자명과 정확 일치 검사를 하므로 대부분 안전하지만, 코드의 의도를 명확히 하고 더욱 안정적으로 하려면--no-table-headers옵션 사용을 권장합니다.♻️ 제안 패치
- --arg c13 "if sudo rabbitmqctl list_users | awk '{print \$1}' | grep -qx \"\$ADMIN_USER\"; then sudo rabbitmqctl change_password \"\$ADMIN_USER\" \"\$ADMIN_PASS\"; else sudo rabbitmqctl add_user \"\$ADMIN_USER\" \"\$ADMIN_PASS\"; fi" \ + --arg c13 "if sudo rabbitmqctl list_users --no-table-headers | awk '{print \$1}' | grep -qx \"\$ADMIN_USER\"; then sudo rabbitmqctl change_password \"\$ADMIN_USER\" \"\$ADMIN_PASS\"; else sudo rabbitmqctl add_user \"\$ADMIN_USER\" \"\$ADMIN_PASS\"; fi" \
c16에도 동일하게 적용하세요.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In @.github/workflows/deploy-rabbitmq.yml around lines 78 - 83, The rabbitmq user-check commands in args c13 and c16 should use "rabbitmqctl list_users --no-table-headers" to avoid the header row being treated as a username; update the string values for c13 and c16 to include --no-table-headers while keeping the existing awk '{print $1}' | grep -qx checks, and leave c14/c15/c17/c18 unchanged.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In @.github/workflows/deploy-ec2-docker.yml:
- Around line 128-133: The deploy-ec2-docker workflow is hardcoding the EC2 Name
tag filter as Name=tag:Name,Values=monitoring while deploy-ai.yml uses
Name=tag:Name,Values=${PROJECT_NAME}-monitoring-ec2, causing mismatch; update
the filter in deploy-ec2-docker.yml (the code constructing MONITORING_PRIVATE_IP
and the aws ec2 --filters entry) to use the same naming convention (e.g.,
${PROJECT_NAME}-monitoring-ec2) and ensure PROJECT_NAME is exported or provide a
consistent fallback so both workflows search for the identical tag value.
- Around line 215-217: The workflow currently injects DB_USER_B64/DB_PASS_B64
into the SSM send-command payload (and into env_file) which exposes base64
plaintext in CloudTrail/SSM logs; change the step so the send-command does NOT
include DB_USER_B64/DB_PASS_B64 and instead run on the instance an aws
secretsmanager get-secret-value (or aws ssm get-parameter) call to fetch the DB
credentials and write SPRING_DATASOURCE_USERNAME/SPRING_DATASOURCE_PASSWORD into
env_file; ensure the EC2 instance role has secretsmanager:GetSecretValue (or
ssm:GetParameter) permission and update the command/script referenced by
env_file creation to perform the Secrets Manager call locally rather than
receiving base64 secrets in the workflow.
In @.github/workflows/deploy-monitoring.yml:
- Around line 92-106: The script builds TRANSCODER_TARGETS_YAML with the wrong
hardcoded port (8080) causing Prometheus to miss targets; update the
TRANSCODER_TARGETS_YAML generation to use port 8082 and normalize AWS CLI
tab-separated outputs (TASK_ARNS and ENI_IDS) by piping them through tr '\t' ' '
before further use; specifically adjust the pipeline that produces
TRANSCODER_TARGETS_YAML (referencing TRANSCODER_IPS -> TRANSCODER_TARGETS_YAML)
and apply tr '\t' ' ' to TASK_ARNS and ENI_IDS parsing to ensure shell-safe
space-separated lists.
- Around line 66-68: The workflow uses hardcoded tag names ("user", "admin") to
resolve USER_API_IP and ADMIN_API_IP while deploy-ai.yml uses a
"${PROJECT_NAME}-monitoring-ec2" pattern, causing inconsistent EC2 Name tag
conventions; update deploy-monitoring.yml where USER_API_IP, ADMIN_API_IP and
MONITORING_IP are computed to derive tags consistently (e.g.,
`${PROJECT_NAME}-user-ec2`, `${PROJECT_NAME}-admin-ec2`, and
`${PROJECT_NAME}-monitoring-ec2`) or add a clear fallback/validation: check if
tags exist and emit a descriptive error before the existing exit path (the block
that currently exits with exit 1), and ensure INSTANCE_TAG input is either
validated or replaced with the same PROJECT_NAME-based naming used in
deploy-ai.yml; also update workflow inputs or docs to state the required tag
naming convention.
In @.github/workflows/deploy-rabbitmq.yml:
- Around line 80-83: The vhost value (RABBITMQ_VHOST) is interpolated into the
shell string used by commands c15 and c18 which allows injection if the vhost
contains a single quote; fix by validating or escaping the input before
interpolation: add validation logic for RABBITMQ_VHOST (e.g., allow only a safe
charset like alphanumerics, dash, underscore, slash) in the workflow input
handling or sanitize/escape single quotes (or reject values containing
quotes/newlines) so the constructed commands for set_permissions (and any other
use of '${RABBITMQ_VHOST}') cannot break out of the single quotes; update the
workflow_dispatch input schema and the step that sets/uses RABBITMQ_VHOST
accordingly and reference c15 and c18 when applying the validation/sanitization.
---
Outside diff comments:
In @.github/workflows/deploy-ec2-docker.yml:
- Around line 165-176: Remove the unused NODE_EXPORTER_TARGET_SSM_PARAM flow:
delete the entire conditional block that checks promtail_role == "user-api" and
writes to SSM (the aws ssm put-parameter snippet that sets
"${private_ip}:9100"), and also remove the NODE_EXPORTER_TARGET_SSM_PARAM
environment variable definition/usage elsewhere (the export/variable at the top
where NODE_EXPORTER_TARGET_SSM_PARAM is set). After removal, search for any
remaining references to NODE_EXPORTER_TARGET_SSM_PARAM and NODE_EXPORTER_TARGET
SSM usage and delete them so no dead SSM write occurs.
In @.github/workflows/deploy-monitoring.yml:
- Around line 138-145: The workflow writes the Grafana admin password
(GRAFANA_PASSWORD derived from GRAFANA_ADMIN_SECRET_ID) directly into GITHUB_ENV
which can expose plaintext in logs and CloudTrail when later used (e.g., in the
c9 send-command); before echoing the password to GITHUB_ENV, call the GitHub
Actions mask command (::add-mask::"$GRAFANA_PASSWORD") so the value is redacted
in logs, or better yet avoid storing the secret in GITHUB_ENV and instead change
the remote step that uses the c9 parameter to fetch the secret directly from AWS
Secrets Manager on the instance.
---
Nitpick comments:
In @.github/workflows/deploy-ec2-docker.yml:
- Around line 496-501: 파일 끝에 불필요하게 여러 개의 빈 줄이 들어가 있으니 마지막 의미 있는 블록인
deploy_transcoder_ecs 이후의 추가 빈 줄들을 모두 삭제하고 파일이 한 줄(또는 단일 개행)로 깔끔하게 끝나도록 정리해 주세요.
- Around line 91-97: RDS_INSTANCE_IDENTIFIER is hardcoded as oplust-dev-db;
change it to derive from PROJECT_NAME and ENV_NAME (e.g., set
RDS_INSTANCE_IDENTIFIER="${PROJECT_NAME}-${ENV_NAME}-db") so it follows the same
naming pattern as other vars, or if env-block interpolation is limited, move the
assignment into the run: step and export/define RDS_INSTANCE_IDENTIFIER there
using PROJECT_NAME and ENV_NAME; update references to the symbol
RDS_INSTANCE_IDENTIFIER accordingly.
In @.github/workflows/deploy-rabbitmq.yml:
- Around line 67-68: The workflow args c2 and c3 assume dnf which breaks on
systems using yum/apt-get/apk; update the commands passed as --arg c2 and --arg
c3 to perform a package-manager fallback (check for command -v jq/aws, then try
installation with dnf || yum || apt-get || apk with appropriate sudo flags) or
use a small shell helper that detects the distro (checking for command -v dnf,
yum, apt-get, apk) and runs the corresponding install command so jq and awscli
are installed reliably across Amazon Linux 2, Ubuntu/Debian, Alpine, and Fedora
systems.
- Around line 78-83: The rabbitmq user-check commands in args c13 and c16 should
use "rabbitmqctl list_users --no-table-headers" to avoid the header row being
treated as a username; update the string values for c13 and c16 to include
--no-table-headers while keeping the existing awk '{print $1}' | grep -qx
checks, and leave c14/c15/c17/c18 unchanged.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Repository UI
Review profile: CHILL
Plan: Pro
Run ID: 81e7ac21-50e3-41ab-ad1d-3f9ad34fe6e8
📒 Files selected for processing (4)
.github/workflows/deploy-ai.yml.github/workflows/deploy-ec2-docker.yml.github/workflows/deploy-monitoring.yml.github/workflows/deploy-rabbitmq.yml
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In @.github/workflows/deploy-ai.yml:
- Around line 99-107: The current aws ec2 describe-instances call uses only
"Name=tag:Name,Values=monitoring" which can match monitoring instances from
other environments; update the filter set used when populating
MONITORING_PRIVATE_IP (and the related occurrences at lines 127-130) to include
an environment-scoping tag filter (e.g.,
"Name=tag:Environment,Values=$ENVIRONMENT" or
"Name=tag:Project,Values=$PROJECT") so the lookup restricts to the intended
environment/project; ensure the same additional tag filter is applied to both
the Loki endpoint and node-exporter ingress source SG lookups so they resolve to
the same, correct monitoring host.
In @.github/workflows/deploy-ec2-docker.yml:
- Around line 92-93: The MONITORING_INSTANCE_TAG value is too generic and will
match wrong EC2 instances; update the workflow to use a unique tag schema (e.g.,
include project and environment) or add additional tag filters (e.g., PROJECT
and ENVIRONMENT / Project and Environment) wherever instance selection or SSM
parameter resolution occurs (references: MONITORING_INSTANCE_TAG,
NODE_EXPORTER_TARGET_SSM_PARAM and other instance-tag env vars used later in the
file). Change the tag values to include project/env identifiers (or add new env
vars like PROJECT and ENVIRONMENT) and update every place that filters EC2
instances or configures promtail/node-exporter to use both the name tag and
these additional tag filters so selection is unambiguous.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Repository UI
Review profile: CHILL
Plan: Pro
Run ID: 9daeaf80-c7c2-4866-ab1e-2a5bbba9eb71
📒 Files selected for processing (4)
.github/workflows/deploy-ai.yml.github/workflows/deploy-ec2-docker.yml.github/workflows/deploy-monitoring.yml.github/workflows/deploy-rabbitmq.yml
🚧 Files skipped from review as they are similar to previous changes (2)
- .github/workflows/deploy-rabbitmq.yml
- .github/workflows/deploy-monitoring.yml
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In @.github/workflows/deploy-ai.yml:
- Around line 100-104: Currently you call aws ec2 describe-instances twice with
the same filters which can return different instances; instead, first query and
store the monitoring instance ID (e.g., MONITORING_INSTANCE_ID using the same
filters and --query "Reservations[0].Instances[0].InstanceId"), then reuse that
ID with --instance-ids to fetch MONITORING_PRIVATE_IP and MONITORING_SG_ID
(querying PrivateIpAddress and SecurityGroups[*].GroupId) so both values come
from the same instance (follow the MACHINE_INSTANCE pattern that uses
instance-ids).
- Around line 76-80: The OIDC session length is too short (default 3600s) for
your deployment which can exceed that; update the GitHub Action step that uses
aws-actions/configure-aws-credentials@v4 (the "Configure AWS credentials" step)
to set with: role-duration-seconds to at least 7200 (or a bit higher to match
your SSM/polling timeouts) and verify the target IAM role's MaxSessionDuration
is configured to the same or greater value so AssumeRole tokens won't expire
during the long-running SSM/polling operations.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Repository UI
Review profile: CHILL
Plan: Pro
Run ID: 48b05c60-4329-4d6c-a4a0-359e1444f3d6
📒 Files selected for processing (4)
.github/workflows/deploy-ai.yml.github/workflows/deploy-ec2-docker.yml.github/workflows/deploy-monitoring.yml.github/workflows/deploy-rabbitmq.yml
🚧 Files skipped from review as they are similar to previous changes (3)
- .github/workflows/deploy-rabbitmq.yml
- .github/workflows/deploy-monitoring.yml
- .github/workflows/deploy-ec2-docker.yml
Comment on lines
76
to
80
| - name: Configure AWS credentials | ||
| uses: aws-actions/configure-aws-credentials@v4 | ||
| with: | ||
| aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY_ID }} | ||
| aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY }} | ||
| role-to-assume: ${{ secrets.AWS_GITHUB_ACTIONS_ROLE_ARN }} | ||
| aws-region: ${{ env.AWS_REGION }} |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
cat -n .github/workflows/deploy-ai.yml | head -100Repository: OpenTheTaste/backend
Length of output: 4350
🏁 Script executed:
cat -n .github/workflows/deploy-ai.yml | sed -n '200,280p'Repository: OpenTheTaste/backend
Length of output: 4593
🌐 Web query:
aws-actions configure-aws-credentials@v4 default role-duration-seconds OIDC session
💡 Result:
In the aws-actions/configure-aws-credentials action (including v4), the role-duration-seconds input controls the duration of the assumed role session in seconds [1][2]. Key details regarding this setting include: Default Value: The default duration is 1 hour (3600 seconds) [1][3]. Configurability: You can adjust this value by providing an integer to the role-duration-seconds input [1][3]. Constraints: The requested duration cannot exceed the MaxSessionDuration setting configured for the specific IAM Role in AWS [1][4]. Acceptable values generally range from 15 minutes (900 seconds) to 12 hours (43200 seconds), depending on the IAM role's configuration [3][5]. OIDC Context: When using OIDC to assume a role, the same 1-hour default applies [6][7]. If you require a session longer than 1 hour, you must explicitly set role-duration-seconds to your desired value (up to the role's maximum) [6]. If you encounter an error stating that the requested duration exceeds the maximum, ensure that the IAM Role's MaxSessionDuration in the AWS console or via CLI/API is set high enough to accommodate your requested duration [4][5].
Citations:
- 1: https://github.com/aws-actions/configure-aws-credentials/tree/16fec6080fdb89d4b237dee411b7bf8f3658ec97
- 2: https://github.com/aws-actions/configure-aws-credentials/blob/v4/action.yml
- 3: https://github.com/aws-actions/configure-aws-credentials
- 4: Always timeouts when trying to assume a role aws-actions/configure-aws-credentials#436
- 5: https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_update-role-settings.html
- 6: Assume Role with OIDC with more than 1 hour aws-actions/configure-aws-credentials#354
- 7: chore: update role duration description aws-actions/configure-aws-credentials#486
OIDC 세션 길이를 배포 최대 시간에 맞춰 명시해야 합니다.
현재 configure-aws-credentials 액션의 기본 OIDC 세션 기간은 3,600초(1시간)이지만, 라인 235의 SSM 명령 타임아웃은 7,200초이고 라인 244-270의 폴링 루프도 최대 7,200초까지 지속됩니다. 이 경우 배포가 1시간을 초과하면 라인 245, 259, 273의 AWS API 호출이 ExpiredToken 오류로 실패합니다. role-duration-seconds를 7,200초 이상으로 설정하고, 해당 IAM 역할의 MaxSessionDuration이 충분히 구성되어 있는지 확인하세요.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In @.github/workflows/deploy-ai.yml around lines 76 - 80, The OIDC session
length is too short (default 3600s) for your deployment which can exceed that;
update the GitHub Action step that uses aws-actions/configure-aws-credentials@v4
(the "Configure AWS credentials" step) to set with: role-duration-seconds to at
least 7200 (or a bit higher to match your SSM/polling timeouts) and verify the
target IAM role's MaxSessionDuration is configured to the same or greater value
so AssumeRole tokens won't expire during the long-running SSM/polling
operations.
Comment on lines
100
to
104
| MONITORING_PRIVATE_IP=$(aws ec2 describe-instances \ | ||
| --region "$AWS_REGION" \ | ||
| --filters "Name=tag:Name,Values=${PROJECT_NAME}-monitoring-ec2" "Name=instance-state-name,Values=running" \ | ||
| --filters "Name=tag:Name,Values=monitoring" "Name=tag:Project,Values=${PROJECT_NAME}" "Name=tag:Env,Values=${ENV_NAME}" "Name=instance-state-name,Values=running" \ | ||
| --query "Reservations[0].Instances[0].PrivateIpAddress" \ | ||
| --output text) |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
cat -n .github/workflows/deploy-ai.yml | sed -n '95,160p'Repository: OpenTheTaste/backend
Length of output: 3433
모니터링 인스턴스는 ID로 먼저 결정 후 재사용하세요.
lines 100-104와 148-152에서 동일한 필터로 describe-instances를 두 번 호출하고 있습니다. 같은 태그를 가진 모니터링 인스턴스가 둘 이상 있을 경우, 각 쿼리가 Reservations[0].Instances[0]에서 서로 다른 인스턴스를 반환할 수 있으며, 이로 인해 MONITORING_PRIVATE_IP와 MONITORING_SG_ID가 서로 다른 인스턴스를 가리킬 수 있습니다.
모니터링 인스턴스 ID를 먼저 1회 조회로 결정한 후, 그 ID로 private IP와 SG를 모두 읽어오세요. (MACHINE_INSTANCE의 패턴을 참고: lines 142-146에서 instance-ids 사용)
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In @.github/workflows/deploy-ai.yml around lines 100 - 104, Currently you call
aws ec2 describe-instances twice with the same filters which can return
different instances; instead, first query and store the monitoring instance ID
(e.g., MONITORING_INSTANCE_ID using the same filters and --query
"Reservations[0].Instances[0].InstanceId"), then reuse that ID with
--instance-ids to fetch MONITORING_PRIVATE_IP and MONITORING_SG_ID (querying
PrivateIpAddress and SecurityGroups[*].GroupId) so both values come from the
same instance (follow the MACHINE_INSTANCE pattern that uses instance-ids).
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
📝 작업 내용
📷 스크린샷
☑️ 체크 리스트
#️⃣ 연관된 이슈
OT-14
💬 리뷰 요구사항
Summary by CodeRabbit