Skip to main content

Kubernetes Cluster

Connector name

agtkube

Connector type

Executable

Type (UI field value)

Kubernetes Cluster

Target system versions supported / tested

The agtkube connector is known to work with Kubernetes Cluster v1.18; other versions may work.

Connector status / support

Customer-Verified

Clients may contact Bravura Security support for assistance with this connector. Troubleshooting and testing must be completed in the client's test environment as Bravura Security does not maintain internal test environments for the associated target system.

The following Bravura Security Fabric operations are supported by this connector (depending on your product license and version):

  • create account

  • create group

  • delete group

  • add user to group

  • delete user from group

  • add group to group

  • remove group from group

  • get server information

  • List:

    • accounts

    • attributes

    • groups

    • members

For a full list and explanation of each connector operation, see connector operations.

Preparation

Before you can target Kubernetes Cluster you must:

  1. Install client software and set up a target system administrator

  2. Create at least one template account

Installing client software and set up a target system administrator

Before targeting a Kubernetes Cluster it is recommended to configure the target system for connector agtkebe to connect with. Follow the guide at: https://kubernetes.io/docs/tasks/access-application-cluster/access-cluster/ . Kubectl should be set up as a proxy on the Bravura Security Fabric server.

Creating a template account

Bravura Security Fabric uses template accounts as models or "blueprints" for creating new accounts in Kubernetes Cluster.

Targeting the Kubernetes Cluster system

For each Kubernetes Cluster system, add a target system in Bravura Security Fabric (Manage the System > Resources > Target systems):

  • Type is Kubernetes Cluster, listed under Storage Systems.

  • Address uses the following options:

The full list of target parameters is explained in Target System Options .

Table 1. Kubernetes Cluster address configuration

Option

Description

Options marked with a redstar.png are required.

Server redstar.png

The Kubernetes Cluster server to connect to.

(key: server)

Port redstar.png

The port to connect to.

(key: port)

Connection over SSL

Select to enforce SSL connections.

Default is "true".

(key: ssl)

Validate the server’s certificate when connecting

Determines whether to validate the server’s security certificate for SSL connections.

Default is "true".

(key: checkCert)

HTTP Network Proxy

Optional.

(key: proxy)

Records per page

Paging size to use while listing.

(key: pagesize)

Seperation character used in object ID ⋆

Separator character to be used in object’s IDs.

Default is "—".

The character should not occur in any of the object names to avoid issues.

(key: seperator)

List external users and groups

If users and groups that are not native to Kubernetes should be listed.

Default is "true".

(key: listExternal)



The address is entered as follows:

{server=<server>;port=<port>;ssl=true/false;checkCert=true/false;][proxy=&lt;proxy&gt;;][pagesize=&lt;pagesize&gt;;][seperator=&lt;|&gt;;][listExternal=true/false;]}

Authentication for connecting to a Kubernetes Cluster is handled by the kubectl application, as such no administrator credentials will be used. However, target system administrator credentials must be specified to pass the configuration page, but they will not be used.

Handling attributes

There are multiple kinds of objects listed as Users and multiple types of roles and groups listed as Groups. The IDs for objects of this connector are in the format of kind|namespace|name with a separating character "|" that is configurable in the address line.

The kind attribute or the first portion of the ID can be used to identify the object type.

Service accounts (kind=ServiceAccount) and external users (kind=User) are listed as users; whereas roles (kind=Role), clusterroles (KIND=CLUSTERROLE), rolebindings (kind=RoleBinding), clusterrolebindings (kind=ClusterRoleBinding) and external groups (kind=Group) are listed as groups.

The middle namespace portion will not exist for objects without a namespace , such as cluster roles or cluster role bindings.

Handling account attributes

You can view the complete list of attributes that Bravura Security Fabric can manage, including native and pseudo-attributes, using the Manage the system (PSA) module. To do this, select Kubernetes Cluster from the Manage the system > Resources > Account attributes > Target system type menu.

For information about the native Kubernetes Cluster attributes managed by Bravura Security Fabric , consult your Kubernetes Cluster documentation.

Bravura Security Fabric explicitly handles the following attributes and pseudo-attributes when creating or modifying recipient accounts for Kubernetes Cluster target systems:

The _binding attribute is a required attribute for create operation and its value should be a longID for RoleBinding or ClusterRoleBinding .

Kubernetes Cluster grants permissions defined in a role to a user or set of users via role binding. The create operation is used for external users only and it functions as GRUA (add user to group) operation. The operation adds an external user to RoleBinding or ClusterRoleBinding which is specified in the _binding attribute in a create new user request. _binding is a required attribute for create operation and its value should be a longID for RoleBinding or ClusterRoleBinding .

Handling group attributes

You can view the complete list of attributes that Bravura Security Fabric can manage, including native and pseudo-attributes, using the Manage the system (PSA) module. To do this, select Kubernetes Cluster from the Manage the system > Resources > Group attributes > Target system type menu.

For information about the native Kubernetes Cluster attributes managed by Bravura Security Fabric , consult your Kubernetes Cluster documentation.

The multi-valued resource attribute rule is a required attribute for creating a Role or a ClusterRole , which needs to be set to specify what permissions the role grants. The format for the attribute is the json format from the Kubernetes API. For example:

"apiGroups":["apps"],"resources":["deployments"],"verbs":["get","list","watch"].

The rule attribute will also be listed in this format.

The resource attribute roleRef is required for creating a RoleBinding or ClusterRoleBinding , which needs to be set to determine what Role or ClusterRole the binding applies to. The value should be the Role or ClusterRole’s longid . For example: RoleBinding|default|Rolebinding .

The resource attribute namespace can be specified, if none is specified the Kubernetes API will use the "default" namespace.

When creating groups:

  • Only Roles, ClusterRoles, RoleBindings and ClusterRoleBindings can be created.

  • For creating a Role or a ClusterRole the multi-valued attribute rule is required to be set for specifying which permissions the role grants.

  • For creating a RoleBinding or ClusterRoleBinding the roleRef attribute is required to be set to determine which Role or ClusterRole the binding applies to. The value should be the Role or ClusterRole’s longid.

  • namespace can be specified for binding Role, if none is specified the Kubernetes API will use the "default" namespace. For ClusterRole and ClusterRoleBinding no namespace cannot be specified.

The connector agtkebe lists external users that are members of at least one binding as there is no full list of all known external users.

Adding users to groups is only valid in the case of adding service accounts or external users to RoleBindings or ClusterRoleBindings .

Adding groups to groups is only valid in the case of adding external groups to RoleBindings or ClusterRoleBindings .