Deployment Guide
Installing and configuring the Trusted Artifact Signer service on Red Hat OpenShift
Abstract
Preface
Welcome to the Red Hat Trusted Artifact Signer Deployment Guide!
These procedures can help guide you on deploying the full Trusted Artifact Signer (RHTAS) software stack on OpenShift, and verify that deployment. You can view the official RHTAS Release Notes here.
Chapter 1. Select your installation platform
As as systems administrator, you can select two different installation platforms to run Red Hat Trusted Artifact Signer (RHTAS). You can deploy RHTAS to Red Hat OpenShift Container Platform, or to Red Hat Enterprise Linux by using Ansible.
Deploying RHTAS to Red Hat Enterprise Linux is currently a Technical Preview feature.
Select your installation platform:
1.1. Installing Trusted Artifact Signer using the Operator Lifecycle Manager
You can install the Red Hat Trusted Artifact Signer (RHTAS) operator, and deploy the RHTAS service by using OpenShift’s Operator Lifecycle Manager (OLM). This deployment gives you a basic signing framework with your choice of an OpenID Connect (OIDC) provider. You must configure at least one of the following OIDC providers: Red Hat Single Sign-on (SSO), Google, Amazon Secure Token Service (STS), or GitHub. You can also optionally customize your database solution, if you do not want to use the default.
Prerequisites
- Red Hat OpenShift Container Platform version 4.13 or later.
-
Access to the OpenShift web console with the
cluster-admin
role. -
A workstation with the
oc
binary installed.
Procedure
-
Log in to the OpenShift web console with a user that has the
cluster-admin
role. - From the Administrator perspective, expand the Operators navigation menu, and click OperatorHub.
- In the search field, type trusted, and click the Red Hat Trusted Artifact Signer tile.
- Click the Install button to show the operator details.
Accept the default values, click Install on the Install Operator page, and wait for the installation to finish.
ImportantOnce the installation finishes, a new project is automatically created for you. The new project name is
trusted-artifact-signer
.NoteThe Trusted Artifact Signer operator installs into the
openshift-operators
namespace, and all dependencies are automatically installed.- Optional. Instead of the default database, you can use an alternative database provider for the Trusted Artifact Signer service. If you want to use Amazon’s Relational Database Service (RDS), or a self-managed database on OpenShift, then follow one of those procedures first before continuing on with this installation. Once done configuring one of these other database providers, you can continue onto the next step of this procedure.
To deploy the Trusted Artifact Signer service.
- Expand Operators from the navigation menu, click Installed Operators.
-
Select
trusted-artifact-signer
from the project drop-down box. - Click Red Hat Trusted Artifact Signer.
- Click the Securesign tab, and click the Create Securesign button.
- On the Create Securesign page, select YAML view.
You can configure Google OAuth, Amazon STS, Red Hat’s SSO, or GitHub OAuth as the initial OIDC provider during this deployment. Under the
spec.fulcio.config.OIDCIssuers
section, edit the following three lines with the OIDC provider URL, and set theClientID
appropriately.Example
... OIDCIssuers: - Issuer: 'OIDC_ISSUER_URL': ClientID: CLIENT_ID IssuerURL: 'OIDC_ISSUER_URL' Type: email ...
ImportantYou can define several different OIDC providers in the same configuration.
NoteIf Red Hat’s SSO is already implemented as your OIDC provider, then run the following command to find the issuer URL:
$ echo https://$(oc get route keycloak -n keycloak-system | tail -n 1 | awk '{print $2}')/auth/realms/trusted-artifact-signer
Set the
ClientID
totrusted-artifact-signer
.Optional. If using a different database other than the default, then under the
spec.trillian
section, setcreate
tofalse
, and give the name of the database secret object.Example
... trillian: database: create: false databaseSecretRef: name: trillian-mysql ...
- Click the Create button.
Click All instances tab to watch the deployment status until the CTlog, Fulcio, Rekor, Trillian, and TUF instances are ready.
NoteThe Securesign instance does not give a status.
- You can check on the health of the new Trusted Artifact Signer service by using Prometheus in the OpenShift console. From the navigation menu, expand Observe, and click Dashboards.
- Verify the installation by signing a container image, or a Git commit.
Additional resources
- See the Appendix in the RHTAS Deployment Guide for more information about RHTAS components and version numbers.
1.2. Installing Trusted Artifact Signer using Ansible
You can install the Red Hat Trusted Artifact Signer (RHTAS) on Red Hat Enterprise Linux by using a Red Hat provided Ansible Playbook. This deployment gives you a basic signing framework with Keycloak as the OpenID Connect (OIDC) provider.
Deploying RHTAS on Red Hat Enterprise Linux by using Ansible is a Technology Preview feature only. Technology Preview features are not supported with Red Hat production service level agreements (SLAs), might not be functionally complete, and Red Hat does not recommend to use them for production. These features provide early access to upcoming product features, enabling customers to test functionality and provide feedback during the development process. See the support scope for Red Hat Technology Preview features for more details.
Prerequisites
- Red Hat Enterprise Linux version 9.2 or later.
- A Red Hat user account to access the Red Hat Hybrid Cloud Console.
Procedure
- Log in to the Red Hat Hybrid Cloud Console with your Red Hat credentials.
- From the home page, click the Services drop-down menu, and click Red Hat Ansible Automation Platform.
- From the navigational menu, expand Automation Hub, and click Collections.
- In the search field type rhtas and press enter.
- Click the artifact_signer link on the Red Hat Trusted Artifact Signer tile.
Click the Documentation tab, and follow the steps there to complete the installation of RHTAS on Red Hat Enterprise Linux.
NoteFor a detailed overview of all the configuration parameters, click the tas_single_node link under the Roles section.
Additional resources
- See the Appendix in the RHTAS Deployment Guide for more information about RHTAS components and version numbers.
Chapter 2. Verify the Trusted Artifact Signer service installation
2.1. Signing and verifying containers by using Cosign from the command-line interface
The cosign
tool gives you the capability to sign and verify Open Container Initiative (OCI) container images, along with other build artifacts by using Red Hat’s Trusted Artifact Signer (RHTAS) service.
Prerequisites
- A RHTAS installation on Red Hat OpenShift Container Platform version 4.13 or later.
- Access to the OpenShift web console.
-
A workstation with the
podman
, andoc
binaries installed.
Procedure
Download the
cosign
binary from the OpenShift cluster to your workstation.- Login to the OpenShift web console. From the home page, click the ? icon, click Command line tools, go to the cosign download section, and click the link for your platform.
Open a terminal on your workstation, decompress the binary
.gz
file, and set the execute bit:Example
$ gunzip cosign-amd64.gz $ chmod +x cosign-amd64
Move and rename the binary to a location within your
$PATH
environment:Example
$ sudo mv cosign-amd64 /usr/local/bin/cosign
Log in to the OpenShift cluster:
Syntax
oc login --token=TOKEN --server=SERVER_URL_AND_PORT
Example
$ oc login --token=sha256~ZvFDBvoIYAbVECixS4-WmkN4RfnNd8Neh3y1WuiFPXC --server=https://example.com:6443
NoteYou can find your login token and URL to use on the command line from the OpenShift web console. Log in to the OpenShift web console. Click your user name, and click Copy login command. Offer your user name and password again, if asked, and click Display Token to view the command.
Switch to the RHTAS project:
Syntax
oc project PROJECT_NAME
Example
$ oc project trusted-artifact-signer
NoteUse the project name for the RHTAS installation.
Configure your shell environment for doing container image signing and verifying.
Example
$ export TUF_URL=$(oc get tuf -o jsonpath='{.items[0].status.url}' -n trusted-artifact-signer) $ export OIDC_ISSUER_URL=https://$(oc get route keycloak -n keycloak-system | tail -n 1 | awk '{print $2}')/auth/realms/trusted-artifact-signer $ export COSIGN_FULCIO_URL=$(oc get fulcio -o jsonpath='{.items[0].status.url}' -n trusted-artifact-signer) $ export COSIGN_REKOR_URL=$(oc get rekor -o jsonpath='{.items[0].status.url}' -n trusted-artifact-signer) $ export COSIGN_MIRROR=$TUF_URL $ export COSIGN_ROOT=$TUF_URL/root.json $ export COSIGN_OIDC_CLIENT_ID="trusted-artifact-signer" $ export COSIGN_OIDC_ISSUER=$OIDC_ISSUER_URL $ export COSIGN_CERTIFICATE_OIDC_ISSUER=$OIDC_ISSUER_URL $ export COSIGN_YES="true" $ export SIGSTORE_FULCIO_URL=$COSIGN_FULCIO_URL $ export SIGSTORE_OIDC_ISSUER=$COSIGN_OIDC_ISSUER $ export SIGSTORE_REKOR_URL=$COSIGN_REKOR_URL $ export REKOR_REKOR_SERVER=$COSIGN_REKOR_URL
Initialize The Update Framework (TUF) system:
Example
$ cosign initialize
Sign a test container image.
Create an empty container image:
Example
$ echo "FROM scratch" > ./tmp.Dockerfile $ podman build . -f ./tmp.Dockerfile -t ttl.sh/rhtas/test-image:1h
Push the empty container image to the
ttl.sh
ephemeral registry:Example
$ podman push ttl.sh/rhtas/test-image:1h
Sign the container image:
Syntax
cosign sign -y IMAGE_NAME:TAG
Example
$ cosign sign -y ttl.sh/rhtas/test-image:1h
A web browser opens allowing you to sign the container image with an email address.
Remove the temporary Docker file:
Example
$ rm ./tmp.Dockerfile
Verify a signed container image by using a certificate identity and issuer:
Syntax
cosign verify --certificate-identity=SIGNING_EMAIL_ADDR IMAGE_NAME:TAG
Example
$ cosign verify --certificate-identity=jdoe@redhat.com ttl.sh/rhtas/test-image:1h
NoteYou can also use regular expressions for the certificate identity and issuer by using the following options to the
cosign
command,--certificate-identity-regexp
and--certificate-oidc-issuer-regexp
.Download the
rekor-cli
binary from the OpenShift cluster to your workstation.- Login to the OpenShift web console. From the home page, click the ? icon, click Command line tools, go to the rekor-cli download section, and click the link for your platform.
Open a terminal on your workstation, decompress the binary
.gz
file, and set the execute bit:Example
$ gunzip rekor-cli-amd64.gz $ chmod +x rekor-cli-amd64
Move and rename the binary to a location within your
$PATH
environment:Example
$ sudo mv rekor-cli-amd64 /usr/local/bin/rekor-cli
Query the transparency log by using the Rekor command-line interface.
Search based on the log index:
Example
$ rekor-cli get --log-index 0 --rekor_server $COSIGN_REKOR_URL --format json | jq
Search for an email address to get the universal unique identifier (UUID):
Syntax
rekor-cli search --email SIGNING_EMAIL_ADDR --rekor_server $COSIGN_REKOR_URL --format json | jq
Example
$ rekor-cli search --email jdoe@redhat.com --rekor_server $COSIGN_REKOR_URL --format json | jq
This command returns the UUID for use with the next step.
Use the UUID to get the transaction details:
Syntax
rekor-cli get --uuid UUID --rekor_server $COSIGN_REKOR_URL --format json | jq
Example
$ rekor-cli get --uuid 24296fb24b8ad77a71b9c1374e207537bafdd75b4f591dcee10f3f697f150d7cc5d0b725eea641e7 --rekor_server $COSIGN_REKOR_URL --format json | jq
Additional resources
- Installing Red Hat Trusted Artifact Signer on OpenShift.
- Customizing Red Hat Trusted Application Pipeline.
- See the Signing and verifying commits by using Gitsign from the command-line interface section of the RHTAS Deployment Guide for details on signing and verifying Git commits.
- The Update Framework home page.
2.2. Signing and verifying commits by using Gitsign from the command-line interface
The gitsign
tool gives you the ability to sign and verify Git repository commits by using Red Hat’s Trusted Artifact Signer (RHTAS) service.
Prerequisites
- A RHTAS installation on Red Hat OpenShift Container Platform version 4.13 or later.
- Access to the OpenShift web console.
-
A workstation with the
oc
, andgit
binaries installed. -
Downloaded the
cosign
binary from the OpenShift cluster.
Procedure
Download the
gitsign
binary from the OpenShift cluster to your workstation.- Login to the OpenShift web console. From the home page, click the ? icon, click Command line tools, go to the gitsign download section, and click the link for your platform.
Open a terminal on your workstation, decompress the .gz file, and set the execute bit:
Example
$ gunzip gitsign-amd64.gz $ chmod +x gitsign-amd64
Move and rename the binary to a location within your
$PATH
environment:Example
$ sudo mv gitsign-amd64 /usr/local/bin/gitsign
Log in to the OpenShift cluster:
Syntax
oc login --token=TOKEN --server=SERVER_URL_AND_PORT
Example
$ oc login --token=sha256~ZvFDBvoIYAbVECixS4-WmkN4RfnNd8Neh3y1WuiFPXC --server=https://example.com:6443
NoteYou can find your login token and URL to use on the command line from the OpenShift web console. Log in to the OpenShift web console. Click your user name, and click Copy login command. Offer your user name and password again, if asked, and click Display Token to view the command.
Switch to the RHTAS project:
Syntax
oc project PROJECT_NAME
Example
$ oc project trusted-artifact-signer
NoteUse the project name for the RHTAS installation.
Configure your shell environment for doing commit signing and verifying:
Example
$ export TUF_URL=$(oc get tuf -o jsonpath='{.items[0].status.url}' -n trusted-artifact-signer) $ export OIDC_ISSUER_URL=https://$(oc get route keycloak -n keycloak-system | tail -n 1 | awk '{print $2}')/auth/realms/trusted-artifact-signer $ export COSIGN_FULCIO_URL=$(oc get fulcio -o jsonpath='{.items[0].status.url}' -n trusted-artifact-signer) $ export COSIGN_REKOR_URL=$(oc get rekor -o jsonpath='{.items[0].status.url}' -n trusted-artifact-signer) $ export COSIGN_MIRROR=$TUF_URL $ export COSIGN_ROOT=$TUF_URL/root.json $ export COSIGN_OIDC_CLIENT_ID="trusted-artifact-signer" $ export COSIGN_OIDC_ISSUER=$OIDC_ISSUER_URL $ export COSIGN_CERTIFICATE_OIDC_ISSUER=$OIDC_ISSUER_URL $ export COSIGN_YES="true" $ export SIGSTORE_FULCIO_URL=$COSIGN_FULCIO_URL $ export SIGSTORE_OIDC_ISSUER=$COSIGN_OIDC_ISSUER $ export SIGSTORE_REKOR_URL=$COSIGN_REKOR_URL $ export REKOR_REKOR_SERVER=$COSIGN_REKOR_URL
Configure the local repository configuration to sign your commits by using the RHTAS service:
Example
$ git config --local commit.gpgsign true $ git config --local tag.gpgsign true $ git config --local gpg.x509.program gitsign $ git config --local gpg.format x509 $ git config --local gitsign.fulcio $SIGSTORE_FULCIO_URL $ git config --local gitsign.rekor $SIGSTORE_REKOR_URL $ git config --local gitsign.issuer $SIGSTORE_OIDC_ISSUER $ git config --local gitsign.clientID trusted-artifact-signer
Make a commit to the local repository:
Example
$ git commit --allow-empty -S -m “Test of a signed commit”
A web browser opens allowing you to sign the commit with an email address.
Initialize The Update Framework (TUF) system:
Example
$ cosign initialize
Verify the commit:
Syntax
gitsign verify --certificate-identity=SIGNING_EMAIL --certificate-oidc-issuer=$SIGSTORE_OIDC_ISSUER HEAD
Example
$ gitsign verify --certificate-identity=jdoe@redhat.com --certificate-oidc-issuer=$SIGSTORE_OIDC_ISSUER HEAD
Additional resources
- Installing Red Hat Trusted Artifact Signer on OpenShift.
- Customizing Red Hat Trusted Application Pipeline.
- See the Signing and verifying containers by using Cosign from the command-line interface section in the RHTAS Deployment Guide for details on signing and verifying container images.
- The Update Framework home page.
2.3. Verifying signatures on container images with Enterprise Contract
Enterprise Contract (EC) is a tool for maintaining the security of software supply chains, and you can use it to define and enforce policies for container images. You can use the ec
binary to verify the attestation and signature of container images that use Red Hat’s Trusted Artifact Signer (RHTAS) signing framework.
Prerequisites
- A RHTAS installation on Red Hat OpenShift Container Platform version 4.13 or later.
-
A workstation with the
oc
,cosign
, andpodman
binaries installed. - Access to the OpenShift web console.
Procedure
Download the
ec
binary from the OpenShift cluster.- Log in to the OpenShift web console. From the home page, click the ? icon, click Command line tools, go to the ec download section, then click the link for your platform.
Open a terminal on your workstation, decompress the binary .gz file, and set the execute bit:
Example
$ gunzip ec-amd64.gz $ chmod +x ec-amd64
Move and rename the binary to a location within your
$PATH
environment:Example
$ sudo mv ec-amd64 /usr/local/bin/ec
Log in to the OpenShift cluster:
Syntax
oc login --token=TOKEN --server=SERVER_URL_AND_PORT
Example
$ oc login --token=sha256~ZvFDBvoIYAbVECixS4-WmkN4RfnNd8Neh3y1WuiFPXC --server=https://example.com:6443
NoteYou can find your login token and URL to use on the command line from the OpenShift web console. Log in to the OpenShift web console. Click your user name, and click Copy login command. Offer your user name and password again, if asked, and click Display Token to view the command.
Switch to the RHTAS project:
Syntax
oc project PROJECT_NAME
Example
$ oc project trusted-artifact-signer
NoteUse the project name for the RHTAS installation.
Configure your shell environment for doing container image signing and verifying.
Example
$ export TUF_URL=$(oc get tuf -o jsonpath='{.items[0].status.url}' -n trusted-artifact-signer) $ export OIDC_ISSUER_URL=https://$(oc get route keycloak -n keycloak-system | tail -n 1 | awk '{print $2}')/auth/realms/trusted-artifact-signer $ export COSIGN_FULCIO_URL=$(oc get fulcio -o jsonpath='{.items[0].status.url}' -n trusted-artifact-signer) $ export COSIGN_REKOR_URL=$(oc get rekor -o jsonpath='{.items[0].status.url}' -n trusted-artifact-signer) $ export COSIGN_MIRROR=$TUF_URL $ export COSIGN_ROOT=$TUF_URL/root.json $ export COSIGN_OIDC_CLIENT_ID="trusted-artifact-signer" $ export COSIGN_OIDC_ISSUER=$OIDC_ISSUER_URL $ export COSIGN_CERTIFICATE_OIDC_ISSUER=$OIDC_ISSUER_URL $ export COSIGN_YES="true" $ export SIGSTORE_FULCIO_URL=$COSIGN_FULCIO_URL $ export SIGSTORE_OIDC_ISSUER=$COSIGN_OIDC_ISSUER $ export SIGSTORE_REKOR_URL=$COSIGN_REKOR_URL $ export REKOR_REKOR_SERVER=$COSIGN_REKOR_URL
Initialize The Update Framework (TUF) system:
Example
$ cosign initialize
Sign a test container image.
Create an empty container image:
Example
$ echo "FROM scratch" > ./tmp.Dockerfile $ podman build . -f ./tmp.Dockerfile -t ttl.sh/rhtas/test-image:1h
Push the empty container image to the
ttl.sh
ephemeral registry:Example
$ podman push ttl.sh/rhtas/test-image:1h
Sign the container image:
Syntax
cosign sign -y IMAGE_NAME:TAG
Example
$ cosign sign -y ttl.sh/rhtas/test-image:1h
A web browser opens allowing you to sign the container image with an email address.
Remove the temporary Docker file:
Example
$ rm ./tmp.Dockerfile
Create a
predicate.json
file:Example
{ "builder": { "id": "https://localhost/dummy-id" }, "buildType": "https://example.com/tekton-pipeline", "invocation": {}, "buildConfig": {}, "metadata": { "completeness": { "parameters": false, "environment": false, "materials": false }, "reproducible": false }, "materials": [] }
Refer to the SLSA provenance predicate specifications for more information about the schema layout.
Associate the
predicate.json
file with the container image:Syntax
cosign attest -y --predicate ./predicate.json --type slsaprovenance IMAGE_NAME:TAG
Example
$ cosign attest -y --predicate ./predicate.json --type slsaprovenance ttl.sh/rhtas/test-image:1h
Verify that the container image has at least one attestation and signature:
Syntax
cosign tree IMAGE_NAME:TAG
Example
$ cosign tree ttl.sh/rhtas/test-image:1h 📦 Supply Chain Security Related artifacts for an image: ttl.sh/rhtas/test-image@sha256:7de5fa822a9d1e507c36565ee0cf50c08faa64505461c844a3ce3944d23efa35 └── 💾 Attestations for an image tag: ttl.sh/rhtas/test-image:sha256-7de5fa822a9d1e507c36565ee0cf50c08faa64505461c844a3ce3944d23efa35.att └── 🍒 sha256:40d94d96a6d3ab3d94b429881e1b470ae9a3cac55a3ec874051bdecd9da06c2e └── 🔐 Signatures for an image tag: ttl.sh/rhtas/test-image:sha256-7de5fa822a9d1e507c36565ee0cf50c08faa64505461c844a3ce3944d23efa35.sig └── 🍒 sha256:f32171250715d4538aec33adc40fac2343f5092631d4fc2457e2116a489387b7
Verify the container image by using Enterprise Contact:
Syntax
ec validate image --image IMAGE_NAME:TAG --certificate-identity-regexp 'SIGNER_EMAIL_ADDR' --certificate-oidc-issuer-regexp 'keycloak-keycloak-system' --output yaml --show-successes
Example
$ ec validate image --image ttl.sh/rhtas/test-image:1h --certificate-identity-regexp 'jdoe@example.com' --certificate-oidc-issuer-regexp 'keycloak-keycloak-system' --output yaml --show-successes success: true successes: - metadata: code: builtin.attestation.signature_check msg: Pass - metadata: code: builtin.attestation.syntax_check msg: Pass - metadata: code: builtin.image.signature_check msg: Pass ec-version: v0.1.2427-499ef12 effective-time: "2024-01-21T19:57:51.338191Z" key: "" policy: {} success: true
Enterprise Contract generates a pass-fail report with details on any security violations. When you add the
--info
flag, the report includes more details and possible solutions for any violations found.
Additional resources
- Installing Red Hat Trusted Artifact Signer on OpenShift.
- Managing compliance with Enterprise Contract.
- See the Enterprise Contract website for more information.
Chapter 3. Configure additional OpenID Connect providers
3.1. Configuring Google as an OpenID Connect provider for Trusted Artifact Signer
You can use Google OAuth 2.0 as your OpenID Connect (OIDC) provider for Red Hat’s Trusted Artifact Signer (RHTAS) service. You can decide to configure Google OAuth during the deployment of RHTAS, or at a later time.
You can define several different OIDC providers in the same configuration.
Prerequisites
- Red Hat OpenShift Container Platform version 4.13 or later.
-
Access to the OpenShift web console with the
cluster-admin
role. -
A workstation with the
oc
, andpodman
binaries installed. From the Google Cloud Console, create an OAuth client ID with the following settings:
- Set the application type to “Web Application”.
- Authorized redirect URIs must include: http://localhost/auth/callback .
Procedure
Open a terminal on your workstation, and log in to OpenShift:
Syntax
oc login --token=TOKEN --server=SERVER_URL_AND_PORT
Example
$ oc login --token=sha256~ZvFDBvoIYAbVECixS4-WmkN4RfnNd8Neh3y1WuiFPXC --server=https://example.com:6443
NoteYou can find your login token and URL for use on the command line from the OpenShift web console. Log in to the OpenShift web console. Click your user name, and click Copy login command. Offer your user name and password again, if asked, and click Display Token to view the command.
Update the RHTAS configuration.
Open for editing the
Securesign
resource:Syntax
oc edit Securesign NAME -n NAMESPACE
Example
$ oc edit Securesign securesign-sample -n trusted-artifact-signer
NoteYou must use the project name created for the RHTAS installation as the namespace.
Under the
OIDCIssuers
section, add a new subsection with your Google client identifier, issuer’s URL, and set theType
value toemail
:Syntax
... OIDCIssuers: - Issuer: "https://accounts.google.com" IssuerURL: "https://accounts.google.com" ClientID: "CLIENT_ID" Type: email ...
Add you Google client identifier to the
ClientID
field.- Save your changes, and quit the editor. After a few seconds the operator automatically reconfigures the RHTAS software stack.
Change the OIDC issuer, and client id environment variables to use Google:
Example
$ export OIDC_ISSUER_URL=https://accounts.google.com $ export COSIGN_OIDC_CLIENT_ID="314919563931-35zke44ouf2oiztjg7v8o8c2ge9usnd1.apps.googleexample.com"
Copy and paste your secret from the Google Console to a plain text file:
Syntax
echo SECRET > my-google-client-secret
If you already have the RHTAS service running, you can verify the updated configuration by signing a test container image.
Create an empty container image:
Example
$ echo "FROM scratch" > ./tmp.Dockerfile $ podman build . -f ./tmp.Dockerfile -t ttl.sh/rhtas/test-image:1h
Push the empty container image to the
ttl.sh
ephemeral registry:Example
$ podman push ttl.sh/rhtas/test-image:1h
Remove the temporary Docker file:
Example
$ rm ./tmp.Dockerfile
Sign the container image:
Syntax
cosign sign -y --oidc-client-secret-file=SECRET_FILE IMAGE_NAME:TAG
Example
$ cosign sign -y --oidc-client-secret-file=my-google-client-secret ttl.sh/rhtas/test-image:1h
A web browser opens allowing you to sign the container image with an email address.
Additional resources
3.2. Configuring Red Hat SSO as an OpenID Connect provider for Trusted Artifact Signer
You can use Red Hat Single Sign-On (SSO) as your OpenID Connect provider for Red Hat’s Trusted Artifact Signer (RHTAS) service. This gives you a Keycloak authentication environment for applications and secure services.
Prerequisites
- Red Hat OpenShift Container Platform version 4.13 or later.
-
Access to the OpenShift web console with the
cluster-admin
role. - Have 1 GB of container storage available for the Keycloak PostgreSQL database.
-
A workstation with the
oc
binary installed.
Procedure
-
Log in to the OpenShift web console with a user that has the
cluster-admin
role. Create a new project to deploy the Keycloak service.
- From the Administrator perspective, expand Home from the navigation menu, and click Projects.
- Click the Create Project button.
-
The new project name is
keycloak-system
, and click the Create button.
- Expand Operators from the navigation menu, and click OperatorHub.
- In the search field, type sso, and click the Red Hat Single Sign-on tile.
- Click the Install button to show the operator details.
-
If not already set, select
keycloak-system
from the Installed Namespace drop-down menu. - Click Install on the Install Operator page, and wait for the installation to finish.
- After the installation finishes, click View Operator.
From your workstation terminal, log in to the OpenShift cluster:
Syntax
oc login --token=TOKEN --server=SERVER_URL_AND_PORT
Example
$ oc login --token=sha256~ZvFDBvoIYAbVECixS4-WmkN4RfnNd8Neh3y1WuiFPXC --server=https://example.com:6443
NoteYou can find your login token and URL to use on the command line from the OpenShift web console. Log in to the OpenShift web console. Click your user name, and click Copy login command. Offer your user name and password again, if asked, and click Display Token to view the command.
Switch to the Keycloak project:
Example
$ oc project keycloak-system
Create a Keycloak instance:
Example
$ cat <<EOF | oc apply -f - apiVersion: keycloak.org/v1alpha1 kind: Keycloak metadata: labels: app: sso name: keycloak spec: externalAccess: enabled: true instances: 1 keycloakDeploymentSpec: imagePullPolicy: Always postgresDeploymentSpec: imagePullPolicy: Always EOF
Create a Keycloak realm:
Example
$ cat <<EOF | oc apply -f - apiVersion: keycloak.org/v1alpha1 kind: KeycloakRealm metadata: labels: app: sso name: trusted-artifact-signer spec: instanceSelector: matchLabels: app: sso realm: displayName: Red-Hat-Trusted-Artifact-Signer enabled: true id: trusted-artifact-signer realm: trusted-artifact-signer sslRequired: none EOF
Create a Keycloak client:
Example
$ cat <<EOF | oc apply -f - apiVersion: keycloak.org/v1alpha1 kind: KeycloakClient metadata: labels: app: sso name: trusted-artifact-signer spec: client: attributes: request.object.signature.alg: RS256 user.info.response.signature.alg: RS256 clientAuthenticatorType: client-secret clientId: trusted-artifact-signer defaultClientScopes: - profile - email description: Client for Red Hat Trusted Artifact Signer authentication directAccessGrantsEnabled: true implicitFlowEnabled: false name: trusted-artifact-signer protocol: openid-connect protocolMappers: - config: claim.name: email id.token.claim: "true" jsonType.label: String user.attribute: email userinfo.token.claim: "true" name: email protocol: openid-connect protocolMapper: oidc-usermodel-property-mapper - config: claim.name: email-verified id.token.claim: "true" user.attribute: emailVerified userinfo.token.claim: "true" name: email-verified protocol: openid-connect protocolMapper: oidc-usermodel-property-mapper - config: claim.name: aud claim.value: trusted-artifact-signer id.token.claim: "true" access.token.claim: "true" userinfo.token.claim: "true" name: audience protocol: openid-connect protocolMapper: oidc-hardcoded-claim-mapper publicClient: true standardFlowEnabled: true redirectUris: - "*" realmSelector: matchLabels: app: sso EOF
Create a Keycloak user:
Example
$ cat <<EOF | oc apply -f - apiVersion: keycloak.org/v1alpha1 kind: KeycloakUser metadata: labels: app: sso name: jdoe spec: realmSelector: matchLabels: app: sso user: email: jdoe@redhat.com enabled: true emailVerified: true credentials: - type: "password" value: "secure" firstName: Jane lastName: Doe username: jdoe EOF
Set a user name, the user’s email address, and a password or reference a secret object.
- Go back to the OpenShift web console, click the All instances tab to watch and wait until the Keycloak system initializes successfully.
Additional resources
3.3. Configuring Red Hat build of Keycloak as an OpenID Connect provider for Trusted Artifact Signer
You can configure Red Hat’s build of Keycloak (RHBK) as an OpenID Connect (OIDC) provider for Red Hat’s Trusted Artifact Signer (RHTAS) service. This procedure guides you on integrating RHBK with RHTAS.
You can define several different OIDC providers for Fulcio in the same SecureSign configuration.
Prerequisites
- A RHTAS installation on OpenShift Container Platform version 4.13 or later.
-
Access to the OpenShift web console with the
cluster-admin
role. -
A workstation with the
oc
binary installed. - Have 1 GB of persistent storage available for the Keycloak PostgreSQL database.
- A TLS certificate and key.
Procedure
-
Log in to the OpenShift web console with a user that has the
cluster-admin
role. Create a new project to deploy the Keycloak service.
- From the Administrator perspective, expand Home from the navigation menu, and click Projects.
- Click the Create Project button.
-
The new project name is
keycloak-system
, and click the Create button.
Deploy an instance of PostgreSQL for use by Keycloak to store persistent data.
ImportantIf a database already exists for use by Keycloak, replace the
username
,password
anddatabase
name values for theSecret
resource that corresponds with your database instance. You can skip the creation of the PostgreSQL Service and StatefulSet steps, and move ahead to the next step.Create a
Secret
resource to store the database information.- Expand Workloads from the navigation menu, and click Secrets.
-
Select the
keycloak-system
from the Project drop-down menu. - Click the Create drop-down menu, and select Key/Value secret.
-
Enter
postgresql-db
in the Secret name field. -
Enter
username
in the Key field. -
Enter
keycloak
in the Value field. This is the user name Keycloak uses to authenticate to the PostgreSQL database instance. - Click the Add key/value link to add another key-value pair.
-
Enter
password
in the Key field. - Enter a password of your choice in the Value field. This is the password Keycloak uses to authenticate to the PostgreSQL database instance.
- Click the Add key/value link to add another key-value pair.
-
Enter
database
in the Key field. -
Enter
keycloak
in the Value field. This is the name of the database for storing Keycloak data within the PostgreSQL database instance. - Click the Create button.
Create the PostgreSQL Service and StatefulSet.
- Click the + icon.
- Copy the Service and StatefulSet YAML configuration text, and on the Import YAML page, paste the text into the text editor box.
-
Click the Create button to add the Service and StatefulSet to the
keycloak-system
project.
Open a terminal from your workstation, and log in to the OpenShift cluster:
Syntax
oc login --token=TOKEN --server=SERVER_URL_AND_PORT
Example
$ oc login --token=sha256~ZvFDBvoIYAbVECixS4-WmkN4RfnNd8Neh3y1WuiFPXC --server=https://example.com:6443
NoteYou can find your login token and URL to use on the command line from the OpenShift web console. Log in to the OpenShift web console. Click your user name, and click Copy login command. Offer your user name and password again, if asked, and click Display Token to view the command.
Create a new
Secret
resource to contain the Transport Layer Security (TLS) certificate and the corresponding private key:Syntax
oc create secret tls SECRET_NAME -n NAMESPACE --cert CERTIFICATE_FILE_NAME --key PRIVATE_KEY_FILE_NAME
Example
$ oc create secret tls keycloak-tls -n keycloak-system --cert certificate.pem --key key.pem
NoteThe OpenShift’s service serving certificate can automate the generation and management of a TLS certificates for use by Keycloak. Refer to the appendix for more information.
- In OpenShift web console, expand Operators from the navigation menu, and click OperatorHub.
- In the search field, type keycloak, and click the Keycloak Operator tile from the certified Red Hat catalog.
- Click the Install button to show the operator details.
-
On the Install Operator page, select
keycloak-system
from the Installed Namespace drop-down menu, and click the Install button. Wait for the installation to finish. - After the installation finishes, click the View Operator button.
- Click Create instance on the Keycloak tile.
On the Create Keycloak page, select YAML view.
-
On the
name
line, replaceexample-keycloak
with your custom name, for example,keycloak
. The host name can either be explicitly specified within the
hostname
property or automatically generated similar to other routes. On thehostname
line, replaceexample.org
with your custom host name.NoteSee the appendix for the steps necessary to have OpenShift generate the host name for the Keycloak instance.
Under the
spec
section, add your database details:Example
spec: ... db: vendor: postgres host: postgresql-db usernameSecret: name: postgresql-db key: username passwordSecret: name: postgresql-db key: password ...
Also, under the
spec
section, for thehttp
property, specify the name of theSecret
resource containing the TLS certificates.Example
spec: ... http: tlsSecret: keycloak-tls ...
- Click the Create button.
-
On the
- Expand the Networking navigation menu, and click Routes.
- To open the Keycloak Administration Console, click the link to the route associated with the Keycloak instance.
-
The default credentials for the
admin
user are stored in a Secret called keycloak-initial-admin. To locate the password, expand the Workloads navigation menu, and click Secrets. - Select the keycloak-initial-admin Secret.
- Under the Data section, locate the password key, and click the icon.
-
On the Keycloak Administration Console log in page, enter
admin
as the username, and paste the contents of the previous step as the password. Create a new realm called
trusted-artifact-signer
.- On the navigation menu, select the Red Hat Build of Keycloak drop-down menu.
- Select Create Realm.
-
Enter
trusted-artifact-signer
as the Resource name. - Click Create to create the new realm.
Create a new User. The new user can log in to the Keycloak Administration Console, and can also sign containers and commits using RHTAS.
- On the navigation menu, under the Manage section, and select Clients.
- Click the Create Client button
-
In the Client Id field, enter
trusted-artifact-signer
. - Optionally, you can enter a Name and Description into the corresponding fields.
- Click Next.
- Accept the default options for the Capability Config step of the new client creation process.
- Click Next.
-
In the Valid redirect URIs field, enter
*
. - Click Save to create the client.
-
On the navigation menu, under the Configure section, select Realm Settings to locate the Issuer URL for the
trusted-artifact-signer
realm. - Next to Endpoints, click the OpenID Endpoint Configuration link.
-
Copy the URL from the
issuer
property. Under the
.spec.fulcio.config.OIDCIssuers
section of theSecureSign
resource for RHTAS, replace CLIENT_ID withtrusted-artifact-signer
, and paste the URL content to replace RHBK_REALM_ISSUER_URL:Syntax
spec: ... fulcio: config: OIDCIssuers: - ClientID: CLIENT_ID Issuer: 'RHBK_REALM_ISSUER_URL' IssuerURL: 'RHBK_REALM_ISSUER_URL' Type: email ...
Example
spec: ... fulcio: config: OIDCIssuers: - ClientID: trusted-artifact-signer Issuer: 'https://keycloak-ingress-keycloak-system.apps.openshift.example.com/realms/trusted-artifact-signer' IssuerURL: 'https://keycloak-ingress-keycloak-system.apps.openshift.example.com/realms/trusted-artifact-signer' Type: email ...
3.4. Configuring Amazon STS as an OpenID Connect provider for Trusted Artifact Signer
You can use Amazon’s Security Token Service (STS) as your OpenID Connect (OIDC) provider for Red Hat’s Trusted Artifact Signer (RHTAS) service. You can decide to configure Amazon STS during the deployment of RHTAS, or at a later time.
You can define several different OIDC providers in the same configuration.
Prerequisites
- Red Hat OpenShift Container Platform version 4.13 or later.
-
Access to the OpenShift web console with the
cluster-admin
role. -
A workstation with the
oc
,podman
, andaws
binaries installed. - Enable managed Amazon Web Service (AWS) Resources for OpenShift environments.
A created Amazon Identity and Access Management (IAM) user with full permissions. This allows access to run IAM operations.
- Created access keys for this user.
Procedure
Open a terminal on your workstation, and log in to OpenShift:
Syntax
oc login --token=TOKEN --server=SERVER_URL_AND_PORT
Example
$ oc login --token=sha256~ZvFDBvoIYAbVECixS4-WmkN4RfnNd8Neh3y1WuiFPXC --server=https://example.com:6443
NoteYou can find your login token and URL for use on the command line from the OpenShift web console. Log in to the OpenShift web console. Click your user name, and click Copy login command. Offer your user name and password again, if asked, and click Display Token to view the command.
Find the AWS OIDC provider URL:
Example
$ oc get authentication cluster -o jsonpath='{.spec.serviceAccountIssuer}'
Update RHTAS the configuration.
Open for editing the
Securesign
resource:Syntax
oc edit Securesign NAME -n NAMESPACE
Example
$ oc edit Securesign securesign-sample -n trusted-artifact-signer
NoteYou must use the project name created for the RHTAS installation as the namespace.
Under the
OIDCIssuers
section, add a new subsection with your AWS STS client identifier, issuer’s URL, and set theType
value tokubernetes
:Example
... OIDCIssuers: - Issuer: "https://example.s3.us-east-1.aws.com/47bd6cg0vs5nn01mue83fbof94dj4m9c" IssuerURL: "https://example.s3.us-east-1.aws.com/47bd6cg0vs5nn01mue83fbof94dj4m9c" ClientID: "trusted-artifact-signer" Type: kubernetes ...
- Save your changes, and quit the editor. After a few seconds the operator automatically reconfigures the RHTAS software stack.
Configure the AWS command-line tool by entering your access key, secret key, default region, and output format:
Example
$ aws configure
Set the following environment variables:
Example
$ export account_id=$(aws sts get-caller-identity --query "Account" --output text) $ export oidc_provider="$(oc get authentication cluster -o jsonpath='{.spec.serviceAccountIssuer}' | cut -d '/' -f3-)" $ export role_name=rhtas-sts $ export namespace=rhtas-sts $ export service_account=cosign-sts
Create a Trust Policy that gets associated with newly created IAM roles:
Example
$ cat >trust-relationship.json <<EOF { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Federated": "arn:aws:iam::${account_id}:oidc-provider/${oidc_provider}" }, "Action": "sts:AssumeRoleWithWebIdentity", "Condition": { "StringEquals": { "${oidc_provider}:aud": "trusted-artifact-signer" } } } ] } EOF
Create a new IAM role for the RHTAS service by using the trust policy:
Example
$ aws iam create-role --role-name rhtas-sts --assume-role-policy-document file://trust-relationship.json --description "Red Hat Trusted Artifact Signer STS Role"
On the OpenShift cluster with STS enabled, create a new project namespace:
Syntax
oc new-project NAMESPACE
Example
$ oc new-project rhtas-sts
Create a service account for assuming an IAM role, and running a workload within the OpenShift project namespace.
Create the service account manifest:
Example
$ cat >service_account.yaml <<EOF apiVersion: v1 kind: ServiceAccount metadata: name: $service_account namespace: $namespace annotations: eks.amazonaws.com/role-arn: "arn:aws:iam::${account_id}:role/${role_name}" # optional: Defaults to "sts.amazonaws.com" if not set eks.amazonaws.com/audience: "trusted-artifact-signer" # optional: When "true", adds AWS_STS_REGIONAL_ENDPOINTS env var to containers eks.amazonaws.com/sts-regional-endpoints: "true" # optional: Defaults to 86400 for expirationSeconds if not set eks.amazonaws.com/token-expiration: "86400" EOF
Apply the service account manifest to OpenShift:
Example
$ oc apply -f service_account.yaml
Create a new deployment workload for signing container images within a image registry.
Create the deployment manifest:
Example
$ cat >deployment.yaml <<EOF apiVersion: apps/v1 kind: Deployment metadata: name: cosign-sts namespace: ${namespace} spec: selector: matchLabels: app: cosign-sts template: metadata: labels: app: cosign-sts spec: securityContext: runAsNonRoot: true serviceAccountName: cosign-sts containers: - args: - -c - env; cosign initialize --mirror=\$COSIGN_MIRROR --root=\$COSIGN_ROOT; while true; do sleep 86400; done command: - /bin/sh name: cosign image: registry.redhat.io/rhtas-tech-preview/cosign-rhel9@sha256:f4c2cec3fc1e24bbe094b511f6fe2fe3c6fa972da0edacaf6ac5672f06253a3e pullPolicy: IfNotPresent env: - name: AWS_ROLE_SESSION_NAME value: signer-identity-session - name: AWS_REGION value: us-east-1 - name: OPENSHIFT_APPS_SUBDOMAIN value: $(oc get cm -n openshift-config-managed console-public -o go-template="{{ .data.consoleURL }}" | sed 's@https://@@; s/^[^.]*\.//') - name: OIDC_AUTHENTICATION_REALM value: "trusted-artifact-signer" - name: COSIGN_FULCIO_URL value: $(oc get fulcio -o jsonpath='{.items[0].status.url}' -n trusted-artifact-signer) - name: COSIGN_OIDC_ISSUER value: $(oc get authentication cluster -o jsonpath='{.spec.serviceAccountIssuer}') - name: COSIGN_CERTIFICATE_OIDC_ISSUER value: $(oc get authentication cluster -o jsonpath='{.spec.serviceAccountIssuer}') - name: COSIGN_REKOR_URL value: $(oc get rekor -o jsonpath='{.items[0].status.url}' -n trusted-artifact-signer) - name: COSIGN_MIRROR value: $(oc get tuf -o jsonpath='{.items[0].status.url}' -n trusted-artifact-signer) - name: COSIGN_ROOT value: "$(oc get tuf -o jsonpath='{.items[0].status.url}' -n trusted-artifact-signer)/root.json" - name: COSIGN_YES value: "true" securityContext: allowPrivilegeEscalation: false capabilities: drop: - ALL dnsPolicy: ClusterFirst restartPolicy: Always schedulerName: default-scheduler securityContext: runAsNonRoot: true serviceAccount: ${service_account} serviceAccountName: ${service_account} terminationGracePeriodSeconds: 30 EOF
Apply the deployment manifest to OpenShift:
Example
$ oc apply -f deployment.yaml
Create a test container image to sign.
Create an empty container image:
Example
$ echo "FROM scratch" > ./tmp.Dockerfile $ podman build . -f ./tmp.Dockerfile -t ttl.sh/rhtas/test-image:1h
Push the empty container image to the
ttl.sh
ephemeral registry:Example
$ podman push ttl.sh/rhtas/test-image:1h
Remove the temporary Docker file:
Example
$ rm ./tmp.Dockerfile
Validate the configuration by signing and verifying the test container image.
Open a remote shell session within a running pod:
Syntax
oc rsh -n NAMESPACE deployment/cosign-sts env IMAGE=IMAGE_NAME:TAG /bin/sh
Example
$ oc rsh -n rhtas-sts deployment/cosign-sts env IMAGE=ttl.sh/rhtas/test-image:1h /bin/sh
Sign the container image:
Example
$ cosign sign -y --identity-token=$(cat $AWS_WEB_IDENTITY_TOKEN_FILE) ttl.sh/rhtas/test-image:1h
Verify the signed container image:
Example
$ cosign verify --certificate-identity=https://kubernetes.io/namespaces/$(cat /var/run/secrets/kubernetes.io/serviceaccount/namespace)/serviceaccounts/cosign-sts --certificate-oidc-issuer=$COSIGN_CERTIFICATE_OIDC_ISSUER ttl.sh/rhtas/test-image:1h
3.5. Configuring GitHub as an OpenID Connect provider for Trusted Artifact Signer
You can use GitHub OAuth 2.0 when federating it with Red Hat’s Single Sign-On (SSO) service as an OpenID Connect (OIDC) provider for the Red Hat Trusted Artifact Signer (RHTAS) service. This procedure guides you on integrating GitHub OAuth with an existing Red Hat SSO deployment on OpenShift.
You can define several different OIDC providers in the same configuration.
Prerequisites
- Red Hat OpenShift Container Platform version 4.13 or later.
- A running Red Hat SSO instance.
-
A workstation with the
oc
binary installed. Create a GitHub OAuth app, and after registering the application, make note of the client identifier and secret values.
ImportantWhen registering your new GitHub OAuth app, you must specify the Homepage URL, and the Authorization callback URL. Enter placeholder values for both of these fields, for example,
https://localhost:8080
. Later in this procedure you will modify your GitHub OAuth app with the intended values for these fields.
Procedure
Open a terminal on your workstation, and log in to OpenShift:
Syntax
oc login --token=TOKEN --server=SERVER_URL_AND_PORT
Example
$ oc login --token=sha256~ZvFDBvoIYAbVECixS4-WmkN4RfnNd8Neh3y1WuiFPXC --server=https://example.com:6443
NoteYou can find your login token and URL for use on the command line from the OpenShift web console. Log in to the OpenShift web console. Click your user name, and click Copy login command. Offer your user name and password again, if asked, and click Display Token to view the command.
Log in to the Red Hat SSO console.
Find the Red Hat SSO console URL from the command line:
Example
$ oc get routes -n keycloak-system keycloak -o jsonpath='https://{.spec.host}'
- Copy and paste the Red Hat SSO console URL into your web browser.
- Click Administration Console.
Retrieve the
admin
password from the command line:Example
$ oc get secret/credential-keycloak -n keycloak-system -o jsonpath='{ .data.ADMIN_PASSWORD }' | base64 -d
Copy the output from this command.
-
From your web browser, log in as the
admin
user, and paste the password in the corresponding field. Click the Sign In button.
- Select your realm from the dropdown on the navigation menu.
Add the GitHub identity provider.
- From the navigational menu, click Identity Providers.
- From the Add provider… drop-down menu, select GitHub.
- Add your GitHub OAuth client identifier to the Client ID field.
- Add your GitHub OAuth client secret to the Client Secret field.
- Turn on the Trust Email option.
- Click the Save button.
Add the identity provider mapper to the newly created identity provider.
- Click the Mapper tab.
- Click the Create button.
- Give a Name to the new mapper.
- Change the Mapper Type to Hardcoded Attribute.
-
Set the User Attribute field to
emailVerified
. -
Set the User Attribute Value field to
true
. - Click the Save button.
-
From the GitHub Identity Provider Settings page, copy the Redirect URI value and paste it to your GitHub OAuth app Authorization Callback URL field. Also, paste this same value into the Homepage URL field, but remove the
broker/github/endpoint
part of the URL string. - Click Update Application. You can now sign commits, and containers by using GitHub as your OIDC provider.
- When signing artifacts, a web browser opens and prompts you to sign in to your Red Hat SSO account. Click the GitHub button to sign in with your credentials.
- Click the Authorize button to enable GitHub user details to be accessible by Red Hat SSO.
Chapter 4. Configure an alternative database for Trusted Artifact Signer
You can replace the Red Hat Trusted Artifact Signer (RHTAS) default database for Trillian with an externally managed MariaDB database instance. The database instance can be a cloud-hosted database provider, such as Amazon’s Relational Database Service (RDS), or your own database deployment in OpenShift.
4.1. Prerequisites
- Red Hat OpenShift Container Platform version 4.13, 4.14, or 4.15.
4.2. Configuring Amazon RDS for Trusted Artifact Signer
With this procedure, you can replace Red Hat’s Trusted Artifact Signer (RHTAS) default database for Trillian with a MariaDB instance managed by Amazon’s Relational Database Service (RDS).
Red Hat recommends using a highly available MariaDB database for production workloads.
Prerequisites
- An Amazon Web Service (AWS) account with access to the Amazon RDS console.
-
Access to the OpenShift web console with the
cluster-admin
role. -
A workstation with the
oc
,curl
, and themysql
binaries installed. - Command-line access with privileges to create a database and populate the MariaDB instance.
Procedure
Open the Amazon RDS console, and create a new MariaDB instance.
- Wait for the MariaDB instance to be deployed, and is available.
From your workstation, log in to the new database by providing the regional endpoint, the port, and the user credentials:
Syntax
mysql -h REGIONAL_ENDPOINT -P 3306 -u USER_NAME -p
Example
$ mysql -h exampledb.1234.us-east-1.rds.amazonaws.com -P 3306 -u admin -p
Create a new database named trillian:
Example
create database trillian;
Switch to the newly created database:
Example
use trillian;
Create a new database user named
trillian
, and set a PASSWORD for the newly created user:Syntax
CREATE USER trillian@'%' IDENTIFIED BY 'PASSWORD'; GRANT ALL PRIVILEGES ON trillian.* TO 'trillian'@'%'; FLUSH PRIVILEGES;
Disconnect from the database:
Example
EXIT
Download the database configuration file:
Example
$ curl -o dbconfig.sql https://raw.githubusercontent.com/securesign/trillian/main/storage/mysql/schema/storage.sql
Apply the database configuration to the new database:
Syntax
mysql -h FQDN_or_SERVICE_ADDR -P 3306 -u USER_NAME -p PASSWORD -D DB_NAME < PATH_TO_CONFIG_FILE
Example
$ mysql -h rhtasdb.example.com -P 3306 -u trillian -p mypassword123 -D trillian < dbconfig.sql
Open a terminal on your workstation, and log in to OpenShift:
Syntax
oc login --token=TOKEN --server=SERVER_URL_AND_PORT
Example
$ oc login --token=sha256~ZvFDBvoIYAbVECixS4-WmkN4RfnNd8Neh3y1WuiFPXC --server=https://example.com:6443
NoteYou can find your login token and URL for use on the command line from the OpenShift web console. Log in to the OpenShift web console. Click your user name, and click Copy login command. Offer your user name and password again, if asked, and click Display Token to view the command.
Create a new Secret containing the credentials for the Trillian database within the MariaDB instance which was created previously:
Syntax
oc create secret generic OBJECT_NAME \ --from-literal=mysql-database=trillian \ --from-literal=mysql-host=FQDN_or_SERVICE_ADDR \ --from-literal=mysql-password=PASSWORD \ --from-literal=mysql-port=3306 \ --from-literal=mysql-root-password=PASSWORD \ --from-literal=mysql-user=USER_NAME
Example
$ oc create secret generic trillian-mysql \ --from-literal=mysql-database=trillian \ --from-literal=mysql-host=mariadb.trusted-artifact-signer.svc.cluster.local \ --from-literal=mysql-password=mypassword123 \ --from-literal=mysql-port=3306 \ --from-literal=mysql-root-password=myrootpassword123 \ --from-literal=mysql-user=trillian
You can use an OpenShift internal service name for the MariaDB instance.
- You can now deploy the Trusted Artifact Signer service to use this database. If you were following the Trusted Artifact Signer installation procedure, then you can proceed to the next step.
Additional resources
4.3. Configuring a database in OpenShift for Trusted Artifact Signer
With this procedure, you can replace Red Hat’s Trusted Artifact Signer (RHTAS) default database for Trillian with a MariaDB instance managed by Amazon’s Relational Database Service (RDS).
Red Hat recommends using a highly available MariaDB database for production workloads.
Prerequisites
- Permissions to create an OpenShift project, and deploy a database instance from the OpenShift samples catalog.
-
Access to the OpenShift web console with the
cluster-admin
role. -
A workstation with the
oc
,curl
, and themysql
binaries installed. - Command-line access with privileges to create a database and populate the MariaDB instance.
Procedure
- Log in to the OpenShift web console where you are deploying the RHTAS service:
- Change to the Developer perspective.
Select the
trusted-artifact-signer
project, if the project already exists, else create a new project for the database:- To create a new project, click the drop-down project menu, and click the Create Project button.
-
Name the new project
trusted-artifact-signer
, and click the Create button.
- On the Developer Catalog card, click Database.
Select MariaDB, and click the Instantiate Template button.
ImportantDo not select MariaDB (Ephemeral).
On the Instantiate Template page, configure the following fields:
-
In the MariaDB Database Name field, enter
trillian
. -
In the Volume Capacity field, enter
5Gi
. - Click the Create button.
-
In the MariaDB Database Name field, enter
Begin a remote shell session:
- On the Topology page, selecting the MariaDB pod brings up a side panel, click the Resources tab.
- Under the Pods section, click on the MariaDB pod name.
- Click the Terminal tab to start a remote shell session to the MariaDB pod.
In the remote shell session, verify that you can connect to the Trillian database:
Example
$ mysql -u $MYSQL_USER -p$MYSQL_PASSWORD -D$MYSQL_DATABASE
NoteCredentials are stored in a secret object with the service name (
mariadb
), and contains the name of the database, and user name, along with the database root password. Make a note of these credentials as they will be used later on when creating the database secret object.Disconnect from the database:
Example
EXIT
Download the database configuration file:
Example
$ curl -o dbconfig.sql https://raw.githubusercontent.com/securesign/trillian/main/storage/mysql/schema/storage.sql
Apply the database configuration to the new database:
Syntax
mysql -h FQDN_or_SERVICE_ADDR -P 3306 -u USER_NAME -p PASSWORD -D DB_NAME < PATH_TO_CONFIG_FILE
Example
$ mysql -h rhtasdb.example.com -P 3306 -u trillian -p mypassword123 -D trillian < dbconfig.sql
Open a terminal on your workstation, and log in to OpenShift:
Syntax
oc login --token=TOKEN --server=SERVER_URL_AND_PORT
Example
$ oc login --token=sha256~ZvFDBvoIYAbVECixS4-WmkN4RfnNd8Neh3y1WuiFPXC --server=https://example.com:6443
NoteYou can find your login token and URL for use on the command line from the OpenShift web console. Log in to the OpenShift web console. Click your user name, and click Copy login command. Offer your user name and password again, if asked, and click Display Token to view the command.
Create a new Secret containing the credentials for the Trillian database within the MariaDB instance which was created previously:
Syntax
oc create secret generic OBJECT_NAME \ --from-literal=mysql-database=trillian \ --from-literal=mysql-host=FQDN_or_SERVICE_ADDR \ --from-literal=mysql-password=PASSWORD \ --from-literal=mysql-port=3306 \ --from-literal=mysql-root-password=PASSWORD \ --from-literal=mysql-user=USER_NAME
Example
$ oc create secret generic trillian-mysql \ --from-literal=mysql-database=trillian \ --from-literal=mysql-host=mariadb.trusted-artifact-signer.svc.cluster.local \ --from-literal=mysql-password=mypassword123 \ --from-literal=mysql-port=3306 \ --from-literal=mysql-root-password=myrootpassword123 \ --from-literal=mysql-user=trillian
You can use an OpenShift internal service name for the MariaDB instance.
- You can now deploy the Trusted Artifact Signer service to use this database. If you were following the Trusted Artifact Signer installation procedure, then you can proceed to the next step.
Additional resources
Appendix A. Configuring OpenShift service serving certificates to generate TLS certificates for Keycloak
OpenShift’s service serving certificate can automate the generation and management of Transport Layer Security (TLS) certificates for use by Keycloak. Infrastructure components, such as the Ingress Controller, within an OpenShift cluster will trust these TLS certificates.
Prerequisites
- Red Hat OpenShift Container Platform version 4.13 or later.
- Installation of the RHBK operator.
-
Access to the OpenShift web console with the
cluster-admin
role.
Procedure
- In OpenShift web console, from the Administrator perspective, expand Home from the navigation menu, and click Projects.
-
Search for
keycloak
, and select thekeycloak-system
namespace. Create a new service.
- Click the + icon.
In the Import YAML text box, copy the example, and paste it into the text box.
Example
apiVersion: v1 kind: Service metadata: annotations: service.beta.openshift.io/serving-cert-secret-name: keycloak-tls labels: app: keycloak app.kubernetes.io/instance: keycloak name: keycloak-service-trusted namespace: keycloak-system spec: internalTrafficPolicy: Cluster ipFamilies: - IPv4 ipFamilyPolicy: SingleStack ports: - name: https port: 8443 selector: app: keycloak app.kubernetes.io/instance: keycloak
- Click the Create button.
- Expand Operators from the navigation menu, click Installed Operators, and click Keycloak Operator.
In the YAML view of the
Keycloak
resource, under thespec
section, add theingress
property:Example
spec: ... ingress: annotations: route.openshift.io/destination-ca-certificate-secret: keycloak-tls route.openshift.io/termination: reencrypt ...
By default, the Keycloak operator creates Ingress resources instead of routes. OpenShift automatically creates a route based on the Ingress definition.
Specify the name of the secret containing the TLS certificate, under the
spec
section:Example
spec: ... http: tlsSecret: keycloak-tls ...
Once Keycloak starts, OpenShift’s service serving certificate starts generating TLS certificates for Keycloak.
Additional resources
Appendix B. Generating Keycloak host names automatically
OpenShift routes has support for automatically generating host names by using a set pattern. This feature can integrate with Red Hat’s build of Keycloak (RHBK) operator running on OpenShift.
Prerequisites
- Red Hat OpenShift Container Platform version 4.13 or later.
- Installation of the RHBK operator.
-
Access to the OpenShift web console with the
cluster-admin
role. -
A workstation with the
oc
binary installed.
Procedure
Enable the automatically generated route hostname feature.
Under the
.spec
section, remove the entirehostname
section, and replace it with theingress
section andclassName
property within theKeycloak
resource:Example
spec: ... hostname: hostname: example.com ...
Example
spec: ... ingress: className: openshift-default ...
NoteTo view all of the available Ingress classes, run the following command:
$ oc get ingressclass
- Click the Save button.
Verify the automatically generated
hostname
by clicking the Reload button to view the latest configuration:Example
spec: ... hostname: hostname: example-keycloak-ingress-keycloak-system.apps.rhtas.example.com ...
Appendix C. Service and StatefulSet YAML configuration for Red Hat build of Keycloak
The Service and StatefulSet YAML resource configuration used when configuring Red Hat’s build of Keycloak (RHBK) for Red Hat’s Trusted Artifact Signer (RHTAS) service.
--- apiVersion: v1 kind: Service metadata: name: postgresql-db namespace: keycloak-system spec: internalTrafficPolicy: Cluster ipFamilies: - IPv4 ipFamilyPolicy: SingleStack ports: - port: 5432 selector: app: postgresql-db --- apiVersion: apps/v1 kind: StatefulSet metadata: name: postgresql-db namespace: keycloak-system spec: persistentVolumeClaimRetentionPolicy: whenDeleted: Retain whenScaled: Retain podManagementPolicy: OrderedReady replicas: 1 revisionHistoryLimit: 10 selector: matchLabels: app: postgresql-db serviceName: postgresql-db template: metadata: labels: app: postgresql-db spec: containers: - env: - name: POSTGRESQL_USER valueFrom: secretKeyRef: key: username name: postgresql-db - name: POSTGRESQL_PASSWORD valueFrom: secretKeyRef: key: password name: postgresql-db - name: POSTGRESQL_DATABASE valueFrom: secretKeyRef: key: database name: postgresql-db image: registry.redhat.io/rhel9/postgresql-15:latest imagePullPolicy: IfNotPresent livenessProbe: exec: command: - /usr/libexec/check-container - --live failureThreshold: 3 initialDelaySeconds: 120 periodSeconds: 10 successThreshold: 1 timeoutSeconds: 10 name: postgresql-db readinessProbe: exec: command: - /usr/libexec/check-container failureThreshold: 3 initialDelaySeconds: 5 periodSeconds: 10 successThreshold: 1 timeoutSeconds: 1 securityContext: allowPrivilegeEscalation: false capabilities: drop: - ALL terminationMessagePath: /dev/termination-log terminationMessagePolicy: File volumeMounts: - mountPath: /var/lib/pgsql/data name: data dnsPolicy: ClusterFirst restartPolicy: Always schedulerName: default-scheduler securityContext: runAsNonRoot: true seccompProfile: type: RuntimeDefault terminationGracePeriodSeconds: 30 updateStrategy: rollingUpdate: partition: 0 type: RollingUpdate volumeClaimTemplates: - apiVersion: v1 kind: PersistentVolumeClaim metadata: name: data spec: accessModes: - ReadWriteOnce resources: requests: storage: 1Gi volumeMode: Filesystem
Appendix D. Trusted Artifact Signer components and version numbers
The following tables list Red Hat’s Trusted Artifact Signer (RHTAS) software components and their corresponding version numbers for the 1.1 release.
Component | Version |
---|---|
| 2.4.0 |
| 0.10.2 |
| 1.3.6 |
| 0.2.1 |
| 0.17.1 |
| 0.17.1 |
Component | Version |
---|---|
logserver | 1.6.0 |
logsigner | 1.6.0 |
database | 1.6.0 |
redis | 1.6.0 |
Component | Version |
---|---|
rekor-server | 1.3.6 |
backfill-redis | 1.3.6 |
rekor-search-ui | 1.3.6 |
Component | Version |
---|---|
fulcio-erver | 1.4.5 |
Component | Version |
---|---|
certificate-transparency-go | 1.2.1 |
Component | Version |
---|---|
timestamp-authority | 1.1.2 |
Component | Version |
---|---|
createctconfig | 0.7.3 |
ctlog-managectroots | 0.7.3 |
tuf-server | 0.7.3 |
trillian-createtree | 0.7.3 |
trillian-createdb | 0.7.3 |
fulcio-createcerts | 0.7.3 |
Additional resources
- For more information about Trillian, see the project page on GitHub.
- For more information about Sigstore’s Rekor, see the project page on GitHub.
- For more information about Sigstore’s Fulcio, see the project page on GitHub.
- For more information about Sigstore’s Timestamp Authority, see the project page on GitHub.
- For more information about TUF, see their home page hosted by the Linux Foundation.