L53: gRFC for STS credentials. by jboeuf · Pull Request #145 · grpc/proposal

jboeuf · 2019-05-30T16:07:45Z

No description provided.

a11r · 2019-05-30T16:33:34Z

Thanks for the proposal.

I can see the need for StsCredentialsOptions in the internal implementation of the Auth library, but I would expect that the API we would expose to gRPC applications would be of the form :

StsCredentials mySTScreds =
StsCredentialsFromALTS(
myALTScreds);

You can imagine replacing "ALTS" with other creds types that are relevant.

chwarr · 2019-05-30T16:29:21Z

L50-cpp-sts-creds-api.md

+
+## Background
+
+[OAuth 2.0 Token Exchange](https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-16) is the proposed standard for exchanging tokens, for scenarios where a client needs to access a resource that does not natively accept the credentials created by the authentication system used by the client. In these settings, enabling credential exchange can provide better security: Otherwise, the client needs to acquire a different set of credentials to access the resource, and the new credentials must be managed securely.


Consider using reference-style links to minimize duplication of the addresses:

[OAuth 2.0 Token Exchange][oauth-token-exchange] is the proposed... [oauth-token-exchange]: https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-16

chwarr · 2019-05-30T16:30:39Z

L50-cpp-sts-creds-api.md

+
+## Background
+
+[OAuth 2.0 Token Exchange](https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-16) is the proposed standard for exchanging tokens, for scenarios where a client needs to access a resource that does not natively accept the credentials created by the authentication system used by the client. In these settings, enabling credential exchange can provide better security: Otherwise, the client needs to acquire a different set of credentials to access the resource, and the new credentials must be managed securely.


Minor: Remove the comma in " ...exchanging tokens, for scenarios ..."?

chwarr · 2019-05-30T16:31:28Z

L50-cpp-sts-creds-api.md

+
+[OAuth 2.0 Token Exchange](https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-16) is the proposed standard for exchanging tokens, for scenarios where a client needs to access a resource that does not natively accept the credentials created by the authentication system used by the client. In these settings, enabling credential exchange can provide better security: Otherwise, the client needs to acquire a different set of credentials to access the resource, and the new credentials must be managed securely.
+
+For instance, Kubernetes workloads can securely obtain credentials from their platform, and they can use these to authenticate to other entities in the cluster, or to the Kubernetes API itself. However, if a Kubernetes workload requires access to a cloud provider's API, it needs a separate set of secrets, and a way to deploy these secrets securely. With credential exchange this is no longer necessary: The workload credential can be directly exchanged for a short-lived token for the cloud API. We expect this type of interaction to become a best practice, as it eliminates a number of problematic patterns, such as secrets checked into code repos, or stored in improperly ACL'ed files.


Minor: Remove the comma in "cluster, or to the Kubernetes API itself."?

chwarr · 2019-05-30T16:31:43Z

L50-cpp-sts-creds-api.md

+* Status: Draft
+* Implemented in: core, cpp
+* Last updated: May 20, 2019
+* Discussion at: <google group thread> (filled after thread exists)


Is there a thread for this yet? Can you start one?

Just did:
https://groups.google.com/forum/#!topic/grpc-io/Bam9eLaI62Q
Thanks for the reminder!

chwarr · 2019-05-30T16:32:27Z

L50-cpp-sts-creds-api.md

+
+[OAuth 2.0 Token Exchange](https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-16) is the proposed standard for exchanging tokens, for scenarios where a client needs to access a resource that does not natively accept the credentials created by the authentication system used by the client. In these settings, enabling credential exchange can provide better security: Otherwise, the client needs to acquire a different set of credentials to access the resource, and the new credentials must be managed securely.
+
+For instance, Kubernetes workloads can securely obtain credentials from their platform, and they can use these to authenticate to other entities in the cluster, or to the Kubernetes API itself. However, if a Kubernetes workload requires access to a cloud provider's API, it needs a separate set of secrets, and a way to deploy these secrets securely. With credential exchange this is no longer necessary: The workload credential can be directly exchanged for a short-lived token for the cloud API. We expect this type of interaction to become a best practice, as it eliminates a number of problematic patterns, such as secrets checked into code repos, or stored in improperly ACL'ed files.


