16.3. Declarative configuration examples


You can create declarative configurations by using the following examples as a guide. Use the roxctl declarative-config lint command to verify that your configurations are valid.

Declarative configuration authentication provider example

name: A sample auth provider
minimumRole: Analyst
uiEndpoint: central.custom-domain.com:443
extraUIEndpoints:
    - central-alt.custom-domain.com:443
groups:
    - key: email
      value: example@example.com
      role: Admin
    - key: groups
      value: reviewers
      role: Analyst
requiredAttributes:
    - key: org_id
      value: "12345"
claimMappings:
    - path: org_id
      value: my_org_id
oidc:
    issuer: sample.issuer.com
    mode: auto
    clientID: CLIENT_ID
    clientSecret: CLIENT_SECRET
clientSecret: CLIENT_SECRET
iap:
    audience: audience
saml:
    spIssuer: sample.issuer.com
    metadataURL: sample.provider.com/metadata
saml:
    spIssuer: sample.issuer.com
    cert: |
    ssoURL: saml.provider.com
    idpIssuer: idp.issuer.com
userpki:
    certificateAuthorities: |
    certificate
openshift:
    enable: true

where:

minimumRole
Specifies the minimum role that will be assigned by default to any user logging in. If left blank, the value is None.
uiEndpoint
Specifies the user interface endpoint of your Central instance.
extraUIEndpoints
Specifies whether your Central instance is exposed to different endpoints.
groups
Specifies the specific roles to map users based on their attributes.
groups.key
Specifies the key that can be any claim returned from the authentication provider.
groups.role
Specifies the role that the users are given. You can use a default role or a declaratively-created role.
requiredAttributes
Specifies whether the attributes returned from the authentication provider are required, for example, if the audience is limited to a specific organization or group. This is optional.
claimMappings
Specifies whether the claims returned from the identity provider should be mapped to custom claims. This is optional.
oidc
Specifies whether the system is configured to use OpenID Connect (OIDC) as an authentication method.
oidc.issuer
Specifies the expected issuer for the token.
oidc.mode
Specifies the OIDC callback mode. Possible values are auto, post, query, and fragment. The preferred value is auto.
iap
Specifies whether the system is configured to use Google Identity-Aware Proxy (IAP) as an authentication method.
saml
Specifies whether the system is configured to use Security Assertion Markup Language (SAML) 2.0 dynamic or static configuration as an authentication method.
saml.cert
Specifies the certificate in Privacy Enhanced Mail (PEM) format.
userpki.certificateAuthorities
Specifies whether the system is configured for authentication with user certificates.
userpki.certificate
Specifies the certificate in PEM format.
openshift
Specifies whether the system is configured for OpenShift Auth authentication providers.

16.3.2. Declarative configuration short-lived token example

Declarative configuration short-lived token example

issuer: https://token.actions.githubusercontent.com
type: GITHUB_ACTION
tokenExpirationDuration: 20m
mappings:
  - key: sub
    value: repos:stackrox:stackrox
    role: Analyst

where:

issuer
Specifies the expected issuer for the token to exchange against a short-lived one.
type
Specifies the configuration type. See "Configuring short-lived access" and "Integrating RHACS using short-lived access tokens" for more information.
tokenExpirationDuration
Specifies the token lifetime in the XhYmZs format. The lifetime cannot be longer than 24 hours.
mappings
Specifies the roles to which users are mapped, based on their attributes.
mappings.key
Specifies that the key can be any claim returned from the issuer.
mappings.role
Specifies the role that the users are given. You can use a default role or a declaratively-created one.

16.3.3. Declarative configuration permission set example

Declarative configuration permission set example

name: A sample permission set
description: A sample permission set created declaratively
resources:
- resource: Integration
  access: READ_ACCESS
- resource: Administration
  access: READ_WRITE_ACCESS

where:

resources.resource
Specifies a full list of supported resources. For more information, go to Access Control Permission Sets.
resources.access
Specifies that the access can be either READ_ACCESS or READ_WRITE_ACCESS.

16.3.4. Declarative configuration access scope example

Declarative configuration access scope example

name: A sample access scope
description: A sample access scope created declaratively
rules:
    included:
        - cluster: secured-cluster-A
          namespaces:
            - namespaceA
        - cluster: secured-cluster-B
    clusterLabelSelectors:
        - requirements:
        - requirements:
          - key: kubernetes.io/metadata.name
            operator: IN
            values:
            - production
            - staging
            - environment

where:

rules.included.cluster
Specifies a cluster where only specific namespaces are included within the access scope.
rules.included.cluster
Specifies a cluster where all namespaces are included within the access scope.
rules.clusterLabelSelectors.requirements.operator
Specifies the Operator to use for the label selection. Valid values are IN, NOT_IN, EXISTS, and NOT_EXISTS.

16.3.5. Declarative configuration role example

Declarative configuration role example

name: A sample role
description: A sample role created declaratively
permissionSet: A sample permission set
accessScope: Unrestricted

where:

permissionSet
Specifies the name of the permission set; can be either one of the system permission sets or a declaratively-created permission set.
accessScope
Specifies the name of the access scope; can be either one of the system access scopes or a declaratively-created access scope.
Red Hat logoGithubredditYoutubeTwitter

学习

尝试、购买和销售

社区

關於紅帽

我们提供强化的解决方案,使企业能够更轻松地跨平台和环境(从核心数据中心到网络边缘)工作。

让开源更具包容性

红帽致力于替换我们的代码、文档和 Web 属性中存在问题的语言。欲了解更多详情,请参阅红帽博客.

关于红帽文档

Legal Notice

Theme

© 2026 Red Hat
返回顶部