Well, thanks for the convenient reference to that stuff... I would still prefer, however, some kind of solution that looked like
accessControl: aws.greengrass.*: operations: * resources: *
Or alternatively, some sort of
accessControl: disable: true
its nuts that there are conflicting examples, for supposedly the same thing
For example, sometimes, the examples say I should use syntax like com.me.myapp:cli:1
but others say
?!?!? Where's the sense? Just let me turn all the stupid access stuff OFF completely.
Thanks MIchael, I can confirm that this works:
accessControl: "*": operations: * resources: *
This will be useful for me in the future If I need it. However, I will also confirm that for just the get_component_details, this works:
accessControl: randomlabelhere: com.bolthole.hello: operations: - "aws.greengrass#GetComponentDetails" resources: - "*"
What was confusing me was the bit right after accessControl: I didnt understand why it was "aws.greengrass.Cli", and why some examples used it with ":cli:", but others with "getconfig"
Apparently, its just a random user-chosen label, which is why I used the above, and it actually works as is, for my component called com.bolthole.hello.
wait... maybe it isnt random.. .now its working all the time, even if I put in NO access control?? And even if I removed the component before doing a new deploy?? This stuff is really confusing.
To explain to "insiders", the reason why this isnt clear is: How does GreengrassCoreIPCClientV2().component_details()
relate to "aws.greengrass.Cli" ?!? Its a direct nucleus IPC API call. It should work if the Cli component isnt there. So how does the accessControl spec require using THAT, to grant access to that call??
Okay, hopefully final summary :-/
I had changed my code. GreengrassCoreIPCClientV2().get_component_details(component_name="com.bolthole.hello")
accessControl: aws.greengrass.Cli: com.bolthole.hello: operations: - "aws.greengrass#GetComponentDetails" resources: - "*"
even if the component is itself.
Does not require any access control.
Still doesnt make sense why the get_component_details access needs to be filed under "aws.greengrass.Cli" though !!!
Hi. Authorization details here: https://docs.aws.amazon.com/greengrass/v2/developerguide/ipc-local-deployments-components.html#ipc-local-deployments-components-authorization
- Accepted Answerasked 4 months ago
- Accepted Answerasked 6 months ago
- Accepted Answerasked 7 months ago
- Why am I getting a 200 response with "InternalError" or "SlowDown" for copy requests to my Amazon S3 bucket?AWS OFFICIALUpdated 2 years ago
- AWS OFFICIALUpdated 4 months ago
- EXPERTpublished 4 months ago
I understand. You can use wildcards for the resources at least, but I appreciate that's not what you're after. Please consider to raise these issues here: https://github.com/aws-greengrass/aws-greengrass-nucleus/issues. Also, in regards to conflicting examples, I'm not sure which parts of the documentation you're specifically referring to. Please be aware that there is a Feedback button near the top right of every page of the Developer Guide. We'd appreciate you calling out any errors, conflicts or confusions you find.
To allow all, the following should work. However, I really cannot recommend this as it goes against every security best practice known.