Ecosyste.ms: Awesome
An open API service indexing awesome lists of open source software.
https://github.com/intel/trusted-certificate-issuer
Trusted Certificate Service (TCS) is a K8s service to protect signing keys using Intel's SGX technology. K8s CSR and cert-manager CR APIs are both supported. TCS also contains integration samples for Istio service mesh and Key Management Reference Application (KMRA).
https://github.com/intel/trusted-certificate-issuer
certificate istio kubernetes private-key-infrastructure sgx
Last synced: about 1 month ago
JSON representation
Trusted Certificate Service (TCS) is a K8s service to protect signing keys using Intel's SGX technology. K8s CSR and cert-manager CR APIs are both supported. TCS also contains integration samples for Istio service mesh and Key Management Reference Application (KMRA).
- Host: GitHub
- URL: https://github.com/intel/trusted-certificate-issuer
- Owner: intel
- License: apache-2.0
- Created: 2022-01-21T22:37:25.000Z (almost 3 years ago)
- Default Branch: main
- Last Pushed: 2024-04-30T06:10:12.000Z (8 months ago)
- Last Synced: 2024-08-09T00:28:11.669Z (4 months ago)
- Topics: certificate, istio, kubernetes, private-key-infrastructure, sgx
- Language: Go
- Homepage:
- Size: 875 KB
- Stars: 29
- Watchers: 8
- Forks: 15
- Open Issues: 11
-
Metadata Files:
- Readme: README.md
- License: LICENSE
- Security: SECURITY.md
Awesome Lists containing this project
- Awesome-SGX-Open-Source - https://github.com/intel/trusted-certificate-issuer
README
# Trusted Certificate Service for Kubernetes Platform
- [Overview](#overview)
- [Getting started](#getting-started)
- [Prerequisites](#prerequisites)
- [Installing with Helm](#installing-with-helm)
- [Installing with source code](#installing-with-source-code)
- [Create an Issuer](#create-an-issuer)
- [Create certificates](#create-certificates)
- [Deployment in Azure](#deployment-in-azure)
- [Sample use cases](#sample-use-cases)
- [Limitations](#limitations)
## Overview
Trusted Certificate Service (TCS) is a Kubernetes certificate signing solution
that uses the security capabilities provided by Intel® Software Guard Extensions
(Intel® SGX). The signing key is stored and used inside the Intel SGX enclave(s)
and is never stored in clear anywhere in the system. TCS is implemented as a
[cert-manager external issuer](https://cert-manager.io/docs/configuration/external/)
by providing support for both cert-manager and kubernetes certificate signing APIs.
## Getting started
All the examples in this page are using self-signed CA certificates. If you are
looking for more advanced use cases (e.g., Istio integration) please check the
[sample use cases](#sample-use-cases).
### Prerequisites
Prerequisites for building and running Trusted Certificate Service:
- Kubernetes cluster with one or more nodes with Intel® [SGX](https://software.intel.com/content/www/us/en/develop/topics/software-guard-extensions.html) supported hardware
- [Intel® SGX device plugin](https://github.com/intel/intel-device-plugins-for-kubernetes/blob/main/cmd/sgx_plugin/README.md) for Kubernetes
- [Intel® SGX AESM daemon](https://github.com/intel/linux-sgx#install-the-intelr-sgx-psw)
- [cert-manager](https://cert-manager.io/next-docs/installation/). The `cmctl` is also used later in the examples so you may want to install it also.
- Linux kernel version 5.11 or later on the host (in tree Intel SGX driver)
- git, or similar tool, to obtain the source code
- Docker, or similar tool, to build container images
- Container registry ([local](https://docs.docker.com/registry/deploying/) or remote)
### Installing with Helm
If you want to use Helm to install TCS see the document [here](https://github.com/intel/helm-charts/tree/main/charts/trusted-certificate-issuer).
### Installing with source code
This section covers how to obtain the source code, build and install it.
1. Getting the source code
```sh
git clone https://github.com/intel/trusted-certificate-issuer.git
```
2. Build and push the container image
Choose a container registry to push the generated image using `REGISTRY` make variable.
The registry should be reachable from the Kubernetes cluster.
> **NOTE**: By default, the enclave signing is done using a private key
auto-generated by the TCS issuer. In case, if you want to integrate your
own signing tool, modify/replace the `enclave-config/sign-enclave.sh`
script accordingly before building the docker image.
Refer to [Intel(R) SGX SDK developer reference](https://download.01.org/intel-sgx/linux-2.1.3/docs/Intel_SGX_Developer_Reference_Linux_2.1.3_Open_Source.pdf) for more details about enclave signing.
```sh
$ cd trusted-certificate-issuer
$ export REGISTRY="localhost:5000" # docker registry to push the container image
$ make docker-build
$ make docker-push
```
> **NOTE**: If you operate behind a corporate proxy, proxy settings can be passed in like \
```make docker-build BUILD_ARGS="--build-arg http_proxy=someproxy --build-arg https_proxy=someproxy --build-arg no_proxy=some_list"```
3. Deploy custom resource definitions (CRDs)
```sh
# set the KUBECONFIG based on your configuration
export KUBECONFIG="$HOME/.kube/config"
make install # Install CRDs
```
4. Make the deployment
```sh
make deploy
```
By default, `tcs-issuer` namespace is used for the deployment.
```sh
# Ensure that the pod is running state
$ kubectl get po -n tcs-issuer
NAME READY STATUS RESTARTS AGE
tcs-controller-5dd5c46b44-4nz9f 1/1 Running 0 30m
```
### Create an Issuer
Once the deployment is up and running, you are ready to provision TCS
issuer(s) using either a namespace-scoped `TCSIssuer` or a
cluster-scoped `TCSClusterIssuer` resource.
The example below creates a TCS issuer named `my-ca` for `sandbox` namespace:
```sh
kubectl create ns sandbox
cat <
Figure 1: Trusted Certificate Install
1. The `TCSIssuer` is created.
1. This automatically creates the `my-ca-cert` secret. The `tls.key` field is blank
because the private key is actually created and stored within a Intel SGX enclave.
Below is a demo of the install process.
### Create certificates
Creating and signing certificates can be done by using cert-manager `Certificate`
or Kubernetes `CertificateSigningRequest` APIs.
#### Using cert-manager Certificate
This example shows how to request X509 certificate signed by the Trusted Certificate Service
using cert-manger `Certificate` API. Create a cert-manager `Certificate` object and
set the `spec.issuerRef` to `TCSIssuer`(or `TCSClusterIssuer`).
```sh
cat <
Figure 2: Trusted Certificate Issuer with cert-manager
1. The `TCSIssuer` is created.
1. This automatically creates the `my-ca-cert` secret.
1. A user creates a `Certificate` object specifying to use the TCS Issuer.
1. cert-manager automatically creates a `CertificateRequests` object.
1. A user approves the `CertificateRequests` object.
1. The TCS Controller then takes the request and signs the certificate inside
the Intel SGX enclave using the private key stored within that enclave.
1. The signed certificate is then copied into the `demo-cert-tls` secret that was
specified in the original `Certificate` object.
1. Finally, that same signed certificate is copied back into the `CertificateRequests`
object.
Below is a demo of this working with cert-manager.
#### Using Kubernetes CSR
This example shows how to request an X509 certificate signed by the Trusted Certificate Service
using Kubernetes CSR.
First, generate a PEM encoded private key (`privkey.pem`) and certificate signing request (`csr.pem`)
using `openssl` tool:
```sh
$ openssl req -new -nodes -newkey rsa:3072 -keyout privkey.pem -out ./csr.pem -subj "/O=Foo Company/CN=foo.bar.com"
```
Create a Kubernetes `CertificateSigningRequest` using the csr (`csr.pem`) generated above.
The `spec.signerName` field must refer to the TCS issuer we configured earlier
in the form of `./.`.
In this example the signer name is `tcsissuer.tcs.intel.com/sandbox.my-ca`.
**Note:** the issuer namespace in the case of `tcsclusterissuer` is the namespace
of the Trusted Certificate Service.
```sh
cat <
Annotations: kubectl.kubernetes.io/last-applied-configuration={"apiVersion":"certificates.k8s.io/v1","kind":"CertificateSigningRequest","metadata":{"annotations":{},"name":"test-csr"},"spec":{"groups":["system:authenticated"],"request":"LS0tLS1CRUdJTiBDRVJUSUZJQ0FURSBSRVFVRVNULS0tLS0KTUlJRGNUQ0NBZGtDQVFBd0xERVVNQklHQTFVRUNnd0xSbTl2SUVOdmJXRndibmt4RkRBU0JnTlZCQU1NQzJadgpieTVpWVhJdVkyOXRNSUlCb2pBTkJna3Foa2lHOXcwQkFRRUZBQU9DQVk4QU1JSUJpZ0tDQVlFQTZhNzkvTmZLCmdrYzQ5dXd6TVFUajBwZzhuZjZ3VU5tcmNVaG5IUDNhUitDYjZKcE0wOVF3RHBmblI2VU13ejZFVy9RSis3WVQKMndLUFJTRVZqZ3owT29NdXh0c0tScGN2VCtWaDZkb3JjSkU0ZTdjQ2FWK1ZKN0pQRGtwYzdFNSt6VCtncVlRKwptMWhjS0FmTEk0VEpZNzJZR2MzTWt5QkVqRzNsKzl3emxHNVlpZEduYVFjNDhMNUJQSXFxOEdKelpWSTkvQWxLClVDVjcwM2pGQnpKdTBEbFpTQWd2WEo1RUhNbWVhaFBQYTFOV2dkM29mQ2FUcTlnM0xaSTBDejdWbndOK0l1bzEKNGpRcE1zNzVQTFZVUTQ2SEZ0YUxJTWZPNDlkZk94SUwwNlkwZG1XNUc0R05zNUR4SkhtYm11QlQ1NGMrUm5MUQoyVldJL2VRS2xQQW5Sdk00SmpEM3hEcENvOGViSE9nS2RsRU9MTkFPTEk0L2VMUG1GcXlTUGxuY2RTZlFqc2UvCkJQOEpuQk9Xa0xpSUZ4bzBwT1lrTUFDaHhWdDJkdURLcldRZm1JSkhUUSs0Q05OZjhlanZOZkZCY0pmNllldHUKRnlkNnA4WmwrYkV2TldYbDBKeGNQNWlFVGFYWkZqblJqMWxzZWVSbWo3OGFyRDZCUkhTTFlsM0pBZ01CQUFHZwpBREFOQmdrcWhraUc5dzBCQVFzRkFBT0NBWUVBMXYrOURlUE5XOER6Z2twVzBhU1czdW1xR05xc05zaWNhQjc1Cjc3UGsyRnNBMTMya2JWTXBBY2NCRzc1WGh4T0VkNFNYdTJ0eVI1MGxOMUpaNnJldzY5b1dUYWZTTTVXNm00RFAKcE1tVjRJbTJiajlUTUhYeHdXVjdXVk5JL2dQK1BFRDVROVJMNy82Sjh2VnV5aFhZaTAyc2NkampKaStIT0M4Ywo1TFpLem5TQUhtcmZEVGlveG5ydUNqY1ZEZlFlSGlJMkw1SW94aXAwUmt5L0Y1UkhwTjRyMHFQS25Na2F3enRYClV3alB6Nk9uWGVPK1EvVGZyRm5ka2V3OCtsSFc2akxneXNUNlU3SjdmdjVuL1lSUXdYSHJadi9LNFVneW9zU3oKZy9PSkZoOVpyWjl6WFBhT01sN1pLYnlUUXE2NGtMSmFEQys0eWIycXlUT1hMUm1xK0Y1MWc2a0tJdDdMWXdtMQpjR0N3WTc2WmFHMm9hVkQxRVNQSWtpc0I4U01ncVNEajlhQjFxRDJ0Y1E4RGxoV1o3dEdDd3M5VC9RUDlvQnpsCjc5S0g3Qnc1QnVSVFlRT0srMTdJSWUrNUx0YVFzS1dpczBsaGtvQ1R3TjdUS2FnQ1dLWWk0RE16em1wVlNvbTEKaVphb21nUDJIKy8yQ3RoOUNJN1dwVWR5WklkQgotLS0tLUVORCBDRVJUSUZJQ0FURSBSRVFVRVNULS0tLS0K","signerName":"tcsissuer.tcs.intel.com/sandbox.my-ca","usages":["client auth"]}}
CreationTimestamp: Mon, 24 Jan 2022 16:11:10 +0200
Requesting User: kubernetes-admin
Signer: tcsissuer.tcs.intel.com/sandbox.my-ca
Status: Approved,Issued
Subject:
Common Name: foo.bar.com
Serial Number:
Organization: Foo Company
```
Figure 3: Trusted Certificate Issuer with Kubernetes CSR
1. The `TCSIssuer` is created.
1. This automatically creates the `my-ca-cert` secret.
1. A user creates a certificate signing request using openssl and saving the
private key. Using that `csr.pem` file, a `CertificateSigningRequest` object is
created in Kubernetes.
1. A user approves the `CertificateSigningRequest` object.
1. The TCS Controller then takes the request and signs the certificate inside
the Intel SGX enclave using the private key stored within that enclave.
1. The signed certificate is then copied back into the original `CertificateSigningRequest`
object into the `certificate` field.
Below is a demo of this working with Kubernetes CSR.
## Deployment in Azure
You can deploy TCS also in Azure by following the instructions [here](./docs/azure.md).
## Sample use cases
Refer to more example use cases related to Istio service mesh and Trusted Certificate Service
- [Istio custom CA integration using Kubernetes CSR](./docs/istio-custom-ca-with-csr.md)
- [Istio integration with cert-manager and istio-csr](./docs/istio-csr-external-ca-setup.md)
- [Remote attestation and key management (manual)](./docs/integrate-key-server.md)
## Limitations
- This version of the software is pre-production release and is meant for evaluation and trial purposes only.
- The certificate authority (CA) private key transport method (via QuoteAttestation custom resource) does not guarantee any authenticity, only confidentiality, and therefore cannot protect from attacks like key substitution or key replay.