サンドボックスOUに適用したサービスコントロールポリシーのサンプル

社内のAWSアカウント管理を行うことになりました。
標準的なSCP(サービスコトロールポリシー)を作成したので、記事にします。
サンドボックスOUに付与したSCPになります。

1はセキュリティ強化と管理を楽にするため
2~4は費用の適正化のため

1、利用リージョンの制限

以下の利用リージョンに制限する
・東京(ap-northeast-1)
・大阪(ap-northeast-3)
バージニア北部(us-east-1)
オハイオ(us-east-2)
オレゴン(us-west-2)

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "denyRegion",
      "Effect": "Deny",
      "Action": [
        "*"
      ],
      "Resource": [
        "*"
      ],
      "Condition": {
        "StringNotEquals": {
          "aws:RequestedRegion": [
            "ap-northeast-1",
            "ap-northeast-3",
            "us-east-1",
            "us-east-2",
            "us-west-1"
          ]
        }
      }
    }
  ]
}


2、RDSのインスタンスクラスを制限する

個別に記事にしたので、以下に記載しています rikues2012.hatenablog.com


3、EC2のインスタンスタイプを制限する

以下のインスタンスタイプに制限する
・t2:nano、micro、small
・t3:nano、micro、small
・t4g:nano、micro、small

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "RequireMicroInstanceType",
      "Effect": "Deny",
      "Action": "ec2:RunInstances",
      "Resource": [
        "arn:aws:ec2:*:*:instance/*"
      ],
      "Condition": {
        "StringNotEquals": {
          "ec2:InstanceType": [
            "t2.nano",
            "t2.micro",
            "t2.small",
            "t3.nano",
            "t3.micro",
            "t3.small",
            "t4g.nano",
            "t4g.micro",
            "t4g.small"
            ]
        }
      }
    }
  ]
}


4、サービス利用を制限する

利用料が高いもの&弊社では利用しないサービスに限定しました
以下のサービスを利用不可にする
・Braket(量子アルゴリズム)
・CloudHSM
・DeepRacer、DeepComposer、DeepLens
・Shield
・Show Family
・Storage Gateway
・R53(ドメイン購入操作)

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Deny",
            "Action": [
                "braket:*",
                "cloudhsm:*",
                "deepracer:*",
                "deepcomposer:*",
                "deeplens:*",
                "shield:*",
                "snowball:*",
                "snow-device-management:*",
                "storagegateway:*",
                "route53domains:*"
            ],
      "Resource": "*"
    }
  ]
}

全サービスで400以上?あるので全ては精査できていないです。
もっと利用制限した方が良いサービスはあると思いますが、まずは上記としました。
Shield(Advanced)は年契約してしまうと500万ぐらいかかるので、制限したほうが良いです。


【参考サイト】
blog.serverworks.co.jp

dev.classmethod.jp

SCPでRDSのインスタンスクラスを制限する

SCP(サービスコトロールポリシー)でRDSのインスタンスクラスを制限する方法になります。
初めてSCPを作成したので微妙にハマりました。

RDSのインスタンスクラスを制限する

※Auroraも同じSCPで制限できます
コスト最適化のために以下のインスタンスクラスに制限
・db.t2:micro、small、medium
・db.t3:micro、small、medium
・db.t4g:micro、small、medium

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Deny",
      "Action": "rds:CreateDBInstance",
      "Resource": "arn:aws:rds:*:*:*:*",
      "Condition": {
        "StringNotLike": {
          "rds:DatabaseClass": [
            "db.t2.micro",
            "db.t2.small",
            "db.t2.medium",
            "db.t3.micro",
            "db.t3.small",
            "db.t3.medium",
            "db.t4g.micro",
            "db.t4g.small",
            "db.t4g.medium"
          ]
        }
      }
    }
  ]
}


気を付けるところ1

以下の「Resource」記述にするとエラーとなりました

"Resource": "arn:aws:rds:*"

「Missing ARN Field: リソース ARN には、少なくとも 6 フィールドが含まれていて、次の構造が含まれている必要があります: arn:partition:service:region:account:resource。」

対応としては以下にしました。

"Resource": "arn:aws:rds:*:*:*:*",


気を付けるところ2

