Menerapkan dan menegakkan penandaan

Di bagian ini, kami akan memperkenalkan Anda pada alat yang tersedia untuk strategi manajemen sumber daya berikut: manual, infrastruktur sebagai kode (IAc), dan integrasi berkelanjutan/pengiriman berkelanjutan (CI/CD). Dimensi kunci untuk pendekatan ini adalah tingkat penyebaran yang semakin sering.

Sumber daya yang dikelola secara manual

Ini biasanya beban kerja yang termasuk dalam dasar atau tahap migrasi adopsi. Seringkali, ini adalah beban kerja statis sederhana yang telah dibangun menggunakan prosedur tertulis tradisional atau yang dimigrasi seperti menggunakan alat seperti CloudEndure dari lingkungan lokal. Alat migrasi, seperti Migration Hub dan CloudEndure, dapat menerapkan tag sebagai bagian dari proses migrasi. Namun, jika tag tidak diterapkan selama migrasi asli atau skema penandaan telah berubah sejak saat itu, Editor Tag (fitur dari AWS Management Console) memungkinkan Anda untuk mencari sumber daya menggunakan berbagai kriteria pencarian dan menambah, memodifikasi, atau menghapus tag secara massal. Kriteria pencarian dapat mencakup sumber daya dengan atau tanpa kehadiran tag atau nilai tertentu. AWS Resource Tagging API memungkinkan Anda menjalankan fungsi-fungsi ini secara terprogram.

Karena beban kerja ini dimodernisasi, jenis sumber daya seperti grup Auto Scaling diperkenalkan. Jenis sumber daya ini memungkinkan elastisitas yang lebih besar dan ketahanan yang lebih baik. Grup penskalaan otomatis mengelola instans Amazon EC2 atas nama Anda, namun, Anda mungkin masih ingin instans EC2 diberi tag secara konsisten dengan sumber daya yang dibuat secara manual. Template peluncuran Amazon EC2 menyediakan sarana untuk menentukan tag yang harus diterapkan Auto Scaling ke instance yang dibuatnya.

Ketika sumber daya beban kerja dikelola secara manual, akan sangat membantu untuk mengotomatiskan penandaan sumber daya. Ada berbagai solusi yang tersedia. Salah satu pendekatannya adalah dengan menggunakan Aturan AWS Config, yang dapat memeriksa required_tags dan kemudian memulai fungsi Lambda untuk menerapkannya. Aturan AWS Config dijelaskan secara lebih rinci nanti di whitepaper ini.

Sumber daya yang dikelola Infrastruktur sebagai kode (IAc)

AWS CloudFormation menyediakan bahasa umum untuk menyediakan semua sumber daya infrastruktur di lingkungan Anda AWS . CloudFormation template adalah file JSON atau YAMAL yang membuat AWS sumber daya secara otomatis. Saat membuat AWS sumber daya menggunakan CloudFormation templat, Anda dapat menggunakan properti Tag CloudFormation Sumber Daya untuk menerapkan tag ke jenis sumber daya yang didukung saat pembuatan. Mengelola tag serta sumber daya dengan IAc membantu memastikan konsistensi.

Ketika sumber daya dibuat oleh AWS CloudFormation, layanan secara otomatis menerapkan satu set tag yang AWS ditentukan ke sumber daya yang dibuat oleh AWS CloudFormation template. Ini adalah:

aws:cloudformation:stack-name
aws:cloudformation:stack-id
aws:cloudformation:logical-id

Anda dapat dengan mudah menentukan grup sumber daya berdasarkan AWS CloudFormation tumpukan. Tag AWS yang ditentukan ini diwarisi oleh sumber daya yang dibuat oleh tumpukan. Namun, untuk instans Amazon EC2 dalam grup Auto Scaling, AWS::AutoScaling::AutoScalingGroup TagPropertyperlu diatur dalam definisi grup Auto Scaling di template Anda. AWS CloudFormation Atau, jika Anda menggunakan Template Peluncuran EC2 dengan grup Auto Scaling maka Anda dapat menentukan tag dalam definisinya. Dianjurkan untuk menggunakan Template Peluncuran EC2 dengan grup Auto Scaling atau dengan AWS layanan kontainer. Layanan ini dapat membantu memastikan penandaan instans Amazon EC2 Anda secara konsisten dan juga mendukung Auto Scaling di Beberapa Jenis Instans & Opsi Pembelian, yang dapat meningkatkan ketahanan dan mengoptimalkan biaya komputasi Anda.

