Agent skill

Openshift Tls Profile

by openshift-eng in openshift-eng/ai-helpers

A skill your agent uses to implement TLS security profiles for operators and workloads on OpenShift.

Apache-2.0Auto-check passedBackend & APIs

Install Openshift Tls Profile

skills CLI
$ npx skills add openshift-eng/ai-helpers --skill openshift-tls-profile -a claude-code

Project install by default; add -g for ~/.claude/skills/.

GitHub CLI
$ gh skill install openshift-eng/ai-helpers openshift-tls-profile --agent claude-code

Project scope by default; add --scope user for a personal install. Needs GitHub CLI 2.90.0 or later (public preview).

Manual copy
$ git clone --depth 1 https://github.com/openshift-eng/ai-helpers.git skills-src && mkdir -p .claude/skills && cp -r skills-src/plugins/openshift-tls-profile/skills/openshift-tls-profile .claude/skills/openshift-tls-profile && rm -rf skills-src

Use ~/.claude/skills/ instead of .claude/skills for a personal install. The folder must contain SKILL.md.

Claude Code skills documentation · loads skills from .claude/skills/

Facts

Skill name
openshift-tls-profile
GitHub stars
120
Token cost
~6.1k tokens
SKILL.md length
1,624 words
Files
1
Skills in repo
118
Repo updated
First seen
Licence
Apache-2.0

At a glance

A skill your agent uses to implement TLS security profiles for operators and workloads on OpenShift.

  • Works in 3 steps: Fetch TLS Profile from APIServer CR → Convert TLS Profile to Go crypto/tls… → Apply to All HTTP and gRPC Clients/Servers
  • Implement TLS security profiles for operators and workloads on OpenShift
  • SKILL.md covers Background, When to Use This Skill, Requirements and Implementation Steps, plus 4 more sections
  • Calls jq

What it does

Openshift Tls Profile is an agent skill from openshift-eng/ai-helpers. Use this skill to implement TLS security profiles for operators and workloads on OpenShift. Provides guidance on reading TLS config from APIServer CR and applying it to webhook/metrics servers, HTTP, and gRPC endpoints.

Its SKILL.md is about 6.1k tokens, which your agent loads only when the skill is triggered. It is a single SKILL.md file with no bundled scripts.

It sits in Backend & APIs, covering Cryptography, gRPC and Protobuf and Webhooks. It works with gRPC. The repository describes itself as: Developer productivity tools for Claude Code & other AI assistants. The licence is Apache-2.0.

When your agent uses it

  • Implement TLS security profiles for operators and workloads on OpenShift
  • Tasks that involve Cryptography
  • Tasks that involve gRPC and Protobuf

Example prompts

  • “/openshift-tls-profile”

Workflow steps

3 steps, taken from the step headings in SKILL.md.

  1. Fetch TLS Profile from APIServer CR
  2. Convert TLS Profile to Go crypto/tls Configuration
  3. Apply to All HTTP and gRPC Clients/Servers

What it can do on your machine

Read from SKILL.md and the folder at commit a627176. It shows what the files ask for, not the result of running them.

  • Tool permissions

    Pre-approves nothing: there is no allowed-tools line, so your agent's usual permission prompts apply.

    From allowed-tools in the SKILL.md frontmatter.

  • Runs code

    Shell commands in SKILL.md call:

    • jq

    From the folder's file list and the shell code blocks in SKILL.md.

  • Network

    Links to these hosts (documentation or services it may open):

    • github.com
    • pkg.go.dev
    • wiki.mozilla.org
    • docs.redhat.com
    • docs.openshift.com
    • access.redhat.com

    From URLs in SKILL.md, links to its own repository left out.

  • Credentials

    Names no API keys, tokens, secrets or passwords.

    From names ending in _API_KEY, _TOKEN, _SECRET, _KEY or _PASSWORD in SKILL.md.

Context cost

Openshift Tls Profile loads about 6.1k tokens when it runs. Until then it costs about 60 tokens; SKILL.md has 1,624 words of instructions outside code blocks.

Always · name and description, kept in context so the agent knows when to use it
~60
When it runs · the whole SKILL.md, loaded when a task matches
~6.1k

Estimates: characters ÷ 4, the usual rule of thumb; real counts depend on the model's tokenizer. Scripts and assets cost tokens only if the agent reads them.

Safety

Auto-check passed

The automated check found no risky patterns in SKILL.md.

