關於文AWS-RunPatchBaselineAssociationSSM件 - AWS Systems Manager
AWS-RunPatchBaselineAssociation 參數

本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。

關於文AWS-RunPatchBaselineAssociationSSM件

像 AWS-RunPatchBaseline 文件，AWS-RunPatchBaselineAssociation 在執行個體上執行與安全相關和其他更新類型的修補操作。您還可以使用 AWS-RunPatchBaselineAssociation 文件以套用適用於作業系統和應用程式的修補程式。(在 Windows Server 上，應用程式支援僅限於由 Microsoft 發佈的應用程式更新。)

本文件支援適用於 Linux、macOS和的 Amazon 彈性運算雲端 (AmazonEC2) 執行個體Windows Server。它不支援混合式和多雲端環境中的非EC2節點。此文件會針對每個平台執行適當的動作、在 Linux 和執行個macOS體上叫用 Python 模組，以及 Windows 執行個體上的 PowerShell 模組。

但是，AWS-RunPatchBaselineAssociation 在以下方面不同於 AWS-RunPatchBaseline：

  • AWS-RunPatchBaselineAssociation 主要適用於使用 Quick Setup ( AWS Systems Manager功能) 建立的 State Manager 關聯。尤其是，當您使用 Quick Setup 主機管理組態類型時，如果您選擇 Scan instances for missing patches daily (每天掃描執行個體查看是否遺漏修補程式)，則系統會使用 AWS-RunPatchBaselineAssociation 進行操作。

    不過，在大多數情況下，當設定自己的修補操作時，您應該選擇 AWS-RunPatchBaseline 或 AWS-RunPatchBaselineWithHooks，而不是 AWS-RunPatchBaselineAssociation。

  • 使用 AWS-RunPatchBaselineAssociation 文件時，您可以在文件的 BaselineTags 參數欄位指定標籤金鑰對。如果您 AWS 帳戶 共用這些標記中的自訂修補程式基準Patch Manager，則該功能會在目標執行處理上執行時使用該標記的基準 AWS Systems Manager，而不是作業系統類型目前指定的「預設」修補程式基準。

    重要

    如果您選擇用AWS-RunPatchBaselineAssociation於非使用設定的修補操作Quick Setup，並且想要使用其選用BaselineTags參數，則必須為 Amazon 彈性運算雲端 (AmazonEC2) 執行個體的執行個體設定檔提供一些額外的許可。如需詳細資訊，請參閱參數名稱：BaselineTags。

    以下兩種格式對 BaselineTags 參數都是有效的：

    Key=tag-key,Values=tag-value

    Key=tag-key,Values=tag-value1,tag-value2,tag-value3

  • AWS-RunPatchBaselineAssociation執行時，它收集的修補程式符合性資料會使用PutComplianceItemsAPI命令來記錄，而不是使用PutInventory命令AWS-RunPatchBaseline。這種差異表示根據特定關聯存放和報告的修補程式合規資訊。不會覆寫在此關聯之外產生的修補程式合規資料。

  • 執行 AWS-RunPatchBaselineAssociation 後報告的修補程式合規資訊指出執行個體是否合規。它不包含修補程式層級的詳細資料，如下列 AWS Command Line Interface (AWS CLI) 命令的輸出所示。命令會在 Association 上進行篩選，作為合規類型：

    aws ssm list-compliance-items \
    --resource-ids "i-02573cafcfEXAMPLE" \
    --resource-types "ManagedInstance" \
    --filters "Key=ComplianceType,Values=Association,Type=EQUAL" \
    --region us-east-2

    系統會傳回相關資訊，如下所示。

    {
    "ComplianceItems": [
        {
            "Status": "NON_COMPLIANT", 
            "Severity": "UNSPECIFIED", 
            "Title": "MyPatchAssociation", 
            "ResourceType": "ManagedInstance", 
            "ResourceId": "i-02573cafcfEXAMPLE", 
            "ComplianceType": "Association", 
            "Details": {
                "DocumentName": "AWS-RunPatchBaselineAssociation", 
                "PatchBaselineId": "pb-0c10e65780EXAMPLE", 
                "DocumentVersion": "1"
            }, 
            "ExecutionSummary": {
                "ExecutionTime": 1590698771.0
            }, 
            "Id": "3e5d5694-cd07-40f0-bbea-040e6EXAMPLE"
        }
    ]
}

如果已將標籤金鑰對值指定為 AWS-RunPatchBaselineAssociation 文件的參數，則 Patch Manager 會搜尋符合作業系統類型且已使用該相同標籤金鑰對進行標記的自訂修補基準。此搜尋不限於目前指定的預設修補基準或指派給修補程式群組的基準。如果找不到具有指定標籤的基準線，Patch Manager 接下來會尋找修補程式群組 (如果在執行 AWS-RunPatchBaselineAssociation 的命令中指定了一個)。如果沒有相符的修補程式群組，則 Patch Manager 會回溯至目前作業系統帳戶的預設修補基準。

如果找到一個以上的修補基準，其中包含 AWS-RunPatchBaselineAssociation 文件中指定的標籤，則 Patch Manager 會傳回錯誤訊息，指出只有一個修補基準可以使用該鍵值對標記，以便繼續操作。

注意

在 Linux 執行個體上，會使用每個執行個體類型的適當套件管理工具來安裝套件：

  • Amazon Linux 1、Amazon Linux 2、CentOS 和RHEL執行個體使用YUM。Oracle Linux對於YUM操作，Patch Manager需要Python 2.6或更高版本支持的版本（2.6-3.10）。

  • Debian ServerRaspberry Pi OS、和Ubuntu Server執行個體使用APT。對於APT操作，Patch Manager需要支持的版本Python 3（3.0-3.10）。

  • SUSE Linux Enterprise Server 執行個體使用 Zypper。針對 Zypper 操作，Patch Manager 需要 Python 2.6 或更新版本的支援版本 (2.6 - 3.10)。

在掃描完成後或在所有已核准且適用的更新已安裝後，並視需要重新啟動之後，會在執行個體上產生修補程式合規資訊，並回報修補程式管理員。

注意

如果在 AWS-RunPatchBaselineAssociation 文件中將 RebootOption 參數設定為 NoReboot，則在執行 Patch Manager 後不會重新啟動執行個體。如需詳細資訊，請參閱參數名稱：RebootOption。

如需有關檢視修補程式合規資料的詳細資訊，請參閱關於修補程式合規。

AWS-RunPatchBaselineAssociation 參數

AWS-RunPatchBaselineAssociation 支援四個參數。Operation 和 AssociationId 是必要參數。InstallOverrideList、RebootOption 和 BaselineTags 是選用參數。

參數名稱：Operation

用量：必要。

選項：Scan | Install。

Scan

當您選擇 Scan 選項時，AWS-RunPatchBaselineAssociation 會判斷執行個體的修補程式合規狀態，並將此資訊回報至 Patch Manager。Scan 不會提示要安裝的更新或需要重新啟動的執行個體。反之，此操作會識別遺漏哪些已核准且適用於執行個體的更新。

安裝

當您選擇 Install 選項，AWS-RunPatchBaselineAssociation 會嘗試安裝執行個體上遺漏的已核准且適用的更新。在 Install 操作中產生的修補程式合規資訊不會列出任何遺失的更新，但如果因為任何原因導致未成功安裝更新，則可能會報告狀態為失敗的更新。每當更新安裝於執行個體時，執行個體將重新啟動，以確保安裝並啟動更新。(例外：如果 AWS-RunPatchBaselineAssociation 文件中的 RebootOption 參數設為 NoReboot，執行個體不會在 Patch Manager 執行之後重新啟動。如需詳細資訊，請參閱 參數名稱：RebootOption。)

注意

如果在 Patch Manager 更新執行個體之前已安裝基準規則指定的修補程式，系統可能無法如預期重新開機。當使用者手動安裝修補程式，或由其他程式自動安裝 (例如 Ubuntu Server 上的 unattended-upgrades 套件) 時，就會發生這種情況。

參數名稱：BaselineTags

用量：選用。

BaselineTags 是唯一的標籤鍵值對，您可以選擇並指派給個別自訂修補基準。您可以為此參數指定一或多個值。以下兩種格式都是有效的：

Key=tag-key,Values=tag-value

Key=tag-key,Values=tag-value1,tag-value2,tag-value3

BaselineTags 值是 Patch Manager 使用的唯一 ID (GUID)，確保在單一操作中修補的一組執行個體皆有一組完全相同的核准修補程式。修補操作執行時，Patch Manager 會檢查作業系統類型的修補基準是否已使用您為 BaselineTags 指定的相同鍵值對進行標記。如果有相符項目，則會使用此自訂修補基準。如果沒有相符項目，則會根據針對修補操作指定的任何修補程式群組來識別修補基準。如果沒有，則會使用該作業系統的 AWS 受管理預先定義修補程式基準。

額外的許可要求