AWS CloudFormation Hooks menyediakan pengembang dengan sarana untuk menjaga aspek-aspek kunci dari aplikasi mereka konsisten dengan standar organisasi mereka. Hooks dapat dikonfigurasi untuk memberikan peringatan atau mencegah penyebaran. Fitur ini paling cocok untuk memeriksa elemen konfigurasi utama dalam template Anda, seperti apakah grup Auto Scaling dikonfigurasi untuk menerapkan tag yang ditentukan pelanggan ke semua instans Amazon EC2 yang akan diluncurkan, atau untuk memastikan bahwa semua bucket Amazon S3 dibuat dengan pengaturan enkripsi yang diperlukan. Dalam kedua kasus tersebut, evaluasi kepatuhan ini didorong ke proses penerapan sebelumnya dengan AWS CloudFormation kait sebelum penerapan.

AWS CloudFormation menyediakan kemampuan untuk mendeteksi ketika sumber daya (lihat Sumber daya yang mendukung deteksi drift) yang disediakan dari templat telah dimodifikasi dan sumber daya tidak lagi cocok dengan konfigurasi templat yang diharapkan. Ini dikenal sebagai drift. Jika Anda menggunakan otomatisasi untuk menerapkan tag ke sumber daya yang dikelola melalui IAc, maka Anda memodifikasinya, memperkenalkan drift. Saat menggunakan IAc, saat ini disarankan untuk mengelola persyaratan penandaan apa pun sebagai bagian dari templat IAc, menerapkan AWS CloudFormation kait, dan menerbitkan kumpulan aturan AWS CloudFormation Guard yang dapat digunakan oleh otomatisasi.

Sumber daya terkelola pipa CI/CD

Ketika kematangan beban kerja meningkat, kemungkinan teknik seperti integrasi berkelanjutan dan penerapan berkelanjutan (CI/CD) diadopsi. Teknik-teknik ini membantu mengurangi risiko penyebaran dengan membuatnya lebih mudah untuk menerapkan perubahan kecil lebih sering dengan peningkatan otomatisasi pengujian. Strategi observabilitas yang mendeteksi perilaku tak terduga yang diperkenalkan oleh penerapan dapat secara otomatis memutar kembali penerapan dengan dampak pengguna minimal. Ketika Anda mencapai tahap penyebaran puluhan kali sehari, menerapkan tag secara surut tidak lagi praktis. Semuanya perlu dinyatakan sebagai kode atau konfigurasi, dikontrol versi, dan, sedapat mungkin, diuji dan dievaluasi sebelum penerapan ke dalam produksi. Dalam model pengembangan dan operasi (DevOps) gabungan, banyak praktik membahas pertimbangan operasional sebagai kode dan memvalidasinya di awal siklus hidup penerapan.

Idealnya, Anda ingin mendorong pemeriksaan ini sedini mungkin dalam proses (seperti yang ditunjukkan dengan AWS CloudFormation kait), sehingga Anda dapat yakin bahwa AWS CloudFormation template Anda memenuhi kebijakan Anda sebelum mereka meninggalkan mesin pengembang.

AWS CloudFormation Guard 2.0 menyediakan sarana untuk menulis aturan kepatuhan preventif untuk apa pun yang dapat Anda definisikan. CloudFormation Template divalidasi terhadap aturan di lingkungan pengembangan. Jelas, fitur ini memiliki berbagai aplikasi, tetapi dalam whitepaper ini, kita hanya akan melihat beberapa contoh yang akan memastikan selalu AWS::AutoScaling::AutoScalingGroup TagPropertydigunakan.

Berikut ini adalah contoh aturan CloudFormation Penjaga:

let all_asgs = Resources.*[ Type == 'AWS::AutoScaling::AutoScalingGroup' ]

