Documentation for idtoken var source

lit/docs/operation/creds.lit

@@ -46,6 +46,7 @@ backend you want to use.
 \include-section{creds/aws-secretsmanager.lit}
 \include-section{creds/kubernetes.lit}
 \include-section{creds/cyberark-conjur.lit}
+\include-section{creds/idtoken.lit}
 \include-section{creds/caching.lit}
 \include-section{creds/redacting.lit}
 \include-section{creds/retry.lit}

lit/docs/operation/creds/idtoken.lit

@@ -0,0 +1,345 @@
+\title{\aux{The }IDToken credential manager}{idtoken-credential-manager}
+
+\use-plugin{concourse-docs}
+\omit-children-from-table-of-contents
+
+This idtoken credential manager is a bit special. It doesn't load any credentials from an external source but instead generates \link{JWTs}{https://datatracker.ietf.org/doc/html/rfc7519} which are signed by concourse and contain information about the pipeline/job 
+that is currently running. It can NOT be used as a cluster-wide credential manager, but must instead be used as a \reference{var-sources}{var source}.
+
+These JWTs can be used to authenticate with external services via "identity federation" with the identity of the pipeline.
+
+Examples for services that support authentication via JWTs are:
+
+\list{
+  \link{Vault}{https://vaultproject.io}
+}{
+  \link{AWS}{https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers.html}
+}{
+  \link{Azure}{https://learn.microsoft.com/en-us/graph/api/resources/federatedidentitycredentials-overview?view=graph-rest-1.0}
+}
+
+
+External services can verify if JWTs are actually issued by your Concourse, by checking the signatures on the JWTs against the public keys published by your Concourse.
+
+The public keys for verification are published as \link{JWKS}{https://datatracker.ietf.org/doc/html/rfc7517} at:
+\codeblock{bash}{{{
+https://your-concourse-server.com/.well-known/jwks.json
+}}}
+
+Concourse also offers a \link{OIDC Discovery Endpoint}{https://openid.net/specs/openid-connect-discovery-1_0.html}, which allows external services to auto-discover the JWKS-URL.
+
+\section{
+  \title{Usage}
+
+  You create a var-source of type \code{idtoken} with the configuration you want (see \reference{idtoken-credential-manager-config}{next chapter}) in your pipeline.
+  That var-source then exposes a single variable \code{token}, which contains the JWT and can be used in any step of your pipeline.
+
+  You can also have multiple idtoken var-sources in the same pipeline, each with different audiences, lifetimes etc.
+
+  \codeblock{bash}{{{
+  var_sources:
+  - name: myidtoken
+    type: idtoken
+    config:
+      audience: ["sts.amazonaws.com"]
+
+  jobs:
+  - name: print-creds
+    plan:
+    - task: print
+      config:
+        platform: linux
+        image_resource:
+          type: mock
+          source: {mirror_self: true}
+        run:
+          path: bash
+          args:
+          - -c
+          - |
+            echo myidtoken: ((myidtoken:token))
+  }}}
+}
+
+\section{
+  \title{Configuration}{idtoken-credential-manager-config}
+
+  You can pass several config options to the var-source to customize the generated JWTs.
+  You can for example configure the aud-claim, expiration or granularity of the sub-claim.
+  See \reference{idtoken-var-source}{here} for details.
+
+  \section{
+    \title{Subject Scope}{idtoken-subject-scope}
+
+    Some external services (like for example AWS) only perform exact-matches on a token's sub-claim and ignore most other claims.
+    To enable use-cases like for example "all pipelines of a team should be able to assume an AWS-Role", Concourse offers the option to configure how fine-granular the sub-claim's value should be.
+
+    This is configured via the \code{subject_scope} setting of the \reference{idtoken-var-source}{var-source}.
+
+    Depending of the value of \code{subject_scope}, the content of the JWT's sub-claim will differ:
+    \list{
+      \code{team}: sub="<team_name>"
+    }{
+      \code{pipeline}: sub="<team_name>/<pipeline_name>"
+    }{
+      \code{instance}: sub="<team_name>/<pipeline_name>/<instance_vars>"
+    }{
+      \code{job}: sub="<team_name>/<pipeline_name>/<instance_vars>/<job_name>"
+    }
+
+    \smaller{Note: If a path element is empty (for example because you chose \code{job} on a pipeline with no instance-vars), the empty element is still added.}
+
+    This way all your pipelines can simply get a token with \code{subject_scope="team"} and use this token to assume an AWS-Role that matches on \code{sub="yourteamname"}.
+
+  }
+
+}
+
+\section{
+  \title{Example JWT}
+
+  The generated tokens usually look something like this:
+  \code{
+    eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJodHRwczovL3lvdXItY29uY291cnNlLmV4YW1wbGUuY29tIiwiZXhwIjoxNzUxMDE1NzM0LCJhdWQiOlsiYXBpOi8vQXp1cmVBRFRva2VuRXhjaGFuZ2UiXSwic3ViIjoibWFpbi9leGFtcGxlLXBpcGVsaW5lIiwidGVhbSI6Im1haW4iLCJwaXBlbGluZSI6ImV4YW1wbGUtcGlwZWxpbmUiLCJqb2IiOiJleGFtcGxlLWpvYiJ9.my7l44tH0wfz8vc6z3fMmzTMxZ8_orhjcsOti3BKSNo
+  }
+
+  And after decoding like this:
+  \codeblock{bash}{{{
+    {
+      "aud": "sts.amazonaws.com",
+      "exp": 1751282764,
+      "iat": 1751279164,
+      "iss": "https://your-concourse-server.com",
+      "job": "print-creds",
+      "pipeline": "mypipeline",
+      "sub": "main/mypipeline",
+      "team": "main"
+    }
+  }}}
+
+  Here is a short explanation of the different claims:
+
+  \list{
+    \code{iss}: Who issued the token (always contains the external URL of your Concourse)
+  }{
+    \code{exp}: When the token will expire
+  }{
+    \code{aud}: Who the token is intended for. (In the above example it's for Azure's Identity Federation API)
+  }{
+    \code{team}: The team of the pipeline this token was generated for
+  }{
+    \code{pipeline}: The pipeline this token was generated for
+  }{
+    \code{job}: The name of the job (inside the pipeline) this token was generated for
+  }{
+    \code{instance_vars}: Any instance_vars for the pipeline (if it is an instanced pipeline).
+  }{
+    \code{sub}: A combination of team + pipeline + instance_vars + job. Which parts are used here is configurable, see \reference{idtoken-subject-scope}{here}.
+  }
+}
+
+\section{
+  \title{Automatic Key Rotation}{idtoken-key-rotation}
+
+  Concourse will automatically rotate the signing keys used for creating the JWTs. The default rotation period is \code{7 days}. The previously used keys are being kept around for a while (by default \code{24h})
+  so that verification of currently existing JWTs doesn't fail during key rotation.
+
+  That behavior can be configured via the following ATC flags:
+
+  \list{
+    \code{signing-key.rotation-period}: How often to rotate the signing keys. Default: \code{7d}. 0 means don't rotate at all.
+  }{
+    \code{signing-key.grace-period}: How long to keep previously used signing keys published in the JWKs after they have been superseded. Default: \code{24h}.
+  }{
+    \code{signing-key.check-interval}: How often to check if new keys are needed or if old ones should be removed. Default: \code{10m}
+  }
+
+}
+
+\right-side{Examples}{
+  \example{Vault}{
+    You can use JWTs to authenticate with \link{HashiCorp Vault}{https://developer.hashicorp.com/vault/docs/auth/jwt#jwt-authentication}. This way your pipelines can directly communicate with Vault and use all of it's features, beyond what Concourse's native Vault-integration offers.
+
+    First enable the JWT auth method in your Vault Server:
+    \codeblock{bash}{{{
+      vault auth enable jwt
+    }}}
+
+    Now configure the JWT auth method to accept JWTs issued by your Concourse:
+    \codeblock{bash}{{{
+    vault write auth/jwt/config \
+      oidc_discovery_url="https://<external_url_of_your_concourse>" \
+      default_role="demo"
+    }}}
+
+    Lastly configure a role for JWT auth. Make sure to use the same value in your pipeline that you used for \italic{bound_audiences} (the best would be the URL of your Vault). \italic{bound_subject} must be the sub-claim value of your JWT, if you use the \italic{subject_scope} setting to change the contents of your sub-claim, adapt this accordingly!
+    \codeblock{bash}{{{
+      vault write auth/jwt/role/demo \
+      role_type="jwt"\
+      user_claim="sub" \
+      bound_subject="main/your-pipeline" \
+      bound_audiences="my-vault-server.com" \
+      policies=webapps \
+      ttl=1h
+    }}}
+
+    This role will allow the holder of a JWT with \italic{aud=my-vault-server.com} and \italic{sub=main/your-pipeline} to get a Vault token with the Vault-policy "webapps". If the policy you want to assign has a different name, simply change it in the above example.
+    Make sure to adapt the value for \italic{bound_subject} according to your team and pipeline name.
+
+    Pipelines can now do the following:
+    \codeblock{bash}{{{
+      var_sources:
+      - name: vaulttoken
+        type: idtoken
+        config:
+          audience: ["my-vault-server.com"]
+
+      jobs:
+      - name: vault-login
+        plan:
+        - task: login
+          config:
+            platform: linux
+            image_resource:
+              type: registry-image
+              source: { repository: hashicorp/vault }
+            run:
+              path: sh
+              args:
+              - -e
+              - -c
+              - |
+                export VAULT_ADDR=https://my-vault-server.com
+                vault write auth/jwt/login role=demo jwt=((vaulttoken:token)) --format=json > vault-response.json
+                echo "Now do something with the token in vault-response.json"
+    }}}
+
+    You don't have to create a role and a policy for every single of your pipelines! 
+    You can use claims from the JWT with Vault's \link{policy templating}{https://developer.hashicorp.com/vault/tutorials/policies/policy-templating} feature.
+    This way you can define a policy that allows a pipeline read to all the secrets it would usually have access to using Concourse's native Vault-integration:
+
+    \codeblock{bash}{{{
+      path "concourse/metadata/{{ identity.entity.aliases.<JWT_ACCESSOR>.metadata.team }}" {
+        capabilities = ["list"]
+      }
+
+      path "concourse/data/{{ identity.entity.aliases.<JWT_ACCESSOR>.metadata.team }}/+" {
+        capabilities = ["read"]
+      }
+
+      path "concourse/metadata/{{ identity.entity.aliases.<JWT_ACCESSOR>.metadata.team }}/{{ identity.entity.aliases.<JWT_ACCESSOR>.metadata.pipeline }}" {
+        capabilities = ["list"]
+      }
+
+      path "concourse/metadata/{{ identity.entity.aliases.<JWT_ACCESSOR>.metadata.team }}/{{ identity.entity.aliases.<JWT_ACCESSOR>.metadata.pipeline }}/*" {
+        capabilities = ["read", "list"]
+      }
+
+      path "concourse/data/{{ identity.entity.aliases.<JWT_ACCESSOR>.metadata.team }}/{{ identity.entity.aliases.<JWT_ACCESSOR>.metadata.pipeline }}/*" {
+        capabilities = ["read", "list"]
+      }
+    }}}
+    \smaller{Make sure to set \italic{<JWT_ACCESSOR>} to the actual mount-accessor value of your JWT Auth method! You can use \italic{vault auth list --format=json | jq -r '."jwt/".accessor'} to get the accessor for your jwt auth method.}
+
+    With a policy like this you don't need to configure \italic{bound_subject} in your JWT auth role. Every single pipeline can simply use the same role and the policy will take care that they can only access secrets meant for them. However you need to explicitly configure claim to metadata mapping:
+
+    \codeblock{bash}{{{
+      vault write auth/jwt/role/demo \
+        role_type="jwt"\
+        user_claim="sub" \
+        bound_subject= \
+        bound_audiences="my-vault-server.com" \
+        policies=pipeline-new \
+        claim_mappings='team=team' \
+        claim_mappings='pipeline=pipeline' \
+        ttl=1h
+    }}}
+
+  }
+
+  \example{AWS}{
+    AWS supports \link{federation with external identity providers}{https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers.html}. 
+    Using this you can allow identities managed by an external identity provider to perform actions in your AWS account.
+
+    In this scenario the external identity provider is Concourse and the identities are teams/pipelines/jobs.
+    This means you are able to grant a specific pipeline or job permissions to perform actions in AWS (like deploying something). All without managing IAM-Users or dealing
+    with long-lived credentials.
+
+    First you need to \link{create an OpenID Connect identity provider}{https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_create_oidc.html} in your AWS Account.
+    As \italic{Provider URL} specify the external URL of your Concourse server.
+    For \italic{Audience} you can choose any string you like. Using something like \italic{sts.amazonaws.com} is recommended. You have to use the same string later in the configuration of your var-source.
+
+    Next you will need to \link{create an IAM-Role that can be assumed using your JWT}{https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-idp_oidc.html#idp_oidc_Create}.
+    As \italic{Identity Provider} choose the one you created previously.
+    Add a condition on the sub-claim with type \italic{StringEquals} and value \italic{yourteam/yourpipeline}. This will allow ONLY that specific pipeline (and any instanced versions of it) to assume that IAM Role using a JWT. If you use the \italic{subject_scope} setting to change the contents of your sub-claim, adapt this condition accordingly!
+    In the next step you will be able to choose which AWS permissions your role will get.
+
+    Now you can use the AWS \link{AssumeRoleWithWebIdentity API operation}{https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRoleWithWebIdentity.html} to assume your role via a JWT issued by Concourse.
+    The easiest way is to do this is via the \link{assume-role-with-web-identity AWS CLI command}{https://docs.aws.amazon.com/cli/latest/reference/sts/assume-role-with-web-identity.html}:
+    \codeblock{bash}{{{
+      var_sources:
+      - name: awstoken
+        type: idtoken
+        config:
+          audience: ["sts.amazonaws.com"]
+
+      jobs:
+      - name: aws-login
+        plan:
+        - task: print
+          config:
+            platform: linux
+            image_resource:
+              type: registry-image
+              source: { repository: amazon/aws-cli }
+            run:
+              path: bash
+              args:
+              - -e
+              - -c
+              - |
+                aws sts assume-role-with-web-identity --role-session-name Concourse --role-arn arn:aws:iam::<your_account>:role/<your_role> --web-identity-token ((awstoken:token)) > creds.json
+                echo "Now do something with the temporary credentials in creds.json"
+    }}}
+  }
+
+  \example{Azure}{
+    Azure also supports a way to grant the holder of a JWT permissions in the Cloud. This is done via a feature called \link{Federated Credentials}{https://learn.microsoft.com/en-us/graph/api/resources/federatedidentitycredentials-overview?view=graph-rest-1.0}.
+
+    First, \link{create an EntraID App Registration}{https://learn.microsoft.com/en-us/entra/identity-platform/quickstart-register-app}. This app registration will be the service principal used by your pipeline.
+
+    Now \link{create a federated credential}{https://learn.microsoft.com/en-us/entra/workload-id/workload-identity-federation-create-trust?pivots=identity-wif-apps-methods-azp#other-identity-providers} for the app registration you just created.
+    As \italic{Scenario} select "Other". As \italic{Issuer} paste the URL of your Concourse server. As \italic{Type} select "Explicit subject identifier" and as \italic{Value} use \italic{<teamname>/<pipelinename>} of the pipeline that should be able to use the identity. If you use the \italic{subject_scope} setting to change the contents of your sub-claim, adapt this setting here accordingly!
+
+    You can now assign IAM permissions to the identity of the app registration, which define what the identity is allowed to do in your Azure subscription. You most probably already know how to do this.
+
+    Your pipeline can now use the az cli to login to Azure using a JWT generated by Concourse:
+    \codeblock{bash}{{{
+      var_sources:
+      - name: azuretoken
+        type: idtoken
+        config:
+          audience: ["api://AzureADTokenExchange"]
+
+      jobs:
+      - name: azure-deploy
+        plan:
+        - task: login
+          config:
+            platform: linux
+            image_resource:
+              type: registry-image
+              source: { repository: mcr.microsoft.com/azure-cli }
+            run:
+              path: bash
+              args:
+              - -e
+              - -c
+              - |
+                echo ((azuretoken:token))
+                az login --service-principal -u <client_id of your app registration> --tenant <tenant_id of your app registration> --federated-token ((azuretoken:token))
+                echo "You are now authenticated with Azure. Do something with it!"
+    }}}
+
+  }
+}