Hey folks, I don't see this in the docs or repo, so I am asking here: Is there some way to add arbitrary plugins without rebuilding cloud custodian ? e.g. similar to Terraform / OpenTofu's

local

execution? I want to add some API calls to gather info outside of cloud providers, so I am wondering if I should wrap CC (similar to the other tools) or is there some mechanism to extend the functionality via "plugin". Thanks!

I'm not going to be able to lead on the community meeting, re on train, but can setup it up for others. Meeting notes https://hackmd.io/K2wmVyyASKqz9FDE-w0Cpg

Oh.. one pr i was looking for a review on to reduce some of the dependable pr volume by grouping is https://github.com/cloud-custodian/cloud-custodian/pull/10695

@kapilt Hello, I submitted a report through GitHub. How long does the review usually take? https://github.com/cloud-custodian/cloud-custodian/security

I'll mention this during today's community meeting too, but we're about due for a release so a good time to check for any known release blockers. Feel free to yell them out, I may create a c7n 0.9.51 milestone to track them (was helpful leading up to 0.9.50)

In the last community meeting, there was a point about "hey we should flex that recent filter_resources fix in tests and compile its jmespath expressions" - that was a fair point. https://github.com/cloud-custodian/cloud-custodian/pull/10775 does that. I've also made a drive-by tweak to the awscc data build step because that recently started failing in CI (I think it had been working by accident for a while).

It’s sprint day at PyConUS, and… Well… I have an ask. I hope to be flinging around some PR’s today. Most (I think) will be relatively straightforward. One will be large but it’s a clone of the Google cel-spec acceptance test suite, so the details don’t much matter, mostly it requires more eyes to be sure I haven’t polluted the project with some other fat-fingered mistake.

Finally, the CEL-Python acceptance test features files are up-to-date with cel-spec. This needs a review. Some Background Many tests are marked with

@wip

so they can be filtered out of the acceptance test suite. This is a much larger problem that needs to be carved up into pieces and tackled in waves. I have a suspicion that several hundred tests will already pass, but were flagged as

@wip

because of a small bug in the conversion from textproto to Gherkin. Bug fixed and the tests now have a proper syntax.

Hey Maintainers, Can I get pair of eyes to review this PR: https://github.com/cloud-custodian/cloud-custodian/pull/10802? Thanks in advance!!! cc: @AJ Kerrigan

The PR for tfparse 0.6.20 should be good to go now: https://github.com/cloud-custodian/tfparse/pull/279 (During the last community meeting, Kapil made a point about making sure we could generate release artifacts with the changes. That was a good call 👍 )

FYI for anyone who remembers the issue where upgrading

oci

broke our Azure tests... it was because the oci sdk stopped vendoring urllib3 and started globally mutating HTTP Connections which broke VCR behavior 🫠 . They fixed it in a later version and stopped pinning old pyopenssl so we don't need to pin an old oci version anymore, but that was a weird one.

Hey Maintainers! Can you please review this PR : https://github.com/cloud-custodian/cloud-custodian/pull/10807 ? Thanks.

PR ready for review: cloud-custodian/pull/10831 (adds cloudfront function and keyvalue store)

Two PR ready for review: https://github.com/cloud-custodian/cloud-custodian/pull/10838 https://github.com/cloud-custodian/cloud-custodian/pull/10827

i've been wondering about dropping make for just, as the ergonomics are way better, this came up about two years ago, but deferred since just wasn't universally packaged at the time. afaics, every linux distribution now has a package for it, so i don't see any downside except for dev impact on switching out. https://github.com/casey/just

in a separate note, python 3.14 seeems to just work, probably worth putting into ci

A cel-python PR github.com/cloud-custodian/cel-python/pull/186 needs a review. I’ve added 3.14 to the

ci.yaml

. There’s very little being changed. (Looking into replace make with just.)

One more CEL-Python PR github.com/cloud-custodian/cel-python/pull/188 I’ve finally put the changes in for a long-standing Windows issue. This lets me clean up two PR’s that were incomplete, also.

CEL-Python PR github.com/cloud-custodian/cel-python/pull/189 This expands test coverage to 100% of lines. (This still does not address the elephant in the room: numerous CEL compliance test scenarios marked as “work-in-process”. Working up to this via some cleanup effort first. There will be a few other cleanup PR’s as part of lurching closer to the essential issue.)

CEL-Python PR github.com/cloud-custodian/cel-python/pull/191 is voluminous. However, there are changes to

gherkinize.py

