From 0d8c9f93aba23c39ae913b18c67d41951b3c098c Mon Sep 17 00:00:00 2001 From: dbaumgarten Date: Wed, 18 Dec 2024 09:48:50 +0100 Subject: [PATCH] Fixed typos Signed-off-by: Daniel Baumgarten --- 139-pipeline-identity-tokens/proposal.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/139-pipeline-identity-tokens/proposal.md b/139-pipeline-identity-tokens/proposal.md index ffac220..3be64df 100644 --- a/139-pipeline-identity-tokens/proposal.md +++ b/139-pipeline-identity-tokens/proposal.md @@ -13,10 +13,10 @@ As of now you would need to create static credentials for these outside services However having static (long lived) credentials for something that is critical (like a prod account on AWS) is not state of the art for authentication. It would be much better if code running in a pipeline could somehow prove it's identity to the outside service. The outside service could then be configured to grant permissions to a specific pipeline. -Lot's if other services already implement something like this. One well knwon example of this are [Kubernetes's Service Accounts](https://kubernetes.io/docs/concepts/security/service-accounts/#authenticating-credentials). Kubernetes mounts a signed JWT into the pod and the pod can then use this token to authenticate with Kubernetes itself or with any other service that has a trust-relationship. +Lots if other services already implement something like this. One well known example of this are [Kubernetes's Service Accounts](https://kubernetes.io/docs/concepts/security/service-accounts/#authenticating-credentials). Kubernetes mounts a signed JWT into the pod and the pod can then use this token to authenticate with Kubernetes itself or with any other service that has a trust-relationship. ## Usage with AWS -For example a Pipeline could use AWS's [AssumeRoleWithWebIdentity API-Call](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRoleWithWebIdentity.html) to authenticate with AWS using it's concourse-token and do stuff in AWS. It is even [diretly supported by the AWS CLI](https://docs.aws.amazon.com/cli/latest/reference/sts/assume-role-with-web-identity.html) +For example a Pipeline could use AWS's [AssumeRoleWithWebIdentity API-Call](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRoleWithWebIdentity.html) to authenticate with AWS using it's concourse-token and do stuff in AWS. It is even [directly supported by the AWS CLI](https://docs.aws.amazon.com/cli/latest/reference/sts/assume-role-with-web-identity.html) 1. Create an OIDC-Identity-Provider for your Concourse Server in the AWS Account you would like to use. Like [this](img/AWS-IDP.png). 2. Create an AWS.IAM-Role with the required deployment-permissions and the following trust policy: @@ -48,7 +48,7 @@ This trust-policy allows everyone to assume this role via the AssumeRoleWithWebI And conveniently Concourse will create exactly such a token and supply it to (and only to) the pipeline "deploy-to-aws" in the "main" team. -When code inside a pipeline performs the AssumeRoleWithWebIdentity API-Call, AWS will check the provided token for expiry, query concourse to obtain the correct signature-verification key and use it to check the JWT's signature. It will then compare the aud-claim of the token with the one specified in the Role's trust policy. If everything checks out, AWS will return temporary AWS-Credentials that the pipeline can then use to perfor actions in AWS. +When code inside a pipeline performs the AssumeRoleWithWebIdentity API-Call, AWS will check the provided token for expiry, query concourse to obtain the correct signature-verification key and use it to check the JWT's signature. It will then compare the aud-claim of the token with the one specified in the Role's trust policy. If everything checks out, AWS will return temporary AWS-Credentials that the pipeline can then use to perform actions in AWS. In a concourse pipeline all of this could then look like this: ``` @@ -78,7 +78,7 @@ It works similarly to AWS. You tell vault an URL to the Issuer of the JWT (your Detailed usage-instructions for vault can follow if required. # Proposal -Implementation is split into different phases, that stack onto each other. We could implement the first few and expant the implementation step by step. +Implementation is split into different phases, that stack onto each other. We could implement the first few and expand the implementation step by step. ## Phase 1 - When Concourse boots for the first time it creates a signature keypair and stores it into the DB