Customizing suffix of the assumed role ARN for auditing purpose?

[mumoshu]

Hi! Thanks for starting & maintaining this great project 👍

I recently realized that running get-caller-identity with the kiam-provided AWS credentials produce:

$ aws sts get-caller-identity --region ap-northeast-1

{
    "Account": "$myaccountid",
    "UserId": "AROAICVHQ4GZUSQIQRRHY:kiam-kiam",
    "Arn": "arn:aws:sts::$myaccountid:assumed-role/my-k8s-service-role/kiam-kiam"
}

my-k8s-service-role is from the pod annotation and kiam-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 looks kiam-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.

[mumoshu]

Seems like these are where it is set:

kiam/pkg/aws/sts/cache.go

Line 53 in e809a1a

sessionName: fmt.Sprintf("kiam-%s", sessionName),

kiam/pkg/server/server.go

Line 159 in bbbc497

credentialsCache := sts.DefaultCache(stsGateway, config.SessionName, arnResolver)

kiam/cmd/server/main.go

Line 56 in bbbc497

kingpin.Flag("session", "Session name used when creating STS Tokens.").Default("kiam").StringVar(&serverConfig.SessionName)

So, ideally a template to the session flag like --session ${cluster_name}-{{.PodNamespace}}-{{.PodName}} executed with the metadata from the credentials-requestor pod would be great.

Note that ${cluster_name} is not needed to be templated. A cluster provisioning tool knows the cluster name at kiam installation time.

[pingles]

As you say- it's configurable with --session but currently kiam will request credentials (and cache) per-role, so the session would be tied to the originally requesting Pod (if you have the same role used by multiple pods it might be misleading) so given it's current implementation it'd mostly be useful for cluster name.

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?).

[pingles]

Also @mumoshu sorry for only just noticing this issue now :)

[pingles]

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!

[pingles]

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.

[aidansteele]

@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?

[pingles]

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> .

[stefansedich]

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.