rule tags_asg_automation_EnvironmentId when %all_asgs !empty {
    let required_tags = %all_asgs.Properties.Tags.*[ 
        Key == 'example-inc:automation:EnvironmentId' ] 
    %required_tags[*] {
        PropagateAtLaunch == 'true'
        Value IN ['Prod', 'Dev', 'Test', 'Sandbox']
        <<Tag must have a permitted value
          Tag must have PropagateAtLaunch set to 'true'>>
    }
}

rule tags_asg_costAllocation_CostCenter when %all_asgs !empty {
    let required_tags = %all_asgs.Properties.Tags.*[ 
        Key == 'example-inc:cost-allocation:CostCenter' ]
    %required_tags[*] {
        PropagateAtLaunch == 'true'
        Value == /^123-/
        <<Tag must have a permitted value
          Tag must have PropagateAtLaunch set to 'true'>>
    }
}

Dalam contoh kode, kami memfilter template untuk semua sumber daya yang berjenisAutoScalingGroup, dan kemudian memiliki dua aturan:

• tags_asg_automation_EnvironmentId- Memeriksa bahwa tag dengan kunci ini ada, memiliki nilai dalam daftar nilai yang diizinkan, dan PropagateAtLaunch itu diatur ke true

• tags_asg_costAllocation_CostCenter- Memeriksa bahwa tag ada dengan kunci ini, memiliki nilai yang dimulai dengan nilai awalan yang ditentukan, dan yang PropagateAtLaunch diatur ke true

Penegakan

Seperti dijelaskan sebelumnya, Resource Groups & Tag Editor menyediakan sarana untuk mengidentifikasi di mana sumber daya Anda gagal memenuhi persyaratan penandaan yang ditentukan dalam kebijakan tag yang diterapkan pada OU organisasi. Mengakses alat konsol Resource Groups & Tag Editor dari dalam akun anggota Organisasi menunjukkan kepada Anda kebijakan yang berlaku untuk akun tersebut dan sumber daya dalam akun yang gagal memenuhi persyaratan kebijakan tag. Jika diakses dari akun manajemen (dan jika kebijakan Tag mengaktifkan Akses di layanan di bawah AWS Organizations), Anda dapat melihat kepatuhan kebijakan tag untuk semua akun tertaut di organisasi.

Dalam Kebijakan Tag itu sendiri, Anda dapat mengaktifkan penegakan untuk jenis sumber daya tertentu. Dalam contoh kebijakan berikut, kami telah menambahkan penegakan hukum sehingga semua jenis sumber daya ec2:instance dan ec2:volume harus mematuhi kebijakan. Ada beberapa batasan yang diketahui, seperti harus ada tag pada sumber daya agar dapat dievaluasi oleh kebijakan tag. Lihat Sumber daya yang mendukung penegakan dengan kebijakan tag untuk daftar.

ExampleInc-Alokasi biaya.json

Berikut ini adalah contoh kebijakan tag yang melaporkan dan/atau memberlakukan tag Alokasi Biaya:

{
  "tags": {
    "example-inc:cost-allocation:ApplicationId": {
      "tag_key": {
        "@@assign": "example-inc:cost-allocation:ApplicationId"
      },
      "tag_value": {
        "@@assign": [
          "DataLakeX",
          "RetailSiteX"
        ]
      },
      "enforced_for": {
        "@@assign": [
          "ec2:instance",
          "ec2:volume"
        ]
      }
    },
    "example-inc:cost-allocation:BusinessUnitId": {
      "tag_key": {
        "@@assign": "example-inc:cost-allocation:BusinessUnitId"
      },
      "tag_value": {
        "@@assign": [
          "Architecture",
          "DevOps",
          "FinanceDataLakeX"
        ]
      },
      "enforced_for": {
        "@@assign": [
          "ec2:instance",
          "ec2:volume"
        ]
      }
    },
    "example-inc:cost-allocation:CostCenter": {
      "tag_key": {
        "@@assign": "example-inc:cost-allocation:CostCenter"
      },
      "tag_value": {
        "@@assign": [
          "123-*"
        ]
      },
      "enforced_for": {
        "@@assign": [
          "ec2:instance",
          "ec2:volume"
        ]
      }
    }
  }
}

