Skip 004 - Cloud Identity and Access Management #9
Conversation
Signed-off-by: David Justice <[email protected]>
| replicas: 1 | ||
| executor: containerd-shim-spin | ||
| workloadIdentity: | ||
| enabled: true |
There was a problem hiding this comment.
Does the user need the ability to enable/disable workload identity within the manifest? I'm wondering if the presence of providers, serviceAccount, or other fields not being nil is enough to consider that the user is opting into workload identity or not.
If this is the wrong place to debate the schema of the workloadIdentity object, let me know. :)
There was a problem hiding this comment.
You, sir, have come to the right place. Step on up to debate the schema!!
I'm indifferent about the enabled field. Truth be told, I deleted 1 less time than I typed it. I believe that having a provider and service account defined may be adequate to determine the behavior is enabled.
|
Creating an IAM role and a service account for AWS creds will resolve this issue of supporting the SQS trigger with the spin operator: spinframework/spin-operator#362 |
|
Close in favor of #16 |
As we had discussed in a previous SpinKube meeting, and related to spinframework/spin#2678 & spinframework/spin#2566, this draft proposal addresses the role of the Spin operator in managing the use of federated cloud identities to provide authentication and authorization to cloud services (e.g. variable providers, key value stores, etc.).
I would like to solicit the community's feedback on the approach and structures described in the proposal.
In the initial draft, I have used an example that I'm most familiar with. However, I believe the pattern will hold based on the investigation I've done across Google, AWS, and Azure.