sig-aws: iam credentials integration kep #2329
Conversation
* This proposal was discussed at the SIG-AWS meeting on 15th July 2018 and started in a Google Doc (linked in the proposal). * @countspongebob suggested we put into a kep to broaden the feedback
k8s-ci-robot
added
the
size/L
|
Thanks for your pull request. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA). 📝 Please follow instructions at https://git.k8s.io/community/CLA.md#the-contributor-license-agreement to sign the CLA. It may take a couple minutes for the CLA signature to be fully registered; after that, please reply here with a new comment and we'll verify. Thanks.
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here. |
k8s-ci-robot
added
cncf-cla: no
k8s-ci-robot
added
sig/architecture
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: Assign the PR to them by writing The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
|
@k8s-ci-robot joined CLA org |
| #### Proxy | ||
| Any Pod needing credentials will have an init container and sidecar. | ||
|
|
||
| The init container will ensure that other containers in the Pod when accessing `http://169.254.170.2` will have requests forwarded to the sidecar. The init container can also request initial credentials ensuring that the pod is entitled to use credentials for a role configured through the IAMBinding. |
There was a problem hiding this comment.
The init container will ensure that other containers in the Pod when accessing
http://169.254.170.2will have requests forwarded to the sidecar.
can you describe the mechanism used for that? what level of permission/privilege is required for the init container to accomplish this?
There was a problem hiding this comment.
Within Istio I believe it's done with iptables here: https://github.com/istio/istio/blob/0759c8572119b8c78eeed1e0bbd3c58efc748092/tools/deb/istio-iptables.sh
We do similar with an agent proxy already which adds NET_ADMIN to the security context capabilities. So for this proposal it could be done using the same.
|
|
||
| Using a per-Pod proxy helps mitigate many of the shortcomings of the existing DaemonSet-style solutions: IAM permissions can be checked before pods start, updates to the proxy are associated with the lifecycle of the Pod process, stronger identity attestation and removing inconsistency issues from tracking pods against the watcher. Existing solutions also often rely on per-node agents which, when restarted, can cause problems for the Pods running on the same nodes. Running a proxy sidecar against the Pod mitigates this. | ||
|
|
||
| Our assumption is that proxies can be injected in the same way Istio injects it’s proxy (iptables from the init container). |
There was a problem hiding this comment.
does this require high permission levels for the init container?
There was a problem hiding this comment.
it would be good to get feedback from the istio team on the viability of this approach, challenges they've hit in different environments where initContainers are not allowed those privilege levels, interactions with different types of network environments, etc
There was a problem hiding this comment.
As above, it does need higher permissions- I think NET_ADMIN would suffice. But, it would only need the init container to run with additional privileges.
Agreed- be great to know whether this is a legitimate approach, or something we should/could accomplish in a different way.
|
/ok-to-test |
k8s-ci-robot
removed
the
needs-ok-to-test
|
/check-cla @pingles Thanks for the contribution! It seems you didn't sign the CLA successfully. |
|
@pingles: PR needs rebase. Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
k8s-ci-robot
added
the
needs-rebase
|
/kind kep |
|
REMINDER: KEPs are moving to k/enhancements on November 30. Please attempt to merge this KEP before then to signal consensus. Any questions regarding this move should be directed to that thread and not asked on GitHub. |
|
KEPs have moved to k/enhancements. Any questions regarding this move should be directed to that thread and not asked on GitHub. |
|
@justaugustus: Closed this PR. In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
This proposal was discussed at the SIG-AWS meeting on 15th July 2018 and started in a Google Doc (linked in the proposal). @countspongebob suggested we put into a kep to broaden the feedback.
This KEP outlines a method to allow pods to retrieve credentials for AWS APIs. It allows per-process credentials to be used to improve the security of workloads running on Kubernetes clusters requiring access to AWS resources.
Earlier versions of this proposal were captured in this Google Doc: SIG-AWS IAM Credentials Provider KEP