AWS Config (required_tag)

AWS Config adalah layanan yang memungkinkan Anda menilai, mengaudit, dan mengevaluasi konfigurasi AWS sumber daya Anda (lihat Jenis sumber daya yang didukung oleh AWS Config). Dalam kasus penandaan, kita dapat menggunakannya untuk mengidentifikasi sumber daya yang tidak memiliki tag dengan kunci tertentu, menggunakan required_tags aturan (lihat tipe Sumber daya yang didukung oleh required_tags). Dari contoh sebelumnya, kami mungkin menguji keberadaan kunci pada semua instans Amazon EC2. Dalam kasus di mana kunci tidak ada, instance akan terdaftar sebagai tidak sesuai. AWS CloudFormation Template ini menjelaskan AWS Config Aturan untuk menguji keberadaan kunci wajib yang dijelaskan dalam tabel, di bucket Amazon S3, instans Amazon EC2, dan volume Amazon EBS.

 Resources:
  MandatoryTags:
    Type: AWS::Config::ConfigRule
    Properties:
      ConfigRuleName: ExampleIncMandatoryTags
      Description: These tags should be in place
      InputParameters:
        tag1Key: example-inc:cost-allocation:ApplicationId
        tag2Key: example-inc:cost-allocation:BusinessUnitId
        tag3Key: example-inc:cost-allocation:CostCenter
        tag4Key: example-inc:automation:EnvironmentId
      Scope:
        ComplianceResourceTypes:
        - "AWS::S3::Bucket"
        - "AWS::EC2::Instance"
        - "AWS::EC2::Volume"
      Source:
        Owner: AWS
SourceIdentifier: REQUIRED_TAGS

Untuk lingkungan di mana sumber daya dikelola secara manual, AWS Config aturan dapat ditingkatkan untuk secara otomatis menambahkan kunci tag yang hilang ke sumber daya menggunakan remediasi otomatis melalui AWS Lambda fungsi. Meskipun ini berfungsi dengan baik untuk beban kerja statis, ini semakin kurang efektif saat Anda mulai mengelola sumber daya Anda melalui IAc dan pipeline penerapan.

AWS Organizations Kebijakan kontrol layanan (SCP) adalah jenis kebijakan organisasi yang dapat Anda gunakan untuk mengelola izin di organisasi Anda. SCP menawarkan kontrol pusat atas izin maksimum yang tersedia untuk semua akun di organisasi atau unit organisasi (OU) Anda. SCP hanya memengaruhi pengguna dan peran yang dikelola oleh akun yang merupakan bagian dari organisasi. Meskipun mereka tidak memengaruhi sumber daya secara langsung, mereka membatasi izin pengguna dan peran yang mencakup izin untuk tindakan penandaan. Sehubungan dengan penandaan, SCP dapat memberikan perincian tambahan untuk penegakan tag serta kebijakan tag apa yang dapat disediakan.

Dalam contoh berikut, kebijakan akan menolak ec2:RunInstances permintaan di mana example-inc:cost-allocation:CostCenter tag tidak ada.

Berikut ini adalah penolakan SCP:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyRunInstanceWithNoCostCenterTag",
      "Effect": "Deny",
      "Action": "ec2:RunInstances",
      "Resource": [
        "arn:aws:ec2:*:*:instance/"
      ],
      "Condition": {
        "Null": {
          "aws:RequestTag/example-inc:cost-allocation:CostCenter": "true"
        }
      }
    }
  ]
}

Tidak mungkin untuk mengambil kebijakan kontrol layanan efektif yang berlaku untuk akun tertaut berdasarkan desain. Jika Anda menerapkan penandaan dengan SCP, dokumentasi harus tersedia bagi pengembang sehingga mereka dapat memastikan sumber daya mereka memenuhi kebijakan yang telah diterapkan ke akun mereka. Memberikan akses hanya baca ke CloudTrail acara dalam akun mereka dapat mendukung pengembang dalam tugas debugging ketika sumber daya mereka gagal mematuhi.