Minor: Remove the comma in "set of secrets, and a way to deploy"?

chwarr · 2019-05-30T16:33:10Z

L50-cpp-sts-creds-api.md

+
+[OAuth 2.0 Token Exchange](https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-16) is the proposed standard for exchanging tokens, for scenarios where a client needs to access a resource that does not natively accept the credentials created by the authentication system used by the client. In these settings, enabling credential exchange can provide better security: Otherwise, the client needs to acquire a different set of credentials to access the resource, and the new credentials must be managed securely.
+
+For instance, Kubernetes workloads can securely obtain credentials from their platform, and they can use these to authenticate to other entities in the cluster, or to the Kubernetes API itself. However, if a Kubernetes workload requires access to a cloud provider's API, it needs a separate set of secrets, and a way to deploy these secrets securely. With credential exchange this is no longer necessary: The workload credential can be directly exchanged for a short-lived token for the cloud API. We expect this type of interaction to become a best practice, as it eliminates a number of problematic patterns, such as secrets checked into code repos, or stored in improperly ACL'ed files.


Minor: Remove the comma in "code repos, or stored"?

- Also changing the numbering to L51 as opposed to L50 since there's already a PR with an L51 proposal.

jboeuf · 2019-05-30T22:37:53Z

@a11r Do you want me to reply on this PR or on the https://groups.google.com/forum/#!topic/grpc-io/Bam9eLaI62Q thread?

Adding gRFC for STS credentials.

099cfdc

jboeuf added the enhancement label May 30, 2019

jboeuf requested review from a11r, jiangtaoli2016 and markdroth May 30, 2019 16:07

jboeuf assigned a11r, markdroth and jiangtaoli2016 May 30, 2019

jboeuf mentioned this pull request May 30, 2019

Adding support for STS Token Exchange Creds in core: grpc/grpc#19032

Merged

chwarr reviewed May 30, 2019

View reviewed changes

Julien Boeuf added 2 commits May 30, 2019 15:27

Addressing first round of comments:

c4c54cf

- Also changing the numbering to L51 as opposed to L50 since there's already a PR with an L51 proposal.

Changing to L53 since L51 and L52 already exist.

44e9e6c

jboeuf changed the title ~~gRFC for STS credentials.~~ L53: gRFC for STS credentials. May 30, 2019

Fixing last updated date.

34e86ce


		## Background

		[OAuth 2.0 Token Exchange](https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-16) is the proposed standard for exchanging tokens, for scenarios where a client needs to access a resource that does not natively accept the credentials created by the authentication system used by the client. In these settings, enabling credential exchange can provide better security: Otherwise, the client needs to acquire a different set of credentials to access the resource, and the new credentials must be managed securely.


		[OAuth 2.0 Token Exchange](https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-16) is the proposed standard for exchanging tokens, for scenarios where a client needs to access a resource that does not natively accept the credentials created by the authentication system used by the client. In these settings, enabling credential exchange can provide better security: Otherwise, the client needs to acquire a different set of credentials to access the resource, and the new credentials must be managed securely.

		For instance, Kubernetes workloads can securely obtain credentials from their platform, and they can use these to authenticate to other entities in the cluster, or to the Kubernetes API itself. However, if a Kubernetes workload requires access to a cloud provider's API, it needs a separate set of secrets, and a way to deploy these secrets securely. With credential exchange this is no longer necessary: The workload credential can be directly exchanged for a short-lived token for the cloud API. We expect this type of interaction to become a best practice, as it eliminates a number of problematic patterns, such as secrets checked into code repos, or stored in improperly ACL'ed files.

Conversation

jboeuf commented May 30, 2019

Uh oh!

a11r commented May 30, 2019

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

jboeuf commented May 30, 2019

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants