Container-level approach for AWS IAM identity

**What would you like to be added**:
There is no way, currently, to associate a service account at the container level to have a more fine-grained Kubernetes RBAC and AWS IAM permissions (more information [here](https://github.com/kubernetes/kubernetes/issues/66020)). But it would be nice to have the ability to forcefully refresh the AWS IAM token, based on the current service account token at `/var/run/secrets/kubernetes.io/serviceaccount`. I would suggest to have an environment variable (named such as `REFRESH_IAM_TOKEN`) that could be set in the container.

**Why is this needed**:

In order to give different IAM permissions to containers in the same pod, you can use the environment variables to point to a role ARN. But you are still using a single service account (with certain permissions within Kubernetes) that can assume more IAM roles than necessary.

Take the following use case, for example:
- EKS cluster with only Fargate pods
- In order to send logs to CloudWatch you need to attach a sidecar container for the logging agent
- To adhere to the principle of least privilege, you want your sidecar container to only have access to publish to CloudWatch and limited access to Kubernetes APIs.

You can mount manually another service account token into the container to override the pod one. The only problem is that you cannot do the same for the IAM token.

Along the same lines, it would also be a problem if you have an init container that needs more/less IAM permissions than your main container.

Sample manifest

```yaml
apiVersion: v1
kind: ServiceAccount
metadata:
annotations:
eks.amazonaws.com/role-arn: arn:aws:iam::111122223333:role/s3-reader
name: my-serviceaccount
namespace: default
---
apiVersion: v1
kind: ServiceAccount
metadata:
annotations:
eks.amazonaws.com/role-arn: arn:aws:iam::111122223333:role/cloudwatch-publisher
name: logger
namespace: default
---
apiVersion: v1
kind: Secret
metadata:
annotations:
kubernetes.io/service-account.name: logger
name: logging-svc-acct-token
namespace: default
type: kubernetes.io/service-account-token
---
apiVersion: v1
kind: Pod
metadata:
name: my-pod
namespace: default
spec:
serviceAccountName: my-serviceaccount
containers:
- name: container-name
image: busybox:latest
args:
- 'i=0; while true; do echo "$i: $(date) this is an app log" >> /var/log/app.log;
echo "$(date) $(uname -r) $i" >> /var/log/system.log; i=$((i+1)); sleep 500;
done;'
command:
- /bin/sh
- -c
- --
volumeMounts:
- mountPath: /var/log/
name: log-data
- name: sidercar-name
image: amazon/aws-for-fluent-bit:2.2.0
env:
- name: AWS_REGION
value: us-west-2
- name: AWS_ROLE_ARN
value: arn:aws:iam::111122223333:role/cloudwatch-publisher
- name: AWS_WEB_IDENTITY_TOKEN_FILE
value: /var/run/secrets/eks.amazonaws.com/serviceaccount/token
volumeMounts:
- mountPath: /var/run/secrets/eks.amazonaws.com/serviceaccount
name: aws-token
readOnly: true
- mountPath: /var/run/secrets/kubernetes.io/serviceaccount
name: logger-token
readOnly: true
- mountPath: /var/log/
name: log-data
readOnly: true
volumes:
- emptyDir: {}
name: log-data
- name: aws-token
projected:
sources:
- serviceAccountToken:
audience: "sts.amazonaws.com"
expirationSeconds: 86400
path: token
- name: logger-token
secret:
secretName: logging-svc-acct-token
```

**Workaround**:
We can give the pod service account (called `my-serviceaccount` in the sample) permission to assume both IAM roles (`s3-reader` and `cloudwatch-publisher`) and forget about the logger service account, although that is not the recommended way.

The issue names no implementation files, tests, or entry points. Start by reviewing the webhook's handling of service-account tokens and AWS IAM environment variables, then compare the requested refresh behavior with the sample manifest and stated workaround. Done would mean a container can use its mounted service-account token for appropriately scoped IAM permissions.

Written by the indexing model from the issue text.