Automated static check — not a guarantee. Review scripts before installing. It scans the text of SKILL.md for risky patterns (piping downloads into a shell, reading credential files, hidden Unicode, destructive commands); files beside SKILL.md are not scanned.

SKILL.md

The full file from openshift-eng/ai-helpers at commit a627176, republished under its Apache-2.0 licence (© openshift-eng). 1,624 words, ~6,100 tokens.

Download SKILL.mdSave it as .claude/skills/openshift-tls-profile/SKILL.md (or your agent's skills folder).
name
openshift-tls-profile
description
Use this skill to implement TLS security profiles for operators and workloads on OpenShift. Provides guidance on reading TLS config from APIServer CR and applying it to webhook/metrics servers, HTTP, and gRPC endpoints.

OpenShift TLS Security Profile Configuration

This skill helps implement TLS security profiles for operators and workloads running on OpenShift. It provides complete guidance on reading TLS configuration from OpenShift cluster and applying it consistently across all secured endpoints.

Background

This skill implements the requirements defined in the Centralized and Enforced TLS Configuration Enhancement. The enhancement addresses the gap where many OpenShift components hardcode TLS settings or rely on library defaults rather than respecting cluster-wide TLS configuration. Key points:

  • All components must honor the centralized TLS security profile from the cluster
  • This enables consistent cryptographic policy enforcement and Post-Quantum Cryptography (PQC) readiness
  • Do not hardcode TLS versions (e.g., TLS 1.3). Always read TLS settings dynamically.

The API changes are implemented in openshift/api#2680, which adds the TLSAdherence feature gate and tlsAdherence field to apiserver.config.openshift.io/v1.

TLS Adherence Modes

The tlsAdherence field in the APIServer CR controls how strictly components adhere to the configured TLS security profile:

ModeDescription
Legacy (default)Backward-compatible behavior. Components attempt to honor the configured TLS profile but may fall back to their individual defaults if conflicts arise. Intended for clusters that need to maintain compatibility during migration.
StrictEnforces strict adherence to the TLS configuration. All components must honor the configured profile without fallbacks. Recommended for security-conscious deployments and required for certain compliance frameworks.

Feature Gate: The TLSAdherence feature gate controls this functionality. It is currently enabled in DevPreviewNoUpgrade and TechPreviewNoUpgrade.

Implementation Note: When implementing TLS profile support in your operator, ensure your component applies the configured TLS profile and reports degraded status on failure in both modes. In Strict mode, components that fail to apply the configured TLS profile should report degraded status rather than silently falling back to defaults.

TLS Profile Sources

Default Source: API Server Configuration

Most components should use the API Server configuration as their TLS profile source. This is the default and preferred option. If you're unsure which source to use, start with the API Server configuration.

Order of Precedence (use only if you have a specific reason to deviate from API Server):

SourceWhen to Use
API Server (default)Use this by default. Most OpenShift operators use library-go's apiserver config observer pattern, which automatically observes the API Server TLS profile.
KubeletOnly use if your component is specifically running on the kubelet and needs to match kubelet's TLS settings.
Ingress ControllerOnly use if your component is specifically handling ingress traffic and needs to match the ingress controller's TLS settings.

When to Use This Skill

Use this skill when:

  • Implementing TLS security profiles in a Kubernetes operator running on OpenShift
  • Configuring webhook servers and metrics endpoints with cluster-wide TLS settings
  • Setting up HTTP or gRPC clients/servers that need to comply with OpenShift TLS policies
  • Converting OpenShift TLS profile types to Go crypto/tls configuration

Requirements

Operators implementing TLS security profiles must satisfy these requirements:

  1. Read TLS profile from APIServer CR: Fetch configuration from apiservers.config.openshift.io/cluster
  2. Apply to all TLS endpoints: Webhook server, metrics server, and any HTTP/gRPC clients or servers
  3. Respond to profile changes: If the TLS profile is updated in the cluster, the component must pick up the changes (existing connections should be terminated and new connections should use the new profile).
Handling Profile Changes

There are several approaches to respond to TLS profile changes:

Option A: Use controller-runtime-common Package (Recommended for controller-runtime)

For operators using controller-runtime, the recommended approach is to use the official package:

github.com/openshift/controller-runtime-common/pkg/tls

This package provides all necessary utilities for TLS profile implementation.

Quick Start Example:

go
package main

import (
	"context"
	"crypto/tls"
	"os"

	configv1 "github.com/openshift/api/config/v1"
	openshifttls "github.com/openshift/controller-runtime-common/pkg/tls"
	"sigs.k8s.io/controller-runtime/pkg/metrics/filters"
	"k8s.io/apimachinery/pkg/runtime"
	utilruntime "k8s.io/apimachinery/pkg/util/runtime"
	clientgoscheme "k8s.io/client-go/kubernetes/scheme"
	ctrl "sigs.k8s.io/controller-runtime"
	"sigs.k8s.io/controller-runtime/pkg/client"
	metricsserver "sigs.k8s.io/controller-runtime/pkg/metrics/server"
	"sigs.k8s.io/controller-runtime/pkg/webhook"
)

var scheme = runtime.NewScheme()

func init() {
	utilruntime.Must(clientgoscheme.AddToScheme(scheme))
	utilruntime.Must(configv1.AddToScheme(scheme))
}

func main() {
	// Create a cancellable context for graceful shutdown on TLS profile changes
	ctx, cancel := context.WithCancel(ctrl.SetupSignalHandler())
	defer cancel()

	cfg := ctrl.GetConfigOrDie()

	// Create a temporary client to fetch initial TLS profile
	tempClient, err := client.New(cfg, client.Options{Scheme: scheme})
	if err != nil {
		os.Exit(1)
	}

	// Fetch the TLS profile from APIServer CR
	tlsProfileSpec, err := openshifttls.FetchAPIServerTLSProfile(ctx, tempClient)
	if err != nil {
		os.Exit(1)
	}

	// Convert to TLSOpts function for controller-runtime
	tlsOpts, unsupportedCiphers := openshifttls.NewTLSConfigFromProfile(tlsProfileSpec)
	if len(unsupportedCiphers) > 0 {
		// Log warning about unsupported ciphers
	}

	mgr, err := ctrl.NewManager(cfg, ctrl.Options{
		Scheme: scheme,
		Metrics: metricsserver.Options{
			BindAddress:   ":8443",
			SecureServing: true,
			FilterProvider: filters.WithAuthenticationAndAuthorization,
			TLSOpts:       []func(*tls.Config){tlsOpts},
		},
		WebhookServer: webhook.NewServer(webhook.Options{
			Port:    9443,
			TLSOpts: []func(*tls.Config){tlsOpts},
		}),
	})
	if err != nil {
		os.Exit(1)
	}

	// Set up the TLS profile watcher to trigger graceful shutdown on changes
	watcher := &openshifttls.SecurityProfileWatcher{
		Client:                mgr.GetClient(),
		InitialTLSProfileSpec: tlsProfileSpec,
		OnProfileChange: func(ctx context.Context, old, new configv1.TLSProfileSpec) {
			// Cancel context to trigger graceful shutdown and reload
			cancel()
		},
	}
	if err := watcher.SetupWithManager(mgr); err != nil {
		os.Exit(1)
	}

	if err := mgr.Start(ctx); err != nil {
		os.Exit(1)
	}
}

Package Functions:

FunctionPurpose
FetchAPIServerTLSProfile(ctx, client)Fetches TLS profile spec from APIServer CR, returns default (Intermediate) if not set
GetTLSProfileSpec(profile)Resolves profile type (Old/Intermediate/Modern/Custom) to TLSProfileSpec
NewTLSConfigFromProfile(spec)Returns a func(*tls.Config) for controller-runtime's TLSOpts + list of unsupported ciphers
SecurityProfileWatcherController that watches APIServer and triggers callback on TLS profile changes

SecurityProfileWatcher:

The SecurityProfileWatcher is a controller that watches the APIServer CR and invokes a callback when the TLS profile changes:

go
watcher := &openshifttls.SecurityProfileWatcher{
	Client:                mgr.GetClient(),
	InitialTLSProfileSpec: initialProfile,
	OnProfileChange: func(ctx context.Context, old, new configv1.TLSProfileSpec) {
		// Common pattern: cancel context to trigger graceful shutdown
		// The operator will restart and pick up the new TLS configuration
		cancel()
	},
}
if err := watcher.SetupWithManager(mgr); err != nil {
	return err
}

Note: The watcher handles predicates internally - it only watches the "cluster" APIServer object and compares profile changes using reflect.DeepEqual.

Restart vs Hot-Reload Trade-offs:

ApproachRestart RequiredExisting ConnectionsRecommendation
SecurityProfileWatcherYes - graceful shutdownAll connections use new TLS settings after restartRecommended - ensures consistent TLS policy across all connections
GetConfigForClient (Option D)NoNot updated - only new connections use new settingsUse only when restarts are not acceptable

Why SecurityProfileWatcher is recommended:

  • TLS profile changes are cluster-level security policy changes that should apply uniformly
  • GetConfigForClient leaves existing long-lived connections using the old TLS configuration
  • Graceful shutdown ensures all connections are re-established with the correct TLS settings
  • Simpler implementation using the official package

Option B: For OpenShift Operators (configobserver pattern)

This is the recommended approach for OpenShift operators using the library-go configobserver pattern. Use library-go's ObserveTLSSecurityProfile function from the apiserver config observer package. This function:

  • Observes the API Server's TLSSecurityProfile from the cluster configuration (via APIServerLister().Get("cluster")) - this is the default source for all components
  • Converts OpenSSL cipher names to IANA names (used by Kubernetes ServingInfo configuration) using crypto.OpenSSLToIANACipherSuites
  • Sets servingInfo.minTLSVersion and servingInfo.cipherSuites in the observed config
  • Returns the configuration as a map[string]interface{} in the format expected by your operator's observed config
  • Centralizes profile mappings in library-go to ensure all components use consistent TLS profile handling
go
package configobserver

import (
	"github.com/openshift/library-go/pkg/operator/configobserver"
	"github.com/openshift/library-go/pkg/operator/configobserver/apiserver"
	"github.com/openshift/library-go/pkg/operator/events"
)

// In your config observer controller's ObserveConfig method
func (c *MyConfigObserver) ObserveConfig(
	listers configobserver.Listers,
	recorder events.Recorder,
	existingConfig map[string]interface{},
) (map[string]interface{}, []error) {
	// ObserveTLSSecurityProfile observes APIServer.Spec.TLSSecurityProfile and sets
	// servingInfo.minTLSVersion and servingInfo.cipherSuites in observedConfig
	observedConfig, errs := apiserver.ObserveTLSSecurityProfile(listers, recorder, existingConfig)
	// ... merge with other observed config
	return observedConfig, errs
}

Option C: Watch from Existing Controller

If your operator cannot use the SecurityProfileWatcher (Option A) or the configobserver pattern (Option B), use this approach. Watch the APIServer resource from your existing controller to trigger operand reconciliation when the TLS profile changes, allowing you to update operand deployments with the new TLS settings:

go
package controller

import (
	"context"
	"reflect"

	configv1 "github.com/openshift/api/config/v1"
	"k8s.io/apimachinery/pkg/runtime"
	"k8s.io/apimachinery/pkg/types"
	ctrl "sigs.k8s.io/controller-runtime"
	"sigs.k8s.io/controller-runtime/pkg/builder"
	"sigs.k8s.io/controller-runtime/pkg/client"
	"sigs.k8s.io/controller-runtime/pkg/event"
	"sigs.k8s.io/controller-runtime/pkg/handler"
	"sigs.k8s.io/controller-runtime/pkg/predicate"
	"sigs.k8s.io/controller-runtime/pkg/reconcile"

	myv1 "myoperator/api/v1"
)

type MyOperandReconciler struct {
	client.Client
	Scheme *runtime.Scheme
}

func (r *MyOperandReconciler) Reconcile(ctx context.Context, req ctrl.Request) (ctrl.Result, error) {
	// Fetch operand
	operand := &myv1.MyOperand{}
	if err := r.Get(ctx, req.NamespacedName, operand); err != nil {
		return ctrl.Result{}, client.IgnoreNotFound(err)
	}

	// Fetch current TLS profile
	profile, err := GetTLSSecurityProfile(ctx, r.Client)
	if err != nil {
		return ctrl.Result{}, err
	}

	// Apply TLS configuration to operand's deployment/pods
	// This could involve updating a ConfigMap, Secret, or Deployment annotation
	// to trigger a rolling restart of operand pods with new TLS settings
	if err := r.reconcileOperandTLS(ctx, operand, profile); err != nil {
		return ctrl.Result{}, err
	}

	return ctrl.Result{}, nil
}

func (r *MyOperandReconciler) SetupWithManager(mgr ctrl.Manager) error {
	return ctrl.NewControllerManagedBy(mgr).
		For(&myv1.MyOperand{}).
		// Watch APIServer and trigger reconcile for all operands when TLS profile changes
		Watches(
			&configv1.APIServer{},
			handler.EnqueueRequestsFromMapFunc(r.mapAPIServerToOperands),
			builder.WithPredicates(tlsProfileChangedPredicate()),
		).
		Complete(r)
}

// mapAPIServerToOperands returns reconcile requests for all operands when APIServer changes
func (r *MyOperandReconciler) mapAPIServerToOperands(ctx context.Context, obj client.Object) []reconcile.Request {
	// Only react to the "cluster" APIServer
	if obj.GetName() != "cluster" {
		return nil
	}

	// List all operands and trigger reconcile for each
	var operands myv1.MyOperandList
	if err := r.List(ctx, &operands); err != nil {
		return nil
	}

	requests := make([]reconcile.Request, len(operands.Items))
	for i, op := range operands.Items {
		requests[i] = reconcile.Request{
			NamespacedName: types.NamespacedName{
				Name:      op.Name,
				Namespace: op.Namespace,
			},
		}
	}
	return requests
}

// tlsProfileChangedPredicate filters events to only TLS profile changes
func tlsProfileChangedPredicate() predicate.Predicate {
	return predicate.Funcs{
		CreateFunc: func(e event.CreateEvent) bool {
			return e.Object.GetName() == "cluster"
		},
		UpdateFunc: func(e event.UpdateEvent) bool {
			if e.ObjectNew.GetName() != "cluster" {
				return false
			}
			oldAPI, ok := e.ObjectOld.(*configv1.APIServer)
			if !ok {
				return false
			}
			newAPI, ok := e.ObjectNew.(*configv1.APIServer)
			if !ok {
				return false
			}
			// Only reconcile if TLS profile actually changed
			return !reflect.DeepEqual(
				oldAPI.Spec.TLSSecurityProfile,
				newAPI.Spec.TLSSecurityProfile,
			)
		},
		DeleteFunc: func(e event.DeleteEvent) bool {
			return false
		},
		GenericFunc: func(e event.GenericEvent) bool {
			return false
		},
	}
}

func (r *MyOperandReconciler) reconcileOperandTLS(
	ctx context.Context,
	operand *myv1.MyOperand,
	profile *configv1.TLSSecurityProfile,
) error {
	// Update operand deployment with new TLS settings
	// For example, update an annotation to trigger rolling restart:
	//
	// deployment.Spec.Template.Annotations["tls-profile-hash"] = hashTLSProfile(profile)
	//
	// Or update a ConfigMap/Secret that the operand mounts
	return nil
}

This approach is efficient because:

  • Uses predicates to filter only TLS profile changes (ignores other APIServer updates)
  • Integrates with existing controller logic
  • Automatically reconciles all operands when the profile changes
  • Follows standard controller-runtime patterns

Option D: Dynamic TLS Config Update (Not Recommended)

An alternative approach uses Go's GetConfigForClient callback to dynamically return TLS configuration for each new connection without requiring a restart. However, this approach is not recommended because:

  • Existing connections are not affected - they continue using the old TLS configuration until they disconnect
  • Long-lived connections may remain on outdated TLS settings indefinitely
  • TLS profile changes are security policy changes that should apply uniformly to all connections

For consistent TLS policy enforcement, use Option A (SecurityProfileWatcher with graceful restart) or Option C (watch and reconcile) instead.

Show full SKILL.md (585 more words)Show less

Implementation Steps

Step 1: Fetch TLS Profile from APIServer CR

Use FetchAPIServerTLSProfile from the controller-runtime-common package to retrieve the TLS security profile:

go
import (
	openshifttls "github.com/openshift/controller-runtime-common/pkg/tls"
)

// Fetch the TLS profile from APIServer CR
// Returns default Intermediate profile if not set
tlsProfileSpec, err := openshifttls.FetchAPIServerTLSProfile(ctx, client)
if err != nil {
	return err
}

This function fetches the TLSSecurityProfile from apiservers.config.openshift.io/cluster and returns the default Intermediate profile if none is configured.

Step 2: Convert TLS Profile to Go crypto/tls Configuration

Use NewTLSConfigFromProfile from the controller-runtime-common package to convert the TLS profile spec to a func(*tls.Config) suitable for controller-runtime:

go
import (
	openshifttls "github.com/openshift/controller-runtime-common/pkg/tls"
)

// Convert to TLSOpts function for controller-runtime
// Returns a func(*tls.Config) that sets MinVersion and CipherSuites
tlsOpts, unsupportedCiphers := openshifttls.NewTLSConfigFromProfile(tlsProfileSpec)
if len(unsupportedCiphers) > 0 {
	// Log warning about unsupported ciphers (ciphers not available in Go's crypto/tls)
	log.Info("Some ciphers from TLS profile are not supported", "ciphers", unsupportedCiphers)
}

This function handles:

  • Resolving profile types (Old/Intermediate/Modern/Custom) to their cipher suites and min TLS version
  • Converting OpenSSL cipher names to Go crypto/tls constants
  • Returning unsupported ciphers for logging (some OpenSSL ciphers have no Go equivalent)
Step 3: Apply to All HTTP and gRPC Clients/Servers

For controller-runtime webhook and metrics servers, see the complete Quick Start Example in Option A above.

For other endpoints:

All TLS-enabled endpoints in your operator and operand must honor the cluster TLS configuration. This includes:

Endpoint TypeHow to Apply TLS Config
HTTP ClientSet Transport.TLSClientConfig on http.Client
HTTP ServerSet TLSConfig on http.Server
gRPC ClientUse grpc.WithTransportCredentials(credentials.NewTLS(tlsConfig)) with grpc.NewClient()
gRPC ServerUse grpc.Creds(credentials.NewTLS(tlsConfig)) with grpc.NewServer()

For each endpoint, use the *tls.Config returned by TLSConfigFromProfile() (Step 2) to configure:

  • MinVersion - minimum TLS protocol version
  • CipherSuites - allowed cipher suites (only applies to TLS 1.2 and below)

Key principle: No HTTP or gRPC endpoint should use hardcoded TLS settings. Always derive TLS configuration from the cluster's APIServer CR to ensure consistent security policy enforcement across all components.

TLS Profile Types

OpenShift supports four TLS profile types based on Mozilla's Server Side TLS recommendations:

ProfileMin TLS VersionDescription
OldTLS 1.0Legacy compatibility, not recommended for production
Intermediate (default)TLS 1.2Recommended for general use, balances security and compatibility
ModernTLS 1.3Highest security, may not work with older clients
CustomConfigurableUser-defined ciphers and minimum TLS version

Default Profile: When spec.tlsSecurityProfile is not set in the APIServer CR, the Intermediate profile is used as the default. This provides a good balance between security and compatibility.

Note: In Go, cipher suites are not configurable for TLS 1.3 - they are automatically selected by the runtime.

APIServer Custom Resource

The TLS profile is configured in the APIServer custom resource named cluster. If spec.tlsSecurityProfile is not specified, the Intermediate profile is used by default.

yaml
apiVersion: config.openshift.io/v1
kind: APIServer
metadata:
  name: cluster
spec:
  audit:
    profile: Default
  # tlsSecurityProfile is optional. If not set, defaults to Intermediate profile.
  tlsSecurityProfile:
    # type can be: Old, Intermediate, Modern, or Custom
    type: Intermediate
    # Only one of the following should be set based on type:
    old: {}
    intermediate: {}
    modern: {}
    custom:
      ciphers:
        - TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
        - TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
      minTLSVersion: VersionTLS12

Reference:

Query Commands

Check the current TLS security profile in your cluster:

bash
# Get the full APIServer configuration
oc get apiserver cluster -o yaml

# Get just the TLS security profile (empty output means default Intermediate profile is used)
oc get apiserver cluster -o jsonpath='{.spec.tlsSecurityProfile}' | jq .

# Check the effective TLS profile type (empty means Intermediate default)
oc get apiserver cluster -o jsonpath='{.spec.tlsSecurityProfile.type}'

Note: If the above commands return empty output, the cluster is using the default Intermediate profile.

OpenShift library-go Crypto Utilities

Note: For controller-runtime users, NewTLSConfigFromProfile from github.com/openshift/controller-runtime-common/pkg/tls handles all cipher conversion automatically. The utilities below are primarily for:

  • Non-controller-runtime code (e.g., library-go based operators using configobserver pattern)
  • Understanding how the conversion works internally

The github.com/openshift/library-go/pkg/crypto package provides utilities for converting between OpenShift TLS profile configurations and Go's crypto/tls types:

FunctionPurpose
TLSVersion(name string) (uint16, error)Convert TLS version name (e.g., "VersionTLS12") to Go constant
CipherSuitesOrDie(names []string) []uint16Convert IANA cipher names to Go constants
OpenSSLToIANACipherSuites(ciphers []string) []stringMap OpenSSL cipher names to IANA names
SecureTLSConfig(config *tls.Config) *tls.ConfigApply secure defaults to a TLS config
DefaultCiphers() []uint16Get default cipher suites for Intermediate profile

Why these exist: OpenShift's configv1.TLSProfiles uses OpenSSL-format cipher names, not Go constants. These utilities handle the conversion.

Additional Resources

© openshift-eng, Apache-2.0. Rendered from Markdown: HTML in the file is shown as text, images as links, and headings moved down two levels. Raw file

Files

Just SKILL.md in plugins/openshift-tls-profile/skills/openshift-tls-profile of openshift-eng/ai-helpers.

Open the folder on GitHubat commit a627176

Compare with similar skills

Openshift Tls Profile next to the 5 skills that share the most tags, products or categories with it. Stars are the repository's; “used in” counts other GitHub owners with a copy.

Openshift Tls Profile compared with similar skills
SkillStarsUsed inTokensAuto-checkLicenceRepo updated
Openshift Tls Profile this skillopenshift-eng/ai-helpers120—~6.1kAutomated safety check: PassApache-2.0
Fishjam JS Server SDKsoftware-mansion-labs/skills291—~1.4kAutomated safety check: PassMIT
Quicknode Skillinternet-court/internet-court-skill6.4k—~11kAutomated safety check: PassMIT
Quicknodesendaifun/skills1301 repos~5.5kAutomated safety check: NotesApache-2.0
API ForgeEliasOulkadi/shokunin114—~2.9kAutomated safety check: PassMIT
API Designtravisjneuman/.claude1011 repos~2.5kAutomated safety check: PassMIT

Similar skills

  • Fishjam JS Server SDK

    software-mansion-labs/skills

    Node.js / TypeScript server SDK for Fishjam — backends that create rooms, mint peer tokens, listen to server notifications, and run agents.

    291 GitHub stars~1.4k tokensUpdated 10 days ago
    Backend & APIsAuto-check passed
  • Quicknode Skill

    internet-court/internet-court-skill

    Quicknode blockchain infrastructure for 80+ chains: Core RPC API, Streams, Webhooks, Blazar WSS, Solana gRPC, HyperCore gRPC, SQL Explorer, Metaplex DAS API, Blockbook, Ordinals & Runes API, Swap…

    6.4k GitHub stars~11k tokensUpdated 1 mo ago
    Backend & APIsAuto-check passed
  • Quicknode

    sendaifun/skills

    Quicknode blockchain infrastructure for Solana — RPC endpoints, DAS API (Digital Asset Standard) for NFTs and compressed assets, Yellowstone gRPC streaming, Priority Fee API, Streams (real-time data…

    130 GitHub starsUsed in 1 repo~5.5k tokens
    Backend & APIsAuto-check: notes
  • API Forge

    EliasOulkadi/shokunin

    Design REST/GraphQL APIs with OpenAPI 3.1, error handling, pagination, rate limiting, webhooks, and idempotency.

    114 GitHub stars~2.9k tokensUpdated 3 days ago
    Backend & APIsAuto-check passed
  • API Design

    travisjneuman/.claude

    REST and GraphQL API design best practices including OpenAPI specs.

    101 GitHub starsUsed in 1 repo~2.5k tokens
    Backend & APIsAuto-check passed
  • Helius

    majiayu000/claude-skill-registry

    Comprehensive guide for Helius - Solana's leading RPC and API infrastructure provider.

    666 GitHub starsUsed in 1 repo~4.7k tokens
    Backend & APIsAuto-check: notes

More from openshift-eng/ai-helpers

All 118 skills in this repo
  • Investigate CI Reliability

    openshift-eng/ai-helpers

    Find and independently validate actionable reliability defects across OpenShift release jobs and presubmits, then export portable issue handoffs.

    120 GitHub stars~1.9k tokensUpdated 2 days ago
    Auto-check passed
  • Address Review PR

    openshift-eng/ai-helpers

    Fetch and address all PR review comments — categorize by priority, make code changes, post replies, and push.

    120 GitHub stars~2.9k tokensUpdated 2 days ago
    Auto-check passed
  • Categorize Activity Types

    openshift-eng/ai-helpers

    Categorize Jira issues into Red Hat Sankey Activity Type categories using MCP Jira tools.

    120 GitHub stars~2.4k tokensUpdated 2 days ago
    Auto-check passed
  • Has Review Work

    openshift-eng/ai-helpers

    Decide whether a GitHub PR has unanswered authorized review comments or new required CI failures worth a follow-up agent.

    120 GitHub stars~1.9k tokensUpdated 2 days ago
    Auto-check passed
  • Must Gather Analyzer

    openshift-eng/ai-helpers

    Analyze OpenShift must-gather diagnostic data including cluster operators, pods, nodes, and network components.

    120 GitHub stars~2.3k tokensUpdated 2 days ago
    Auto-check passed
  • Payload Autodl JSON

    openshift-eng/ai-helpers

    Schema for the autodl JSON data file produced by payload-analysis for database ingestion — you must use this skill whenever generating the autodl JSON file

    120 GitHub stars~2.6k tokensUpdated 2 days ago
    Auto-check passed

Works with

Categories

Questions about Openshift Tls Profile

What does Openshift Tls Profile do?

A skill your agent uses to implement TLS security profiles for operators and workloads on OpenShift. Openshift Tls Profile is an agent skill from openshift-eng/ai-helpers. Use this skill to implement TLS security profiles for operators and workloads on OpenShift.

When should I use Openshift Tls Profile?

Openshift Tls Profile fits situations like: implement TLS security profiles for operators and workloads on OpenShift; tasks that involve Cryptography; tasks that involve gRPC and Protobuf.

How do I install Openshift Tls Profile in Claude Code?

Run `npx skills add openshift-eng/ai-helpers --skill openshift-tls-profile -a claude-code`. Or copy the skill folder (plugins/openshift-tls-profile/skills/openshift-tls-profile in openshift-eng/ai-helpers) into .claude/skills/openshift-tls-profile in your project. Claude Code loads it when a task matches its description.

How do I install Openshift Tls Profile in Codex?

Run `npx skills add openshift-eng/ai-helpers --skill openshift-tls-profile -a codex`. Or copy the skill folder (plugins/openshift-tls-profile/skills/openshift-tls-profile in openshift-eng/ai-helpers) into .agents/skills/openshift-tls-profile in your project. Codex loads it when a task matches its description.

Can I use Openshift Tls Profile in Cursor, Gemini CLI or GitHub Copilot?

Cursor, Gemini CLI, GitHub Copilot and OpenCode also load SKILL.md folders. With the skills CLI, run `npx skills add openshift-eng/ai-helpers --skill openshift-tls-profile -a cursor` (or -a gemini-cli, github-copilot or opencode for the others). To copy it by hand, put the folder in .cursor/skills/openshift-tls-profile, .gemini/skills/openshift-tls-profile, .github/skills/openshift-tls-profile and .opencode/skills/openshift-tls-profile in your project.

What does Openshift Tls Profile need to run?

Going by SKILL.md and its folder, Openshift Tls Profile needs the command-line tools its instructions call (jq).

Does Openshift Tls Profile access the network?

SKILL.md names 6 domains. As links in the text: github.com, pkg.go.dev, wiki.mozilla.org, docs.redhat.com, docs.openshift.com and access.redhat.com. This is read from the text; nothing was executed.

Is Openshift Tls Profile safe to install?

Our automated static check of SKILL.md found no risky patterns, such as piping downloads into a shell, reading credential files or hidden Unicode. It is not a guarantee. Review the folder before installing.

What licence does Openshift Tls Profile use?

Openshift Tls Profile is published under the Apache-2.0 licence (the repository's licence). It allows redistribution, so the full SKILL.md is shown on this page.

How many tokens does Openshift Tls Profile use?

About 6.1k tokens (SKILL.md is roughly 24k characters). Agents keep only the skill's name and description in context until a task matches; then they load SKILL.md in full.

What are the alternatives to Openshift Tls Profile?

Skills that share tags, products or a category with Openshift Tls Profile: Fishjam JS Server SDK (software-mansion-labs/skills, 291 stars), Quicknode Skill (internet-court/internet-court-skill, 6.4k stars), Quicknode (sendaifun/skills, 130 stars) and API Forge (EliasOulkadi/shokunin, 114 stars). The comparison table on this page puts their stars, adoption, token cost, safety result and licence side by side.

Who maintains Openshift Tls Profile?

openshift-eng (a GitHub organization) maintains it in openshift-eng/ai-helpers, which has 120 GitHub stars. The repository holds 118 skills in this directory. The repository was last updated on October 6, 2026.

Source: openshift-eng/ai-helpers on GitHub. Facts on this page come from the repository at the commit we read; the author's words are quoted as theirs.