如果您用AWS-RunPatchBaselineAssociation於非使用設定的修補操作Quick Setup，並且想要使用選用BaselineTags參數，則必須將以下許可新增至 Amazon 彈性運算雲端 (AmazonEC2) 執行個體的執行個體設定檔。

注意

Quick Setup並且AWS-RunPatchBaselineAssociation不支援內部部署伺服器和虛擬機器 (VMs)。

{
    "Effect": "Allow",
    "Action": [
        "ssm:DescribePatchBaselines",
        "tag:GetResources"
    ],
    "Resource": "*"
},
{
    "Effect": "Allow",
    "Action": [
        "ssm:GetPatchBaseline",
        "ssm:DescribeEffectivePatchesForPatchBaseline"
    ],
    "Resource": "patch-baseline-arn"
}

Replace (取代) patch-baseline-arn 使用您要提供存取權的修補程式基準的 Amazon 資源名稱 (ARN)，格式為arn:aws:ssm:us-east-2:123456789012:patchbaseline/pb-0c10e65780EXAMPLE。

參數名稱：AssociationId

用量：必要。

AssociationId 是 State Manager ( AWS Systems Manager功能) 中的現有關聯 ID。它由 Patch Manager 使用，將合規資料新增至指定的關聯。此關聯與在 Quick Setup 中建立的主機管理組態中啟用的修補程式 Scan 操作有關。藉由傳送修補結果作為關聯規範遵循資料而非庫存相容性資料，在修補作業之後，不會覆寫執行個體的現有庫存符合性資訊，也不會覆寫其他關聯IDs。如果您還沒有想要使用的關聯，則可以透過執行 create-association 命令建立關聯。例如：

Linux & macOS
aws ssm create-association \
    --name "AWS-RunPatchBaselineAssociation" \
    --association-name "MyPatchHostConfigAssociation" \
    --targets "Key=instanceids,Values=[i-02573cafcfEXAMPLE,i-07782c72faEXAMPLE,i-07782c72faEXAMPLE]" \
    --parameters "Operation=Scan" \
    --schedule-expression "cron(0 */30 * * * ? *)" \
    --sync-compliance "MANUAL" \
    --region us-east-2
Windows Server
aws ssm create-association ^
    --name "AWS-RunPatchBaselineAssociation" ^
    --association-name "MyPatchHostConfigAssociation" ^
    --targets "Key=instanceids,Values=[i-02573cafcfEXAMPLE,i-07782c72faEXAMPLE,i-07782c72faEXAMPLE]" ^
    --parameters "Operation=Scan" ^
    --schedule-expression "cron(0 */30 * * * ? *)" ^
    --sync-compliance "MANUAL" ^
    --region us-east-2

參數名稱：InstallOverrideList

用量：選用。

使用時InstallOverrideList，您可以URL為要安裝的修補程式清單指定 https URL 或 Amazon 簡單儲存服務 (Amazon S3) 路徑樣式。此修補程式安裝清單 (以YAML格式維護) 會覆寫目前預設修補程式基準指定的修補程式。這可讓您更精密地控制哪些修補程式將安裝於您的執行個體。

Linux 與macOS受管理節點以及受管理節點之間，使用InstallOverrideList參數時的修補作業行為會有所不同。Windows Server在 Linux & 上macOS，無論修補程式是否符合修InstallOverrideList補程式基準規則，都會Patch Manager嘗試套用包含在節點上啟用之任何存放庫中的修補程式清單中。但是，在Windows Server節點上，只有當修補程式清單中的修InstallOverrideList補程式也符合修補程式基準規則時，才會套用這些修補程

請注意，合規報告根據修補基準中的指定來反映修補程式狀態，而非您在 InstallOverrideList 合規清單中的指定。換言之，掃描操作會忽略 InstallOverrideList 參數。這是為了確保合規報告根據政策而非已核准用於特定修補操作的內容，來持續反映修補程式狀態。

有效URL格式

注意

如果您的檔案存放在公開可用的儲存貯體中，您可以指定 https URL 格式或 Amazon S3 路徑樣式URL。如果您的檔案存放在私有儲存貯體中，則必須指定 Amazon S3 路徑樣式URL。

  • https URL 格式範例：

    https://s3.amazonaws.com/amzn-s3-demo-bucket/my-windows-override-list.yaml

  • Amazon S3 路徑樣式URL示例：

    s3://amzn-s3-demo-bucket/my-windows-override-list.yaml

有效的YAML內容格式

您用於在清單中指定修補程式的格式，取決於您執行個體使用的作業系統。一般格式如下：

patches:
    - 
        id: '{patch-d}'
        title: '{patch-title}'
        {additional-fields}:{values}

