-
Notifications
You must be signed in to change notification settings - Fork 238
Customizing suffix of the assumed role ARN for auditing purpose? #38
Comments
Seems like these are where it is set: Line 53 in e809a1a
Line 159 in bbbc497
Line 56 in bbbc497
So, ideally a template to the session flag like Note that ${cluster_name} is not needed to be templated. A cluster provisioning tool knows the cluster name at kiam installation time. |
As you say- it's configurable with We re-use credentials as we often have many replicas of deployments/jobs etc. that use the same credentials and this helps reduce the number of AWS calls we make. I guess another option would be to add an additional annotation that would name the session- then have credentials cached using the role name and session name (so pods in the same deployment/job etc. would share the same?). |
Also @mumoshu sorry for only just noticing this issue now :) |
I had a think about doing this today and I don't think it's feasible without quite a large refactoring/change that would also unlock #14. I'm going to make some sketches and talk about it with people. Hopefully we get a little time to do this soon as it'd improve quite a lot of the code! |
I'm going to move this back to 3.1- I'd rather we release with all the stuff that's been done so far and then add this later. It's a feature which shouldn't rely on changing the behaviour of any existing flags so should be possible to add without breaking the existing behaviour. |
@pingles What's the status of this effort? I see 3.0-3.2 have been released since your last message. Is this something that others can help with? |
It’s something we’d love to have contributed but i don’t think we have the
capacity to do ourselves.
If someone wants to pick to I’d be happy to help answer questions here or
on slack to help guide if they need it.
…On Wed, 26 Jun 2019 at 12:09, Aidan Steele ***@***.***> wrote:
@pingles <https://github.com/pingles> What's the status of this effort? I
see 3.0-3.2 have been released since your last message. Is this something
that others can help with?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#38?email_source=notifications&email_token=AAAAI7QG6GJRIZHE7G7TCV3P4NE63A5CNFSM4ERPIXOKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODYTFTHY#issuecomment-505829791>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAAAI7VP5HIBPSGPKDWY6A3P4NE63ANCNFSM4ERPIXOA>
.
|
Was there every any movement on this feature? we really need something like this so that we can have better auditiing of our S3 resources from JupyterHub, if I could apply the username as part of the prefix it could solve this in a simple way. @pingles I am happy to pick this up if you want to have a chat with any ideas you might have had at the time? my initial thoughts in another pod annotation defining the suffix which can then be applied. |
Have been digging into this @pingles and have come to the same conclusion, supporting this is going to require a new annotation but also change the cache key to have to include the role and session name. Now before I go down this long dirty road just want to check in to see that this feature would be welcomed or if there is other work going on that could make the caching changes simpler. My current thought is that the cache key would become some concatenation of Would be interested to hear your thoughts? |
@pingles as talked about in #399 adding my 2c here. I would like to see it work using a pod template like we do today for the role and soon the extrernal ID, however the idea you mentioned to support templates could also be a viable alternative option if we could support both however I imagine from an implementation perspective and since we are already adding extrernal-id support might be easiest to just go with the annotation? |
I see #430 references this and was merged, what is the status of this now? Another nice feature would be to allow specifying the tags used during AssumeRole. AWS allows parameterizing IAM policies based on the role's tags. If it were possible to provide the namespace as a tag, it would allow writing some extremely generic IAM policies parameterized based on namespace. "Condition": {
"StringEquals": {"aws:ResourceTag/namespace": "${aws:PrincipalTag/namespace}"}
} Maybe this is a separate feature request, let me know if this needs a different ticket. |
@bburky this sounds interesting and would not be overly difficult to add with the refactoring that was done to support session-name and external-id, I imagine we could just add support for I think another feature request is a good route here. |
Hi! Thanks for starting & maintaining this great project 👍
I recently realized that running
get-caller-identity
with the kiam-provided AWS credentials produce:my-k8s-service-role
is from the pod annotation andkiam-kiam
seems to be coming from kiam.I couldn't find whether it is hard-coded into kiam or not.
Anyway, it would be great if I could configure the part to e.g.
kiam-$mycluster-$ns-$pod_name
so that it lookskiam-mycluster-kube-system-mytestpod
which would add more traceability via CloudTrail logs. More concretely, it would be nice if I could trace from CloudTrail logs which pod in which cluster/namespace called which AWS API.The text was updated successfully, but these errors were encountered: