jfrog-registry-operator-3.0.0

Version 3.0.0 🚀

Important Changes

CRD Installation Behavior

• Starting from version 3.0.0, the JFrog Registry Operator will no longer install CRDs by default during Helm installation.
• CRDs must now be installed separately.

# Install or Upgrade CRD
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

Custom Resource Scope

• Users can define Custom Resource (CR) objects at both cluster-level and namespace-level.
• The Operator continues to run at the cluster level.
• In namespaced scope, users are restricted to creating CR objects only within the assigned namespace.
• If a user specifies a namespace outside the assigned scope using a namespace selector:
  • The operator will add a warning in the status.
  • Secrets will not be created in the outside-scoped namespace.

Terraform Installation Updates 📚

• Three new environment variables have been introduced for operator installation via Terraform:

1. TF_VAR_install_update_crd
   • Enables CRD installation or update during deployment.
   • Default: false
   • Example usage:

export TF_VAR_install_update_crd=true

2. TF_VAR_service_account_namespace_pairs

• Allows specifying service account and namespace pairs for operator deployment.
• Format: "serviceaccount1:namespace1,serviceaccount2:namespace2"
• Important: The namespaces must exist before applying Terraform.
• Example usage:

export TF_VAR_service_account_namespace_pairs="serviceaccount1:namespace1,serviceaccount2:namespace2"

Notes:

• Namespaces must be pre-created when using TF_VAR_service_account_namespace_pairs.

jfrog-registry-operator-2.1.5

Release Notes: Version 2.1.5 🚀

What's New ✨

We're excited to announce the release of version 2.1.5 of the JFrog Registry Operator!
This update includes an upgrade to the latest Golang and dependency versions, addressing several HIGH and CRITICAL CVEs such as CVE-2025-22868

What's Changed

Other Changes 📚

• Update golang.org/x/oauth2 to v0.27.0 by @imantha in #44
• Update golang.org/x/oauth2 to v0.27.0 in go.sum by @imantha in #46
• Added bot to bump up go version and dependencies by @oumkale in #48
• Bump up golang version and dependencies by @github-actions[bot] in #49

New Contributors

• @imantha made their first contribution in #44

jfrog-registry-operator-2.1.1

Release Notes: Version 2.1.1 🚀

We're excited to announce the release of Version 2.1.1 for the JFrog Registry Operator! This update brings a key enhancement for managing your Artifactory instances.

What's New ✨

Subdomain Support in Registry Operator Spec

Added support for defining Artifactory subdomains directly within the registry operator spec.artifactorySubdomains. This allows for more flexible and granular configuration of your Artifactory instances within the operator.

This feature addresses GH-34.

How to Configure 🛠️

Once your operator is in a running state, you can configure the new artifactorySubdomains field, along with existing parameters, in your secretrotator.yaml.

# Uncomment and modify the following lines to enable subdomain support:
# artifactorySubdomains:
# - "https://docker.artifactory.company.com"
# - "https://base-images.artifactory.company.com"

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:
  artifactorySubdomains:
  - "https://docker.artifactory.company.com"
  - "https://artifactory.example.artifactory.company.com"
  artifactoryUrl: "artifactory.example.com" # Your Artifactory URL
  refreshTime: 30m

Also added minor refactoring to the Terraform script and fixed exchangedServiceAccounts the key in master.

2.1.0

Release Notes: Multi-User Support (Version 2.1.x)

We are excited to announce the release of operator version 2.1.x, which introduces robust multi-user support and enhanced flexibility for managing secrets across various Kubernetes service accounts.

Key Highlights

• Multi-User Capabilities: Seamlessly manage secrets for multiple service accounts within your Kubernetes clusters.
• External Service Account Support: Users can now utilize existing external service accounts, providing greater integration flexibility.
• Optional Service Account Settings: From version 2.1.x onwards, setting SERVICE_ACCOUNT_NAME and ANNOTATIONS is optional for multi-user installations, simplifying deployments.

Installation and Configuration

To get started, ensure you have the latest Helm release (v3 is supported) and have added the JFrog Helm repository to your Helm client:

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

Single Service Account Installation (Existing Method)

For installations involving a single service account, you can continue to use the standard helm upgrade command:

export SERVICE_ACCOUNT_NAME="<your-service-account-name>"
export ANNOTATIONS="<Role annotation for service account>" # Example: eks.amazonaws.com/role-arn: arn:aws:iam::000000000000:role/jfrog-operator-role
export NAMESPACE="jfrog-operator" # Or your desired namespace

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

Multi-User Installation (Multiple Service Accounts)

In a multi-user scenario where multiple service accounts need to be created and managed, please create all service accounts using the role ARN as an annotation via the Helm chart. This approach will also update the ClusterRole to grant the necessary permissions to each specific service account.

Create a custom-values.yaml file with your service account details:

exchangedServiceAccounts:
  - name: "sample-service-account-1"
    namespace: "<NAMESPACE>"
    annotations:
      eks.amazonaws.com/role-arn: <role-arn-for-sa-1>
  - name: "sample-service-account-2"
    namespace: "<NAMESPACE>"
    annotations:
      eks.amazonaws.com/role-arn: <role-arn-for-sa-2>
  # Add more service accounts as needed