雖然您可以在YAML檔案中提供其他欄位，但在修補程式作業期間會忽略這些欄位。

此外，我們建議您在 S3 儲存貯體中新增或更新清單之前，先確認YAML檔案格式是否有效。如需有關此YAML格式的詳細資訊，請參閱 yaml.org。有關驗證工具的選項，請執行 Web 搜尋「yaml 格式驗證工具」。

  • Microsoft Windows

    id

    id 欄位是必要的。使用它來指定使用 Microsoft 知識庫 IDs (例如KB2736693) 和 Microsoft 資訊安全佈告欄 IDs (例如 MS17 -023) 的修補程式。

    您想在 Windows 修補程式清單中提供的任何其他欄位都是選用的，並僅供自己參考。您可以使用其他欄位，例如標題、分類、嚴重性等，提供有關指定的修補程式的更多詳細資訊。

  • Linux

    id

    id 欄位是必要的。利用它來使用套件名稱和架構以指定修補程式。例如：'dhclient.x86_64'。您可以在 id 中使用萬用字元以指示多個套件。例如：'dhcp*' 和 'dhcp*1.*'。

    標題

    標題欄位是選用的，但是在 Linux 系統上，它提供額外的篩選功能。如果您使用標題，它應包含套件版本資訊，並使用以下其中一種格式：

    YUM/SUSE Linux Enterprise Server (SLES):

    {name}.{architecture}:{epoch}:{version}-{release}

    APT

    {name}.{architecture}:{version}

    對於 Linux 修補程式標題，您可以在任何位置使用一或多個萬用字元以擴大相符套件的數量。例如：'*32:9.8.2-0.*.rc1.57.amzn1'。

    例如：

    • apt 套件版本 1.2.25 目前已安裝於您的執行個體上，但現在有 1.2.27 可用。

    • 您將 apt.amd64 版本 1.2.27 新增至修補程式清單。它取決於 apt utils.amd64 版本 1.2.27，但清單中指定的是 apt-utils.amd64 版本 1.2.25。

    在這種情況下，apt 版本 1.2.27 將被阻止安裝，並報告為「失敗-NonCompliant」。

其他欄位

您想在 Linux 修補程式清單中提供的任何其他欄位都是選用的，並僅供自己參考。您可以使用其他欄位，例如分類、嚴重性等，提供有關指定的修補程式的更多詳細資訊。

範例修補程式清單

  • Windows

    patches:
    -
        id: 'KB4284819'
        title: '2018-06 Cumulative Update for Windows Server 2016 (1709) for x64-based Systems (KB4284819)'
    -
        id: 'KB4284833'
    -
        id: 'KB4284835'
        title: '2018-06 Cumulative Update for Windows Server 2016 (1803) for x64-based Systems (KB4284835)'
    -
        id: 'KB4284880'
    -
        id: 'KB4338814'

  • APT

    patches:
    -
        id: 'apparmor.amd64'
        title: '2.10.95-0ubuntu2.9'
    -
        id: 'cryptsetup.amd64'
        title: '*2:1.6.6-5ubuntu2.1'
    -
        id: 'cryptsetup-bin.*'
        title: '*2:1.6.6-5ubuntu2.1'
    -
        id: 'apt.amd64'
        title: '*1.2.27'
    -
        id: 'apt-utils.amd64'
        title: '*1.2.25'

  • Amazon Linux

    patches:
    -
        id: 'kernel.x86_64'
    -
        id: 'bind*.x86_64'
        title: '32:9.8.2-0.62.rc1.57.amzn1'
    -
        id: 'glibc*'
    -
        id: 'dhclient*'
        title: '*12:4.1.1-53.P1.28.amzn1'
    -
        id: 'dhcp*'
        title: '*10:3.1.1-50.P1.26.amzn1'

  • Red Hat Enterprise Linux (RHEL)

    patches:
    -
        id: 'NetworkManager.x86_64'
        title: '*1:1.10.2-14.el7_5'
    -
        id: 'NetworkManager-*.x86_64'
        title: '*1:1.10.2-14.el7_5'
    -
        id: 'audit.x86_64'
        title: '*0:2.8.1-3.el7'
    -
        id: 'dhclient.x86_64'
        title: '*.el7_5.1'
    -
        id: 'dhcp*.x86_64'
        title: '*12:5.2.5-68.el7'

  • SUSE Linux Enterprise Server (SLES)

    patches:
    -
        id: 'amazon-ssm-agent.x86_64'
    -
        id: 'binutils'
        title: '*0:2.26.1-9.12.1'
    -
        id: 'glibc*.x86_64'
        title: '*2.19*'
    -
        id: 'dhcp*'
        title: '0:4.3.3-9.1'
    -
        id: 'lib*'

  • Ubuntu Server 

    patches:
    -
        id: 'apparmor.amd64'
        title: '2.10.95-0ubuntu2.9'
    -
        id: 'cryptsetup.amd64'
        title: '*2:1.6.6-5ubuntu2.1'
    -
        id: 'cryptsetup-bin.*'
        title: '*2:1.6.6-5ubuntu2.1'
    -
        id: 'apt.amd64'
        title: '*1.2.27'
    -
        id: 'apt-utils.amd64'
        title: '*1.2.25'

  • Windows

    patches:
    -
        id: 'KB4284819'
        title: '2018-06 Cumulative Update for Windows Server 2016 (1709) for x64-based Systems (KB4284819)'
    -
        id: 'KB4284833'
    -
        id: 'KB4284835'
        title: '2018-06 Cumulative Update for Windows Server 2016 (1803) for x64-based Systems (KB4284835)'
    -
        id: 'KB4284880'
    -
        id: 'KB4338814'