インスタンスクラスの先頭に「db」を付ける。 当たり前ですが「t2.micro」だとダメで、「db.t2.micro」にすること。


気を付けるところ3

Aurora MySQLを利用する場合は
Aurora(Mysql8.0~)はmedium以下のインスタンスタイプは選択できないため、mediumも含める。


動作確認(制限確認)

エラーとなりインスタンスは作成できませんが、クラスターは作成できてしまう。。


クラスターが作成されてしまう問題はありますが、
RDS及びAuroraのインスタンスクラスは制限することができました。

ECS on Fargateで複数環境のDockerfileを共通で利用する

複数環境(本番、検証、開発)でECS on Fargateを構築した際にDockerfileを共通化した備忘録です。

前提情報

  • 各環境は別々のAWSアカウント
  • ECSのタスク内は「Nginx」と「SpringBoot」のコンテナで連携
  • 本記事の共通化対象は「SpringBoot」のコンテナで利用するDockerfile

手順

buildspec.yml内のdocker buildするところでDockerfileに引数を渡すことで共通化できます。
例)Javaのメモリ割り当てのところを共通化する

1、パラメータストアにメモリの初期値と最大値を設定する

メモリ初期値のキー名:/web/java-min-memsize

メモリ最大値のキー名:/web/java-max-memsize ※画像は省略

2、buildspec.ymlでパラメータストアの値を取得し、Dockerfileに引数で渡す

--build-arg」を利用してDockerfileに引数で渡す
複数の値を渡したい場合は以下のように「--build-arg」を複数書く。

buildspec.yml

version: 0.2

env:
  parameter-store:
    maxsize: "/web/java-max-memsize"
    minsize: "/web/java-min-memsize" 

