Aws-sdk-net: The guidance on replacing the policy that has been deprecated is extremely vague

Created on 20 Oct 2020  路  16Comments  路  Source: aws/aws-sdk-net

Because of https://github.com/aws/aws-sdk-net/issues/1569 we have been forced to write custom logic to properly settle policies on queues. With the recent updates to the SDK the policies and related objects have been marked as deprecated. The obsoletion message points to

https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html#access_policies-json

Yet it still remains a bit of a mystery to us how this would be achieved because it seems we are effectively forced to reimplement quite a bit of the custom JSON generation present in the JsonPolicyWriter and Reader. Specifically due to the fact that the policy adapts from object to array syntax based on the presence of the number of elements (example whether you have one or multiple statements)

The Question

Can you give us better examples of how to propagate full-blown policies without relying on the SDK taking into account all the special cases that the SDK currently handles?

And why hasn't the SDK itself been adjusted to no longer rely on those structures? At least then we would have code samples available from the SDK dogfooding the obsoletion? For example see

https://github.com/aws/aws-sdk-net/blob/master/sdk/src/Services/SimpleNotificationService/Custom/AmazonSimpleNotificationServiceClient.Extensions.cs#L40-L45

Environment

  • SDK Version: 3.5 range
  • Package Version: 3.5 range
  • OS Info:
  • Build Environment
  • Targeted .NET Platform:

This is a :question: general question

guidance modulcredentials modulsdk-core

All 16 comments

Hi @danielmarbach,

Good morning.

Thanks for posting guidance question. Could you please point to obsoletion message in the documentation which states that the policies and related objects have been deprecated? Somehow, I'm not able to see it in documentation.

I do see that the other related issue #1569 has been marked with service-api label which indicates that it was discussed with developer and looks like it's the service limitation.

Thanks,
Ashish

Thanks @danielmarbach. Looks like the change was implemented back in March. I don't have context on why it was marked as obsolete, I would try getting more information from development team. You may try using AWS CLI to create policies https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create-cli.html. Hope this helps.

I'm aware of other mechanisms to create policies unfortunately we have ability of subscribing and unsubscribing at startup or at runtime that users can use if they choose so that's why we need a way to settle a policy via the SDK (which was always supported but has been made very cumbersome by this obsoletion).

Some of our customers might opt out from policy subscribing and unsubscribing at runtime provision the topology via scripting means like you mentioned yet still we need to also cater for the other segment.

Yup, we have the exact same issue here. It was the only reason I couldn't leap frog to the 3.5.x branch. This needs to be looked at soon rather than later.

Indy

The main reason this area of the SDK was marked as obsolete is because all of the action identifiers defined here are terribly out of date. I think they were last updated 6 years ago. Also we, the .NET SDK team, don't have a mechanism to keep the action update in an automated way.

I'm sure the Policy generation code is out of date as well but probably wouldn't take too much to get it up to date. I'm okay reversing the decision of obsoleting the Policy class and the other classes for policy generation and putting the obsolete on the action identifiers. I'm not saying we will right away update the Policy classes for any missing features from IAM policies but we would keep around and update them per feedback we get. Does that work for you all?

I think that would be magnificent. That being said given the current types are obsolete with warn only there is also no rush. If you need to think things over that would be fine too.

@normj do you have any updates on whether you are going to roll back the policy obsoletion or not? We are currently building a way to influence policy creation for our SQS transport and we are debating whether we can actually expose the policy objects from the SDK or not.

Hi @danielmarbach,

Apologies for the delayed reply. This issue is being currently worked upon by the development team and should be resolved soon. We would post an update here once the fix is released.

Thanks,
Ashish

No worries @ashishdhingra and thanks for coming back to me!

This is fixed in the latest version 3.5.79.0.

鈿狅笍COMMENT VISIBILITY WARNING鈿狅笍

Comments on closed issues are hard for our team to see.
If you need more assistance, please either tag a team member or open a new issue that references this one.
If you wish to keep having a conversation with other community members under this issue feel free to do so.

Great thanks!

@ashishdhingra @normj sorry for being the party crasher again ;) It seems there are still a few things that are obsoleted. For example, while the policy class itself has the obsolete removed for example the ActionIdentifier is still obsolete with the same vague guidance.

Some Action Identifiers are also still obsolete

Is this deliberate only partially done?

@danielmarbach The ActionIdentifier should have had the Obsolete attribute removed. It will be done soon it was just a miss by the engineer that did that work. The obsolete attributes in the classes in the ActionIdentifier directory will stay because we don't maintain any of those predefined ActionIdentifier instances anymore.

Thanks @normj for the reply. Cool. Looking forward

Was this page helpful?
0 / 5 - 0 ratings