參數名稱：RebootOption

用量：選用。

選項：RebootIfNeeded | NoReboot

預設：RebootIfNeeded

警告

預設選項為 RebootIfNeeded。請務必選取適用於您使用案例的正確選項。例如，如果您的執行個體必須立即重新啟動才能完成組態程序，則請選擇 RebootIfNeeded。或者，如果您需要維持執行個體的可用性，直到排定的重新啟動時間，則請選擇 NoReboot。

重要

我們不建議使Patch Manager用修補 Amazon 中的叢集執行個體 EMR (先前稱為 Amazon 彈性 MapReduce)。特別是，請勿為 RebootOption 參數選取 RebootIfNeeded 選項。(此選項可在用於修補AWS-RunPatchBaseline、和的 SSM Command 文件AWS-RunPatchBaselineAssociation中使用AWS-RunPatchBaselineWithHooks。)

使用 Patch Manager 進行修補時所使用的基礎命令使用 yum 和 dnf 命令。因此，相關操作會因套件的安裝方式而導致不相容。如需在 Amazon EMR 叢集上更新軟體的偏好方法的相關資訊，請參閱 Amazon EMR管理指南EMR中的使用 Amazon 預設值AMI。

RebootIfNeeded

當您選擇 RebootIfNeeded 選項時，執行個體在下列情況下會重新開機：

  • Patch Manager 已安裝一或多個修補程式。

    Patch Manager 不會評估修補程式是否需要重新開機。即使修補程式不需要重新開機，系統也會重新開機。

  • Patch Manager 偵測到一或多個修補程式在 Install 操作期間狀態為 INSTALLED_PENDING_REBOOT。

    Patch Manager此INSTALLED_PENDING_REBOOT狀態可能表示上次執行Install作業時已選取該選項NoReboot，或是自上次受管理節點重新啟動後已安裝在以外的地方。

在這兩種情況下重新開機執行個體，可確保更新的套件會從記憶體中清除，並在所有作業系統中保持修補和重新開機行為一致。

NoReboot

當您選擇 NoReboot 選項時，即使執行個體在 Install 作業期間安裝了修補程式，Patch Manager 也不會重新啟動執行個體。如果您知道您的執行個體在套用修補程式之後不需要重新啟動，或是您在執行個體上執行的應用程式或程序不應因於修補操作重新啟動而中斷，則此選項非常有用。當您想要進一步控制執行個體重新啟動的時間時 (例如使用維護時段)，此選項也很有用。

修補程式安裝追蹤檔案：若要追蹤修補程式安裝，特別是自上次系統重新啟動後已安裝的修補程式，Systems Manager 會在受管執行個體上維護檔案。

重要

請勿刪除或修改追蹤檔案。如果此檔案已刪除或損毀，則執行個體的修補程式合規報告會不正確。如果發生此情況，請重新啟動執行個體並執行修補程式掃描作業以還原檔案。

此追蹤檔案存放於受管執行個體的下列位置：

  • Linux 作業系統：

    • /var/log/amazon/ssm/patch-configuration/patch-states-configuration.json

    • /var/log/amazon/ssm/patch-configuration/patch-inventory-from-last-operation.json

  • Windows Server 作業系統：

    • C:\ProgramData\Amazon\PatchBaselineOperations\State\PatchStatesConfiguration.json

    • C:\ProgramData\Amazon\PatchBaselineOperations\State\PatchInventoryFromLastOperation.json