that are really important, and some other parts that are — perhaps — less important. Specifically, the changes to

test_gherkinize.py

to get test coverage to 100%. (Clearly, I think 100% code coverage is important, or I wouldn’t have pursued it. But. Someone reviewing these changes might feel overwhelmed by the volume of code involved.) The point is to get some useful tooling to pursue issue github.com/cloud-custodian/cel-python/issues/64.

👋 Hello C7N Community - Had some inspiration to revisit the long standing "MatchedFilters" gap and limitation. I'm proposing adding a "trace" flag that will provide a detailed trace during policy evaluation. github.com/cloud-custodian/cloud-custodian/pull/10914 The use-case here is to identify specifically which filters evaluate to true and what the actual vs expected values are. This handles nesting and, or and nots. The

match_trace

attribute is set to true on a policy, the evaluation will return 3 new fields.

c7n:MatchTrace

,

c7n:MatchTraceSummary

and

c7n:MatchTraceSlim

I couldn't settle if all 3 are really needed. Personally I like the summarized and slim Summarized

["⊤ OR(
  ⊥ AND(
    ⊥ IamInstanceProfile.Arn regex '(?!.*TestProductionInstanceProfile)(.*)' -> None,
    ⊥ IamInstanceProfile.Arn eq 'not-null' -> None
    ),
  ⊤ IamInstanceProfile eq 'absent' -> None
  )",
"⊤ GroupName regex '(.*PROD-ONLY.*)' related:['sg-411b413c']"]

Slim (Only displays truthy paths)

[
{'type': 'or', 'matched': True, 'children':
  [{'type': 'value', 'key': 'IamInstanceProfile', 'op': 'eq', 'expected': 'absent', 'actual': None, 'value_type': None, 'matched': True}]},
{'type': 'value', 'key': 'GroupName', 'op': 'regex', 'expected': '(.*PROD-ONLY.*)', 'related_ids': ['sg-411b413c'], 'matched': True}]

Have a PR here which adds some additional quicksight functionality and minor refactoring that could use a review. Let me know if you have any thoughts: https://github.com/cloud-custodian/cloud-custodian/pull/10921. Thanks!

Small PR (adds only one line to retrieve get_key details): github.com/cloud-custodian/cloud-custodian/pull/10925

Reviving a dusty old request to support more dynamic options for tagging AWS resources (following GCP/Azure patterns). If someone's got some time for a review I'd appreciate it: github.com/cloud-custodian/cloud-custodian/pull/10942

opened two small, independent PRs against

c7n/mu.py

and

c7n/resources/iam.py

, would appreciate a review when you have a chance: • #10951 —

aws - mu - strip read-only fields from ConfigRule before PutConfigRule update

Fixes an

InvalidParameterValueException

on

PutConfigRule

for ordinary

CUSTOM_LAMBDA

config rules using

EvaluationModes

—

ConfigRule.add()

was round-tripping read-only fields (

RuleEvaluationVisibility

,

ConfigRuleArn

, etc.) from

DescribeConfigRules

back into the update call, which AWS Config now rejects server-side. • #10952 —

aws - iam-policy - detect list-form Action/Resource in has-allow-all

Fixes

has-allow-all

silently missing full-admin IAM policies written with list-form `Action`/`Resource` (

["*"]

instead of bare

"*"

). Also closes #5136, which has been open since 2019 with the exact same repro.

PR to add Clean Rooms Member filter to the CleanRooms Collaboration resource: github.com/cloud-custodian/cloud-custodian/pull/11032

Hey all, have a few pretty standard boilerplate resource implementations and one small change that could use reviews. Thanks! https://github.com/cloud-custodian/cloud-custodian/pull/11098 https://github.com/cloud-custodian/cloud-custodian/pull/11042 https://github.com/cloud-custodian/cloud-custodian/pull/10990 https://github.com/cloud-custodian/cloud-custodian/pull/10899

In the last community meeting we had some discussion about using Cubic to perform some initial PR reviews. That's enabled now, so please fire away here if you have any questions/concerns/etc. I'm sure it'll come up in tomorrow's meeting as well.

PR up here to prep for a release, mostly a fairly standard release prep PR though I did add a 5-day cooldown for uv package updates in case anyone has strong thoughts on that: github.com/cloud-custodian/cloud-custodian/pull/11162

Gave this pr a thorough review and it looks solid, but it’s touching the resolver so I'd like a second set of eyes if possible: https://github.com/cloud-custodian/cloud-custodian/pull/11148 thanks!