Install the operator using the custom-values.yaml file:

export NAMESPACE="jfrog-operator" # Or your desired namespace
helm upgrade --install secretrotator jfrog/jfrog-registry-operator \
  --create-namespace \
  -f custom-values.yaml \
  -n ${NAMESPACE}

Important Note: After installation, you can use the service account name and namespace within your custom resources. You may install multiple custom resources with different service account details.

Example SecretRotator Manifest

Once the operator is in a running state, configure your SecretRotator custom resource manifest (secretrotator.yaml) to specify artifactoryUrl, refreshTime, namespaceSelector, serviceAccount, generatedSecrets, and 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: jfrog-operator # Or your target namespace
  generatedSecrets:
    - secretName: token-imagepull-secret
      secretType: docker
    # - secretName: token-generic-secret
    #   secretType: generic
  artifactoryUrl: "artifactory.example.com" # Your Artifactory URL
  refreshTime: 30m
  serviceAccount: # The default name and namespace will be the operator’s service account name and namespace if not specified
    name: "sample-service-account-1" # Specify the service account for this secret rotator
    namespace: "<NAMESPACE>" # Specify the namespace for this service account
  secretMetadata:
    annotations:
      annotationKey: annotationValue
    labels:
      labelName: labelValue
  security:
    enabled: false
    secretNamespace:
    ## NOTE: You can provide either a ca.pem or ca.crt. But make sure that key needs to same as ca.crt or ca.pem in secret
    certificateSecretName:
    insecureSkipVerify: false

We encourage you to try out these new features and provide any feedback!

jfrog-registry-operator-2.0.0

In version 2.0.0, we introduced a new feature flag called generatedSecrets, which now supports multiple secrets. These secrets can be either Kubernetes generic secrets or Docker image pull secrets.

The generic type secret contains the keys token and password, while the docker type secret contains a standard Kubernetes image pull secret. You can use the spec.generatedSecrets feature to define the specifications for one or more
secrets that should be automatically generated.
Each secret will :
• 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.

Example struct in Custom Resource:

spec:
  generatedSecrets:
  - secretName: token-imagepull-secret
    secretType: docker
  - secretName: token-generic-secret
    secretType: generic

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

Additionally, we have improved the status monitoring part, Example:

Status:
  Conditions:
     Last Transition Time: 2025-05-19T07:00:55Z
     Message: Secrets [token-imagepull-secret] (docker) and [token-generic-secret] (generic) in namespaces with label jfro
g-operator managed successfully, please check if any failed namespaces are visible, in order to evaluate individual secret failures, if any
    Reason: Reconciling
    Status: True
    Type: Available
  Provisioned Namespaces:
    test1
    test2
  Secret Managed By Namespaces:
    test1:
      token-imagepull-secret
      token-generic-secret
    test2:
      token-imagepull-secret
      token-generic-secret

jfrog-registry-operator-1.3.0

JFrog Registry Operator 1.3.0 includes:

Added TLS support for jfrog-registry-operator.

1. Enhanced security in the resource .security.enabled must be set to true if either custom certification or insecureSkipVerify is required.

Reference for tls security: here

    security:
      enabled: false
      secretNamespace:
      ## NOTE: You can provide either a ca.pem or ca.crt. But make sure that key needs to same as ca.crt or ca.pem in secret
      certificateSecretName:
      insecureSkipVerify: false

Sample certificate secret ref

2. Added service monitor support. By default, it is set to false in values.yaml.
   This will be part of the Helm chart here

  serviceMonitor:
    enabled: false

To enable the service monitor, you need to configure the monitoring setup

jfrog-registry-operator-1.0.0

The integration of Assume Role and JFrog Access presents a powerful solution. By leveraging Assume Role, AWS Identity and Access Management (IAM) users can temporarily assume permissions to perform actions in a secure and controlled manner.

Furthermore, incorporating third-party tools like JFrog Artifactory into AWS environments, enables seamlessly pulling images from the JFrog Docker private registry, thereby tightenging access control mechanisms to ensure fluid integration that aligns with established industry practices.

Some of the key benefits of the AWS AssumeRole and JFrog Access solution includes:

Some of the key benefits of the AWS AssumeRole and JFrog Access solution includes:

1. Automated Token Rotation: JFrog Access can now manage token rotation seamlessly within your EKS cluster. This eliminates the need for manual intervention, reducing the risk of unauthorized access due to neglected or forgotten credentials.

2. Enhanced Security: With AssumeRole, you can enforce fine-grained access controls, ensuring that only authorized entities have access to your EKS cluster and JFrog Artifactory. This enhances security by minimizing the attack surface and adhering to the principle of least privilege.

3. AWS Environment Integration: The integration of Assume Role and JFrog Access makes your Artifactory repository a first-class citizen in your AWS environment. This means that you can seamlessly fetch images from your Artifactory repository as if it were a native component of your EKS cluster.