使用 Terraform AWS Provider 查询 Lambda Code Signing Config 数据源配置项、属性与源码实现解析【免费下载链接】terraform-provider-awsThe AWS Provider enables Terraform to manage AWS resources.项目地址: https://gitcode.com/GitHub_Trending/te/terraform-provider-aws导读aws_lambda_code_signing_config是 Terraform AWS Provider 提供的一个只读数据源Data Source用于按 ARN 检索已有的 AWS Lambda 代码签名配置Code Signing Config从而获取其允许的签名发布者Allowed Publishers、签名策略Code Signing Policies等元数据为 Lambda 函数的代码完整性与真实性校验提供依据。读完本文你将掌握该数据源的参数与导出属性、四种典型实战用法基础查询、函数绑定、签名档案校验、多环境对比并理解其背后的 AWS API 调用链与 Provider 源码实现。数据源概览它解决了什么问题Lambda 代码签名功能允许组织要求部署到 Lambda 的所有代码都必须由受信任的签名方签名从而防止未经验证的代码被部署。aws_lambda_code_signing_config数据源正面向已有配置的查询场景你不需要在 Terraform 中重新创建配置只需要提供其 ARN即可读取配置详情供其他资源尤其是aws_lambda_function引用。该数据源的官方文档位于 website/docs/d/lambda_code_signing_config.html.markdown核心实现在 code_signing_config_data_source.go 中。数据源与资源的关系本数据源与托管配置的aws_lambda_code_signing_config资源实现在 code_signing_config.go相互配合资源负责创建/更新/删除数据源负责按 ARN 读取既有配置。二者共用同一套findCodeSigningConfigByARN查找逻辑保证读到的数据与实际状态一致。参数Argument Reference数据源的入参非常简单arn-必填代码签名配置的 ARN。在 code_signing_config_data_source.go 中该字段为Required: true且通过verify.ValidARN校验 ARN 格式非法 ARN 会在plan阶段直接报错而不是等到调用 AWS API 时才发现。region-可选资源所在区域默认使用 Provider 配置中设置的区域即当前 Provider 的默认 Region。其中region参数与 AWS 的区域级端点解析机制相关适合需要跨区域查询配置的场景不指定时则跟随 Provider 的全局配置。导出属性Attribute Reference除了上述参数外数据源还导出以下只读属性均为Computed: true属性类型说明allowed_publishers列表List允许的发布者列表即被允许作为本配置签名方的签名档案Signing Profiles详见下方 allowed_publishers 块config_id字符串代码签名配置的唯一标识符形如csc-xxxxxxxxdescription字符串代码签名配置的描述信息last_modified字符串配置最后修改的日期与时间policies列表List控制签名不匹配或过期时校验失败动作的代码签名策略详见下方 policies 块allowed_publishers块signing_profile_version_arns- 一个字符串集合Set包含每个签名档案的 ARN。签名档案Signing Profile定义了谁是被信任的、可以给代码包签名的人。在源码中该字段被建模为TypeSetcode_signing_config_data_source.goTerraform 会将其作为集合去重处理因此通过[0].signing_profile_version_arns索引访问即可获得完整集合。policies块untrusted_artifact_on_deployment- 部署校验失败时采取的策略合法值为Warn仅告警允许部署与Enforce强制拦截拒绝部署。在资源侧code_signing_config.go该字段通过enum.Validate[awstypes.CodeSigningPolicy]()校验与 AWS SDK 的枚举类型强绑定因此传入非法值会在校验阶段被拒绝。典型用法1. 基础用法按 ARN 查询配置并导出详情data aws_lambda_code_signing_config example { arn arn:aws:lambda:us-west-2:123456789012:code-signing-config:csc-0f6c334abcdea4d8b } output config_details { value { config_id data.aws_lambda_code_signing_config.example.config_id description data.aws_lambda_code_signing_config.example.description policy data.aws_lambda_code_signing_config.example.policies[0].untrusted_artifact_on_deployment } }policies[0].untrusted_artifact_on_deployment的索引写法基于配置恰好包含一个策略块的事实资源侧policies块被限制为MaxItems: 1因此数据源返回的列表至多包含一个元素。2. 在 Lambda 函数中使用绑定代码签名配置将数据源查询到的 ARN 直接传给aws_lambda_function的code_signing_config_arn参数即可让新创建的 Lambda 函数强制启用代码签名# 获取已存在的代码签名配置 data aws_lambda_code_signing_config security_config { arn var.code_signing_config_arn } # 创建启用代码签名的 Lambda 函数 resource aws_lambda_function example { filename function.zip function_name secure-function role aws_iam_role.lambda_role.arn handler index.handler runtime nodejs24.x code_signing_config_arn data.aws_lambda_code_signing_config.security_config.arn tags { Environment production Security code-signed } }从源码看aws_lambda_function的code_signing_config_arn参数在 function.go 中被定义为Optional且经过verify.ValidARN校验。创建函数时该值会被写入CreateFunction请求的CodeSigningConfigArn字段function.go如果函数创建后才变更该属性Provider 会在更新阶段调用PutFunctionCodeSigningConfig或DeleteFunctionCodeSigningConfigAPI 完成绑定与解绑function.go读取阶段则通过GetFunctionCodeSigningConfig回填状态function.go。3. 校验签名档案条件化部署在部署前动态校验目标签名档案是否被当前配置允许只有允许时才创建函数data aws_lambda_code_signing_config example { arn var.code_signing_config_arn } # 检查指定签名档案是否被允许 locals { allowed_profiles data.aws_lambda_code_signing_config.example.allowed_publishers[0].signing_profile_version_arns required_profile arn:aws:signer:us-west-2:123456789012:/signing-profiles/MyProfile profile_allowed contains(local.allowed_profiles, local.required_profile) } # 根据签名档案校验结果条件化创建资源 resource aws_lambda_function conditional { count local.profile_allowed ? 1 : 0 filename function.zip function_name conditional-function role aws_iam_role.lambda_role.arn handler index.handler runtime python3.12 code_signing_config_arn data.aws_lambda_code_signing_config.example.arn } output deployment_status { value { profile_allowed local.profile_allowed function_created local.profile_allowed message local.profile_allowed ? Function deployed with valid signing profile : Deployment blocked - signing profile not allowed } }这里的核心技巧是contains(local.allowed_profiles, local.required_profile)由于signing_profile_version_arns底层是集合Set类型Terraform 的contains函数可以可靠地执行成员判断从而把配置权限校验变成基础设施即代码中的一等公民。4. 多环境配置对比生产与开发环境通常使用不同的签名配置可以并行查询两个配置并对比策略差异# 生产环境代码签名配置 data aws_lambda_code_signing_config prod { arn arn:aws:lambda:us-west-2:123456789012:code-signing-config:csc-prod-123 } # 开发环境代码签名配置 data aws_lambda_code_signing_config dev { arn arn:aws:lambda:us-west-2:123456789012:code-signing-config:csc-dev-456 } # 对比配置 locals { prod_policy data.aws_lambda_code_signing_config.prod.policies[0].untrusted_artifact_on_deployment dev_policy data.aws_lambda_code_signing_config.dev.policies[0].untrusted_artifact_on_deployment config_comparison { prod_enforcement local.prod_policy dev_enforcement local.dev_policy policies_match local.prod_policy local.dev_policy } } output environment_comparison { value local.config_comparison }该模式适合在 CI/审查流程中确保生产环境比开发环境更严格例如生产为Enforce、开发为Warn一旦策略漂移policies_match会输出false并可通过terraform plan直接暴露。源码级解析数据源如何工作读取链路ARN → GetCodeSigningConfig数据源的读取逻辑集中在dataSourceCodeSigningConfigReadcode_signing_config_data_source.go从配置中取出arn调用findCodeSigningConfigByARN(ctx, conn, arn)执行查询查询失败如配置不存在时返回诊断错误reading Lambda Code Signing Config (%s)成功后依次回填allowed_publishers、config_id、description、last_modified、policies并将资源的Id设置为配置 ARN。findCodeSigningConfigByARN与findCodeSigningConfigcode_signing_config.go位于资源文件而非数据源文件二者共用底层调用 AWS SDK v2 的GetCodeSigningConfigAPI当返回ResourceNotFoundException时包装为retry.NotFoundError当返回空响应时包装为tfresource.NewEmptyResultError()。这种统一的 finder 错误归一化模式在整个 Provider 中广泛使用也是数据源与资源读取行为保持一致的原因。数据模型与扁平化Flatten从 AWS API 返回的*awstypes.CodeSigningConfig会被扁平化为 Terraform 状态flattenAllowedPublisherscode_signing_config.go把AllowedPublishers.SigningProfileVersionArns转换为包含单个元素的列表元素内含 ARN 集合policies在数据源中直接以内联方式构造code_signing_config_data_source.go将CodeSigningPolicies.UntrustedArtifactOnDeployment的枚举值字符串化后写入untrusted_artifact_on_deployment。数据源与资源的 Schema 差异对比数据源与资源 Schema 可见数据源将arn设为Required外部传入将allowed_publishers、config_id、description、last_modified、policies全部设为Computed只读回填而资源侧allowed_publishers为Required、description为Optional长度 0-256、policies为Optional Computed并额外支持tags与tags_allcode_signing_config.go。理解这一差异有助于避免在数据源中误用只能在资源上设置的字段。测试验证与使用前提该数据源配套的验收测试位于 code_signing_config_data_source_test.go覆盖basic、policyID、description三个场景测试方式均为先创建资源再用数据源读取并断言二者属性一致例如TestCheckResourceAttrPair(dataSourceName, allowed_publishers.0.signing_profile_version_arns.#, resourceName, ...)。测试中的签名档案通过aws_signer_signing_profile创建平台为AWSLambda-SHA384-ECDSAresource aws_signer_signing_profile test { platform_id AWSLambda-SHA384-ECDSA } resource aws_lambda_code_signing_config test { allowed_publishers { signing_profile_version_arns [ aws_signer_signing_profile.test.version_arn ] } policies { untrusted_artifact_on_deployment Warn } } data aws_lambda_code_signing_config test { arn aws_lambda_code_signing_config.test.arn }使用该数据源时有两点前提需要留意网络可达性数据源会在read阶段实时调用 AWS Lambda 的GetCodeSigningConfigAPI因此运行terraform plan/apply的环境必须配置有效的 AWS 凭证且具备lambda:GetCodeSigningConfig权限区域限制测试代码通过acctest.PreCheckPartitionNot(t, endpoints.AwsUsGovPartitionID)排除了 AWS GovCloud 分区code_signing_config_data_source_test.go说明该数据源在实际 AWS 标准分区中已验证可用若在 GovCloud 等特殊分区使用建议先在目标区域确认服务可用性并通过region参数显式指定区域。小结aws_lambda_code_signing_config数据源用最小的入参仅arn封装了 AWS Lambda 代码签名配置的完整查询能力五个只读属性覆盖了发布者白名单、部署策略、标识符、描述与修改时间配合aws_lambda_function的code_signing_config_arn参数即可快速构建签名即部署门禁的供应链安全体系。其实现遵循 Provider 统一的 finder 模式数据源与资源共用查找逻辑且拥有覆盖多场景的验收测试作为质量保障是在 Terraform 中安全、可靠地管理 Lambda 代码签名配置的推荐入口。【免费下载链接】terraform-provider-awsThe AWS Provider enables Terraform to manage AWS resources.项目地址: https://gitcode.com/GitHub_Trending/te/terraform-provider-aws创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
使用 Terraform AWS Provider 查询 Lambda Code Signing Config 数据源：配置项、属性与源码实现解析
使用 Terraform AWS Provider 查询 Lambda Code Signing Config 数据源配置项、属性与源码实现解析【免费下载链接】terraform-provider-awsThe AWS Provider enables Terraform to manage AWS resources.项目地址: https://gitcode.com/GitHub_Trending/te/terraform-provider-aws导读aws_lambda_code_signing_config是 Terraform AWS Provider 提供的一个只读数据源Data Source用于按 ARN 检索已有的 AWS Lambda 代码签名配置Code Signing Config从而获取其允许的签名发布者Allowed Publishers、签名策略Code Signing Policies等元数据为 Lambda 函数的代码完整性与真实性校验提供依据。读完本文你将掌握该数据源的参数与导出属性、四种典型实战用法基础查询、函数绑定、签名档案校验、多环境对比并理解其背后的 AWS API 调用链与 Provider 源码实现。数据源概览它解决了什么问题Lambda 代码签名功能允许组织要求部署到 Lambda 的所有代码都必须由受信任的签名方签名从而防止未经验证的代码被部署。aws_lambda_code_signing_config数据源正面向已有配置的查询场景你不需要在 Terraform 中重新创建配置只需要提供其 ARN即可读取配置详情供其他资源尤其是aws_lambda_function引用。该数据源的官方文档位于 website/docs/d/lambda_code_signing_config.html.markdown核心实现在 code_signing_config_data_source.go 中。数据源与资源的关系本数据源与托管配置的aws_lambda_code_signing_config资源实现在 code_signing_config.go相互配合资源负责创建/更新/删除数据源负责按 ARN 读取既有配置。二者共用同一套findCodeSigningConfigByARN查找逻辑保证读到的数据与实际状态一致。参数Argument Reference数据源的入参非常简单arn-必填代码签名配置的 ARN。在 code_signing_config_data_source.go 中该字段为Required: true且通过verify.ValidARN校验 ARN 格式非法 ARN 会在plan阶段直接报错而不是等到调用 AWS API 时才发现。region-可选资源所在区域默认使用 Provider 配置中设置的区域即当前 Provider 的默认 Region。其中region参数与 AWS 的区域级端点解析机制相关适合需要跨区域查询配置的场景不指定时则跟随 Provider 的全局配置。导出属性Attribute Reference除了上述参数外数据源还导出以下只读属性均为Computed: true属性类型说明allowed_publishers列表List允许的发布者列表即被允许作为本配置签名方的签名档案Signing Profiles详见下方 allowed_publishers 块config_id字符串代码签名配置的唯一标识符形如csc-xxxxxxxxdescription字符串代码签名配置的描述信息last_modified字符串配置最后修改的日期与时间policies列表List控制签名不匹配或过期时校验失败动作的代码签名策略详见下方 policies 块allowed_publishers块signing_profile_version_arns- 一个字符串集合Set包含每个签名档案的 ARN。签名档案Signing Profile定义了谁是被信任的、可以给代码包签名的人。在源码中该字段被建模为TypeSetcode_signing_config_data_source.goTerraform 会将其作为集合去重处理因此通过[0].signing_profile_version_arns索引访问即可获得完整集合。policies块untrusted_artifact_on_deployment- 部署校验失败时采取的策略合法值为Warn仅告警允许部署与Enforce强制拦截拒绝部署。在资源侧code_signing_config.go该字段通过enum.Validate[awstypes.CodeSigningPolicy]()校验与 AWS SDK 的枚举类型强绑定因此传入非法值会在校验阶段被拒绝。典型用法1. 基础用法按 ARN 查询配置并导出详情data aws_lambda_code_signing_config example { arn arn:aws:lambda:us-west-2:123456789012:code-signing-config:csc-0f6c334abcdea4d8b } output config_details { value { config_id data.aws_lambda_code_signing_config.example.config_id description data.aws_lambda_code_signing_config.example.description policy data.aws_lambda_code_signing_config.example.policies[0].untrusted_artifact_on_deployment } }policies[0].untrusted_artifact_on_deployment的索引写法基于配置恰好包含一个策略块的事实资源侧policies块被限制为MaxItems: 1因此数据源返回的列表至多包含一个元素。2. 在 Lambda 函数中使用绑定代码签名配置将数据源查询到的 ARN 直接传给aws_lambda_function的code_signing_config_arn参数即可让新创建的 Lambda 函数强制启用代码签名# 获取已存在的代码签名配置 data aws_lambda_code_signing_config security_config { arn var.code_signing_config_arn } # 创建启用代码签名的 Lambda 函数 resource aws_lambda_function example { filename function.zip function_name secure-function role aws_iam_role.lambda_role.arn handler index.handler runtime nodejs24.x code_signing_config_arn data.aws_lambda_code_signing_config.security_config.arn tags { Environment production Security code-signed } }从源码看aws_lambda_function的code_signing_config_arn参数在 function.go 中被定义为Optional且经过verify.ValidARN校验。创建函数时该值会被写入CreateFunction请求的CodeSigningConfigArn字段function.go如果函数创建后才变更该属性Provider 会在更新阶段调用PutFunctionCodeSigningConfig或DeleteFunctionCodeSigningConfigAPI 完成绑定与解绑function.go读取阶段则通过GetFunctionCodeSigningConfig回填状态function.go。3. 校验签名档案条件化部署在部署前动态校验目标签名档案是否被当前配置允许只有允许时才创建函数data aws_lambda_code_signing_config example { arn var.code_signing_config_arn } # 检查指定签名档案是否被允许 locals { allowed_profiles data.aws_lambda_code_signing_config.example.allowed_publishers[0].signing_profile_version_arns required_profile arn:aws:signer:us-west-2:123456789012:/signing-profiles/MyProfile profile_allowed contains(local.allowed_profiles, local.required_profile) } # 根据签名档案校验结果条件化创建资源 resource aws_lambda_function conditional { count local.profile_allowed ? 1 : 0 filename function.zip function_name conditional-function role aws_iam_role.lambda_role.arn handler index.handler runtime python3.12 code_signing_config_arn data.aws_lambda_code_signing_config.example.arn } output deployment_status { value { profile_allowed local.profile_allowed function_created local.profile_allowed message local.profile_allowed ? Function deployed with valid signing profile : Deployment blocked - signing profile not allowed } }这里的核心技巧是contains(local.allowed_profiles, local.required_profile)由于signing_profile_version_arns底层是集合Set类型Terraform 的contains函数可以可靠地执行成员判断从而把配置权限校验变成基础设施即代码中的一等公民。4. 多环境配置对比生产与开发环境通常使用不同的签名配置可以并行查询两个配置并对比策略差异# 生产环境代码签名配置 data aws_lambda_code_signing_config prod { arn arn:aws:lambda:us-west-2:123456789012:code-signing-config:csc-prod-123 } # 开发环境代码签名配置 data aws_lambda_code_signing_config dev { arn arn:aws:lambda:us-west-2:123456789012:code-signing-config:csc-dev-456 } # 对比配置 locals { prod_policy data.aws_lambda_code_signing_config.prod.policies[0].untrusted_artifact_on_deployment dev_policy data.aws_lambda_code_signing_config.dev.policies[0].untrusted_artifact_on_deployment config_comparison { prod_enforcement local.prod_policy dev_enforcement local.dev_policy policies_match local.prod_policy local.dev_policy } } output environment_comparison { value local.config_comparison }该模式适合在 CI/审查流程中确保生产环境比开发环境更严格例如生产为Enforce、开发为Warn一旦策略漂移policies_match会输出false并可通过terraform plan直接暴露。源码级解析数据源如何工作读取链路ARN → GetCodeSigningConfig数据源的读取逻辑集中在dataSourceCodeSigningConfigReadcode_signing_config_data_source.go从配置中取出arn调用findCodeSigningConfigByARN(ctx, conn, arn)执行查询查询失败如配置不存在时返回诊断错误reading Lambda Code Signing Config (%s)成功后依次回填allowed_publishers、config_id、description、last_modified、policies并将资源的Id设置为配置 ARN。findCodeSigningConfigByARN与findCodeSigningConfigcode_signing_config.go位于资源文件而非数据源文件二者共用底层调用 AWS SDK v2 的GetCodeSigningConfigAPI当返回ResourceNotFoundException时包装为retry.NotFoundError当返回空响应时包装为tfresource.NewEmptyResultError()。这种统一的 finder 错误归一化模式在整个 Provider 中广泛使用也是数据源与资源读取行为保持一致的原因。数据模型与扁平化Flatten从 AWS API 返回的*awstypes.CodeSigningConfig会被扁平化为 Terraform 状态flattenAllowedPublisherscode_signing_config.go把AllowedPublishers.SigningProfileVersionArns转换为包含单个元素的列表元素内含 ARN 集合policies在数据源中直接以内联方式构造code_signing_config_data_source.go将CodeSigningPolicies.UntrustedArtifactOnDeployment的枚举值字符串化后写入untrusted_artifact_on_deployment。数据源与资源的 Schema 差异对比数据源与资源 Schema 可见数据源将arn设为Required外部传入将allowed_publishers、config_id、description、last_modified、policies全部设为Computed只读回填而资源侧allowed_publishers为Required、description为Optional长度 0-256、policies为Optional Computed并额外支持tags与tags_allcode_signing_config.go。理解这一差异有助于避免在数据源中误用只能在资源上设置的字段。测试验证与使用前提该数据源配套的验收测试位于 code_signing_config_data_source_test.go覆盖basic、policyID、description三个场景测试方式均为先创建资源再用数据源读取并断言二者属性一致例如TestCheckResourceAttrPair(dataSourceName, allowed_publishers.0.signing_profile_version_arns.#, resourceName, ...)。测试中的签名档案通过aws_signer_signing_profile创建平台为AWSLambda-SHA384-ECDSAresource aws_signer_signing_profile test { platform_id AWSLambda-SHA384-ECDSA } resource aws_lambda_code_signing_config test { allowed_publishers { signing_profile_version_arns [ aws_signer_signing_profile.test.version_arn ] } policies { untrusted_artifact_on_deployment Warn } } data aws_lambda_code_signing_config test { arn aws_lambda_code_signing_config.test.arn }使用该数据源时有两点前提需要留意网络可达性数据源会在read阶段实时调用 AWS Lambda 的GetCodeSigningConfigAPI因此运行terraform plan/apply的环境必须配置有效的 AWS 凭证且具备lambda:GetCodeSigningConfig权限区域限制测试代码通过acctest.PreCheckPartitionNot(t, endpoints.AwsUsGovPartitionID)排除了 AWS GovCloud 分区code_signing_config_data_source_test.go说明该数据源在实际 AWS 标准分区中已验证可用若在 GovCloud 等特殊分区使用建议先在目标区域确认服务可用性并通过region参数显式指定区域。小结aws_lambda_code_signing_config数据源用最小的入参仅arn封装了 AWS Lambda 代码签名配置的完整查询能力五个只读属性覆盖了发布者白名单、部署策略、标识符、描述与修改时间配合aws_lambda_function的code_signing_config_arn参数即可快速构建签名即部署门禁的供应链安全体系。其实现遵循 Provider 统一的 finder 模式数据源与资源共用查找逻辑且拥有覆盖多场景的验收测试作为质量保障是在 Terraform 中安全、可靠地管理 Lambda 代码签名配置的推荐入口。【免费下载链接】terraform-provider-awsThe AWS Provider enables Terraform to manage AWS resources.项目地址: https://gitcode.com/GitHub_Trending/te/terraform-provider-aws创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