phases:
  install:
    runtime-versions:
      python: 3.9
  pre_build:
    commands:
   pre_buildは省略    

  build:
    commands:
      - mv buildConf/backOffice/* .
      - docker build -t $REPOSITORY_URI:latest --build-arg MAXSIZE=${maxsize} --build-arg MINSIZE=${minsize} .
      - docker tag $REPOSITORY_URI:latest $REPOSITORY_URI:$IMAGE_TAG


3、Dockerfileで値を受け取る

「ARG」で引数を受け取り、「ENV」で環境変数に設定します。
最後に${}で括って環境変数名を入れます。
環境変数に入れないと実行時に参照することができません。

Dockerfile

FROM public.ecr.aws/amazoncorretto/amazoncorretto:17

ARG MINSIZE
ARG MAXSIZE

ENV MINSIZE ${MINSIZE}
ENV MAXSIZE ${MAXSIZE}

CMD java -Xms${MINSIZE}m -Xmx${MAXSIZE}m -Dloader.path=/test/conf -jar /test/sample.jar

以上で設定は完了です。

buildspec.ymlでparameter-store利用時に「not a valid identifier」エラーの対処法

buildspec.ymlでparameter-store(パラメータストア)を利用したのですが、うまく値を取得することができませんでした。

CodeBuildのIAMロールには「AmazonSSMReadOnlyAccess」ポリシーは付けていました。

原因としては変数に「-」が入っていたからでした。。

 

具体的には赤枠のパラメータストアから値を取得する変数の「s3-cicd-api」でエラーとなります。

 

CodeBuildのログを参照すると以下のエラーでした。

「s3-cicd-api: not a valid identifier」

対応

「-」などの記号を取る。

今回の場合は「s3-cicd-api」→「s3cicdapi」に変更しました。

secrets-manager(AWS Secrets Manager)もたぶん同じだと思います。

 

今まで何となくymlファイルの変数には記号入れたことなかったなぁ~と。

AWS公式サイト(CodeBuild のビルド仕様に関するリファレンス)には特に記載していなかったです。

常識ってことですかね。。

docs.aws.amazon.com

対応方法:Error: PythonPipBuilder:ResolveDependencies - pip executable not found in your python environment at /usr/bin/python3.9

AWS CodeBuild時に以下のエラーが発生した時の対処方法になります。

「Error: PythonPipBuilder:ResolveDependencies - pip executable not found in your python environment at /usr/bin/python3.9」

原因

以下のビルトイメージを利用したため

aws/codebuild/amazonlinux2-x86_64-standard:5.0

ビルトイメージがPython3.9に対応していない

対応方法

以下のビルトイメージを利用する

aws/codebuild/amazonlinux2-x86_64-standard:4.0

AWSコンソールからだと、対象のCodeBuildプロジェクトの「ビルドの詳細」タブを選択し、「環境」の「編集」ボタンから以下のところで変更できます。

 

もう少し詳細

今回ビルドしたのはLambdaのPython3.9になります。

LayerありのLambdaをビルドしたときにエラーとなりました。

ただAWS公式のランタイムとビルドイメージの対応表をみると、

Python3.9は「AmazonLinux2-x86_64-standard:4.0」だよって記載されていました。

■参照先(AWS公式サイト)

docs.aws.amazon.com

 

こんなところでエラーになる人もいないみたいで、全然ネットに情報がなくてハマってしまいました。

もうすぐ開発が始まるのですが、Python3.11にした方が良いような気もしました。

CodePipelineから別アカウントの CodeCommitとECRを利用する

CodePipelineから別アカウントの CodeCommitとECRの2つを利用する手順と躓いたところを書きます。

主には別アカウントにECRを配置するところで躓いたので、そこを中心に書きます。

下記の図は書いていませんが、検証環境アカウントで動作確認をしたECR内のイメージを本番環境アカウントで利用したいため、Dev環境にECRを置く構成としました。

 

以下、イメージ図です。

前提

・同一アカウント(検証環境)で上記の構成を構築済(CodeCommit、ECRは検証環境にある状態)

・buildspec.ymlでSpringbootのjarファイルをコンパイルして、ECRにイメージプッシュ

 ※他の言語でも本編に影響しないが念のため記載

 

Code CommitをDev環境に配置する(前半)

Dev環境:Code Commit

検証環境:Code Commit以外のサービス

 

以下のクラスメソッドさんの記事の手順で構築できます。

dev.classmethod.jp

Code Commitは他のサイトでもいろいろ紹介されていたのですが、上記サイトが一番分かりやすく、しかも手順もしっかり書かれていました。

 

ECRをDev環境に配置する(後半)

Dev環境(AWSアカウント 111111111111)

 :Code Commit、ECR(今回の手順はここ)

検証環境(AWSアカウント 222222222222)

 :上記以外のサービス

概要

 Dev環境

  1、ECRを作成し、リポジトリポリシーを設定(検証環境からアクセスを許可)

  2、CodeBuild用のIAMロールを作成

   (検証環境アカウントのIAMロールからAssumeRoleされる)

 検証環境

  3、CodeBuild用のIAMロールを作成

   (2のIAMロールをAssumeRoleする)

 Dev環境

  4、buildspec.ymlファイル修正(主にECRにログインするところを修正)

 

1~3はすんなりできるのですが、4のところで躓きました。

 

手順詳細

Dev環境

1、ECRを作成し、リポジトリポリシーを設定(検証環境からアクセスを許可)

 1-1、ECRを作成

   任意のリポジトリ名を設定し、「リポジトリ作成」ボタンをクリック

   ※他はデフォルトでOK(検証環境なので)

 

 1-2、ECRリポジトリポリシーを設定

  対象のECRを選択し、「アクション ⇒ 許可」をクリック

 

  「ポリシーJSONの編集」をクリック

 

 以下をポリシーJSONに入力する

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowCrossPushPull",
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::222222222222:root"
      },
      "Action": [
        "ecr:BatchCheckLayerAvailability",
        "ecr:BatchGetImage",
        "ecr:CompleteLayerUpload",
        "ecr:GetDownloadUrlForLayer",
        "ecr:InitiateLayerUpload",
        "ecr:PutImage",
        "ecr:UploadLayerPart"
      ]
    }
  ]
}

「"AWS": "arn:aws:iam::222222222222:root"」は、以下のように手順3で作成する検証環境のCodeBuild用のIAMロールにした方が良いです。

「"AWS": "arn:aws:iam::222222222222:role/検証環境のCodeBuild用のIAMロール名"」

 

2、CodeBuild用のIAMロールを作成

 2-1、ポリシーを作成(ポリシー名:codebuild-policy-111111111111)

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "ECRAccessPolicy",
            "Effect": "Allow",
            "Action": [
                "ecr:GetAuthorizationToken",
                "ecr:BatchCheckLayerAvailability",
                "ecr:GetDownloadUrlForLayer",
                "ecr:GetRepositoryPolicy",
                "ecr:DescribeRepositories",
                "ecr:ListImages",
                "ecr:DescribeImages",
                "ecr:BatchGetImage",
                "ecr:GetLifecyclePolicy",
                "ecr:GetLifecyclePolicyPreview",
                "ecr:ListTagsForResource",
                "ecr:DescribeImageScanFindings",
                "ecr:InitiateLayerUpload",
                "ecr:UploadLayerPart",
                "ecr:CompleteLayerUpload",
                "ecr:PutImage"
            ],
            "Resource": "*"
        }
    ]
}

 2-2、IAMロールを作成(IAMロール名:codebuild-role-111111111111)

  2-1で作成したポリシーを付ける

 

 信用されたエンティティを入力する

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "AWS": "arn:aws:iam::222222222222:root"
            },
            "Action": "sts:AssumeRole",
            "Condition": {}
        }
    ]
}

※ロール作成時には自由に入力できないため、一旦仮の値を設定しロールを作成し、編集にて入力

 

 

検証環境

3、CodeBuild用のIAMロールを作成

 3-1、ポリシーを作成(ポリシー名:codebuild-policy-222222222222)

  手順2-2で作成したDev側のロールをResourceに指定する

 

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "sts:AssumeRole",
            "Resource": "arn:aws:iam::111111111111:role/codebuild-role-111111111111"
        }
    ]
}

 3-2、IAMロールを作成(IAMロール名:codebuild-role-222222222222)

  3-1で作成したポリシーを付ける

   ※画像は省略

 

  信用されたエンティティを入力する

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "Service": "codebuild.amazonaws.com",
                "AWS": "arn:aws:iam::111111111111:root",
            },
            "Action": "sts:AssumeRole"
        }
    ]
}

Dev環境

4、buildspec.ymlファイル修正

権限も設定したのでECRのURLだけ変更すればうまくプッシュできるのでは?を思ったのですが、ECRのログインができず修正する必要があります。

いろいろ方法あるのですが、codebuild内にAWSのプロファイルを作成しました。

赤字が修正した箇所になります

 

version: 0.2
phases:
  install:
    runtime-versions:
      python: 3.9
  pre_build:
    commands:
      - echo "[profile aaa111]" > .awscli-config
      - echo "role_arn = arn:aws:iam::111111111111:role/codebuild-role-111111111111" >> .awscli-config
      - echo "credential_source = EcsContainer" >> .awscli-config
      - export AWS_CONFIG_FILE=${CODEBUILD_SRC_DIR}/.awscli-config
      - $(aws --profile aaa111 ecr get-login --region $AWS_DEFAULT_REGION --no-include-email)
      - REPOSITORY_URI=111111111111.dkr.ecr.ap-northeast-1.amazonaws.com/cross-ecr
      - IMAGE_TAG=$(echo $CODEBUILD_RESOLVED_SOURCE_VERSION | cut -c 1-7)

  build:
    commands:
      - mvn clean
      - mvn install
      - docker build -t $REPOSITORY_URI:latest .
      - docker tag $REPOSITORY_URI:latest $REPOSITORY_URI:$IMAGE_TAG

  post_build:
    commands:
      - mvn package
      - docker push $REPOSITORY_URI:latest
      - docker push $REPOSITORY_URI:$IMAGE_TAG
      - printf '{"Version":"1.0","ImageURI":"%s"}' $REPOSITORY_URI:$IMAGE_TAG > imageDetail.json

artifacts:
    files: imageDetail.json

 

以上で設定は完了です。

 

以下は気になったことや躓いたところです

「4、buildspec.ymlファイル修正」で気になったこと

①CodeBuildのどのフォルダで実行されているのか?

「/codebuild/output/src945596495/src」でした。

※「src945596495」は実行するごとに変わります。(たぶん)

②「.awscli-config」の中身はどうなっているのか?

[profile aaa111]
role_arn = arn:aws:iam::111111111111:role/codebuild-role-111111111111
credential_source = EcsContainer

上記の内容のファイルをCode Commit内に用意し、ビルド時にコピーするのもありかな?と思います。

「[profile aaa111]」のprofileを付けないとエラーになります。

③「export」の「=」の前後に空白を入れない

「=」の前後に半角スペースがあったためエラーとなり30分ぐらいあたふたしました。

「export AWS_CONFIG_FILE = ${CODEBUILD_SRC_DIR}/.awscli-config」

AWS関係なく初歩的なミスですね。。

 

【参考サイト】

他のAWSアカウントのECRリポジトリにPush/Pullする - Qiita

CodeBuildのビルド内でAssumeRole(クロスアカウントアクセス)する方法とハマった話 | DevelopersIO

飲食店の確定申告(白色)の手順

いろいろあり、今年(令和4年度)飲食店の確定申告(白色)をやりました。

本当は青色にしようとおもったのですが、まずは白色から。

来年の引継ぎのために書きます。

まずゴール(確定申告に必要な書類)を知って、作成方法とそれまでに準備すること書いていきます。

 

最終的に確定申告に必要な書類

  1. 確定申告書
  2. 収支内訳書(一般用・営業等)
  3. 社会保険料国民健康保険等)控除証明書
  4. 一般の生命保険料、介護医療保険料の支払額などの証明書

自分で作るのは1、2だけ。

3、4は年末ぐらいに郵送されてきます。

 

書類の作成方法

1(確定申告書)、2(収支内訳書)ともに国税庁のサイトから作成できます

https://www.keisan.nta.go.jp/kyoutu/ky/sm/top

収支内訳書の作成

まず、収支内訳書を作成します。

左から2番目の「決算書・収支内訳書(+所得税)」を選択していろいろ入力

収支内訳書

収支内訳書

確定申告書の作成

続いて、確定申告書を作成します。

所得税」を選択していろいろ入力

確定申告書

確定申告書

これを入力した後に所得税の振込ページが出てくるので、印刷してコンビニで所得税を支払います。

所得税の領収書は確定申告に提出する書類には含まれません。

 

以下、ちょっと気を付けるところです。

アは収支内訳書に入力した売上金額を入力し、①は収支内訳書で算出された所得金額を入力します。

 

書類の作成は終わったので、以下の好きな方法で確定申告します。

・税務署に書類を持っていく(簡単な確認はしてくれます)

・郵送する

e-Tax

 

私は不安だったので、税務署に書類を持っていき、確認してもらいました。

税務署にいろいろな経費の領収書など持ってきて、確定申告に必要な資料を1から作成している人もけっこういてビビりました。

 

収支内訳書を作成するまでにやっておくこと

収支内訳書の作成までに売上や経費を算出していれば、

確定申告の70%は終わっているといっても過言ではないです。

やることとしては以下の3つだけです。

1、経費対象のレシートと領収書を保管する

2、売り上げを記録する

  日々の売り上げをExcelなどに記録し、年間売り上げを算出する

3、経費を記録する

  これが一番面倒。。

  レシートや領収書などをExcelなどに記録し、経費を算出する

  以下のような感じに収支内訳書に入力する項目ごとに分けて入力しました

 

税務署で聞いたこと&知ったこと

国民健康保険料、国民年金保険料は控除の対象なのか?

 ⇒ 控除対象で、確定申告書に入力する。

  ※収支内訳書には入力しない(入力するところないですが。。)

  「国民健康保険の控除証明書」は無くても大丈夫で、正しい金額だけ入力

  「国民年金保険料の控除証明書」は必要

・ちょっと相談するだけでもこの行列に並ぶの?

 ⇒並ぶ。書類を作成する人、ちょっとだけ質問したい人、みんな順番待ちして並ぶ。

・LINEで予約しておけば、税務署であまり並ばずに確定申請ができる

 LINE予約を知らなかったので、なんだかんだで1時間ぐらいかかりました。

 2月下旬の平日9時ぐらいに行きました。(会社午前休して。。)

 国税庁のHPにのっていますね。

www.nta.go.jp

 

以下、スクショ。

税務署の確定申告LINE予約

以上になります。

来年は青色申告e-Taxできたら良いな。

分からないことがあれば、LINE予約して税務署に行こう。