Install the JFrog Registry Operator in EKS

Ensure that you configure the EKS cluster with the IAM role and attach the AWS policy before you install the operator. 1.

Ensure that you configure the EKS cluster with the IAM role and attach the AWS policy before you install the operator.

Run the following command to export the namespace and service account name for use in the procedure.

export NAMESPACE=<namespace where the passwordless access is to be configured>
export SERVICE_ACCOUNT_NAME=<service account where the passwordless access is to be configured>

Set SERVICE_ACCOUNT_NAME and ANNOTATIONS with the ARN details of the IAM role. Note that this is optional from release version 2.1.x.

📘
Note
Support for external service accounts has been added, allowing you to use an external service account. The multi-user approach sets up a pod that can take on the roles of different service accounts.

export SERVICE_ACCOUNT_NAME=<service account where the passwordless access is to be configured>
export ANNOTATIONS="eks.amazonaws.com/role-arn: arn:aws:iam::<account_number>:role/<role_name>"

You can pass this to use the default resources.

Add the JFrog Helm Charts repository.

helm repo add jfrog https://charts.jfrog.io

If you have already added the JFrog Helm Charts repository, run the following command to update the repository.

helm repo update

Install Custom Resource Definition (CRD) for the operator, based on the required scope.

📘
The default is cluster scope.

For Cluster scope:

kubectl apply -f https://raw.githubusercontent.com/jfrog/jfrog-registry-operator/refs/heads/v3.0.0/config/crd/bases/apps.jfrog.com_secretrotators_cluster_scope.yaml

For Namespaced scope:

kubectl apply -f https://raw.githubusercontent.com/jfrog/jfrog-registry-operator/refs/heads/v3.0.0/config/crd/bases/apps.jfrog.com_secretrotators_namespaced_scope.yaml

Run the following command to install the JFrog Registry operator.

helm upgrade --install secretrotator jfrog/jfrog-registry-operator --set "serviceAccount.name=${SERVICE_ACCOUNT_NAME}" --set "serviceAccount.annotations=${ANNOTATIONS}" --create-namespace -n ${NAMESPACE}

The operator runs with a cluster context.

If you skipped Step 2, you can use the command below to install the operator, which is applicable in a multi-user scenario.

The multi-user approach allows a pod to assume the roles of different service accounts. It reads specific service accounts and uses annotations to generate temporary credentials for the ARN, which are accessible to the operator. This setup enables customers to create new users and use the JFrog operator for automatic JFrog token exchange and rotation per namespace, eliminating the need to manage secrets in the target namespace.

In a multi-user scenario, create all service accounts using the role ARN as an annotation via the Helm chart. This will update the ClusterRole to grant the necessary permissions to each specific service account.

Create a custom-values.yaml file with service account details.
```
exchangedServiceAccounts: 
 - name: "sa1" 
   namespace: "<NAMESPACE>"    
   annotations:     
      eks.amazonaws.com/role-arn: <role arn>
 - name: "sa2" 
   namespace: "<NAMESPACE>"    
   annotations:     
      eks.amazonaws.com/role-arn: <role2 arn>
```

✅
Tip
Namespaces are not created by the Helm chart, so you need to create them manually if you are using a different namespace for the service account. For a centralized installation, use the operator's namespace.

Run the following command to install the JFrog Registry operator.

helm upgrade --install secretrotator jfrog/jfrog-registry-operator --create-namespace -f custom-values.yaml -n ${NAMESPACE}

📘
Note
You can then utilize the service account name and namespace in your custom resources. This allows you to install multiple custom resources with different service account details.

Run the following command to check the status of the operator.
```
kubectl get po -n ${NAMESPACE}
```
Update the secretrotator.yaml file to include the JFrog Platform URL (artifactoryUrl) and the namespace namespaceSelector.matchLabels.kubernetes.io/metadata.name).

The service account includes the name and namespace containing the user's service account details and is created by the operator's Helm chart. If an external service account not created by the Helm chart is used, then you must manually patch the ClusterRole to grant the necessary permissions. This includes resources serviceaccounts and serviceaccounts/token with resource names of the new service accounts.

The following is an example that you can use in the CR object.

serviceAccount:
  name: "" 
  namespace: ""

✅
Tip
The generic type secret contains keys token and password, while the docker type secret contains a Kubernetes image pull secret.

You can use the generatedSecrets feature to define the specifications for one or more secrets that should be automatically generated. It also supports a wide range of secret types.

secretName: The name of the secret to be generated.
secretType: The type of secret to generate (for example, docker, generic, and so on).
scope: . This is optional. Specifies the context in which the generated secrets should be applied.

You can also update the time taken to refresh the token (refreshTime) and apply any secret metadata (secretMetadata).

apiVersion: apps.jfrog.com/v1alpha1
kind: SecretRotator
metadata:
labels:
 app.kubernetes.io/name: secretrotators.apps.jfrog.com
 app.kubernetes.io/instance: secretrotator
 app.kubernetes.io/created-by: artifactory-secrets-rotator
name: secretrotator
spec:
namespaceSelector:
 matchLabels:
   kubernetes.io/metadata.name: <NAMESPACE>
generatedSecrets:
 - secretName: token-imagepull-secret
   secretType: docker
   scope:
 - secretName: token-generic-secret
   secretType: generic
   scope:
artifactoryUrl: "<JFROG_PLATFORM_URL>"
serviceAccount:
 name: "" 
 namespace: ""
refreshTime: 30m
secretMetadata:
 annotations:
   annotationKey: annotationValue
 labels:
   labelName: labelValue

📘
Note
The use of spec.secretName is currently supported but will be deprecated in the near future.

By default, rotation of registry tokens is done every 75% of token expiration time, which is set to the max AWS role session timeout. If you provide a value for refreshTime , ensure that it is not longer than the max aws role session expiration.

namespaceSelector is used by the operator to select the namespaces into which the registry tokens are created. You can update the namespaceSelector value to switch to a different namespace.

secretName contains the created Docker registry secret and the value is rotated by the operator.

If the Docker registry is on an Edge server, the user with the AWS role tag must exist on the Edge server and must have the tagging either manually or through access federation.

Run the following command to update the operator with the JFrog Platform URL.

kubectl apply -f secretrotator.yaml -n ${NAMESPACE}

Upgrade JFrog Registry Operator

Update the Helm repository.
```
helm repo update
```

Update Custom Resource Definition (CRD) for the operator, based on the required scope.

📘
The default is cluster scope.

Once the CRD is updated, proceed with either the Helm approach or the Terraform approach.

For Cluster scope:

kubectl apply -f https://raw.githubusercontent.com/jfrog/jfrog-registry-operator/refs/heads/v3.0.0/config/crd/bases/apps.jfrog.com_secretrotators_cluster_scope.yaml

For Namespaced scope:

kubectl apply -f https://raw.githubusercontent.com/jfrog/jfrog-registry-operator/refs/heads/v3.0.0/config/crd/bases/apps.jfrog.com_secretrotators_namespaced_scope.yaml

To uninstall the secret rotator, run the following command:

helm upgrade --install secretrotator jfrog/jfrog-registry-operator --set "serviceAccount.name=${SERVICE_ACCOUNT_NAME}" --set serviceAccount.annotations=${ANNOTATIONS}  --namespace  ${NAMESPACE} --create-namespace

Updated 2 days ago